Talk:Silent boot

From ArchWiki

Remove console cursor blinking

The console cursor at boot keeps blinking if you follow these intstructions. This can be solved by passing vt.global_cursor_default=0 to the kernel (source).

--Farsil (talk) 08:50, 23 September 2016 (UTC)Reply[reply]

Retaining fsck output

Is there any way to retain the output, to keep a record or a log if fsck does in fact do something drastic? Ordinarily one would > or >> to a file, but are not all filesystems as yet unmounted at this point? quequotion (talk) 15:22, 21 August 2017 (UTC)Reply[reply]

You can disable clearing of the console before the login prompt, see getty#Have_boot_messages_stay_on_tty1. -- Lahwaacz (talk) 16:02, 21 August 2017 (UTC)Reply[reply]

Started Bpfilter

As of 4.18, "Started Bpfilter" is displayed at boot after following all listed instructions. I am currently unsure of a way to silence. --Bumblebeer (talk) 03:03, 26 August 2018‎ (UTC)Reply[reply]

Add more info about i915.fastboot=1

As said here [1](https://www.phoronix.com/scan.php?page=news_item&px=Flicker-Free-Arch-Linux), i915.fastboot=1 now replaces quiet splash vt.global_cursor_default=0 rd.loglevel=0 systemd.show_status=false rd.udev.log-priority=0 udev.log-priority=0, tested on intel ivy bridge and it works well. --Sigmasd (talk) 14:52, 13 December 2018 (UTC)Reply[reply]

systemd.show_status=error instead of auto

So reading https://systemd.network/init.html looks like the appropiate value of systemd.show_status to disable succesful messages while displaying error ones is using error, not auto, as auto should behave like false (which is not desirable in this situation) except when some unit is taking too long, then it changes to enable, displaying everything. Also, if you only want to hide the succesful systemd units while displaying error ones and also not changing the default behaviour of the kernel, you should just use systemd.show_status=error while not using quiet or loglevel, so the only addition to the parameters would be systemd.show_status=error. Also, i want to mention that while quiet loglevel=3 rd.systemd.show_status=auto worked for me, only using rd.systemd.show_status=auto did not worked and i had to remove the rd., using only systemd.show_status=auto, i don't know why

—This unsigned comment is by Akrai (talk) 16:54, 31 March 2020‎. Please sign your posts with ~~~~!

I can confirm systemd.show_status=error working, and rd.(…)=error not working. Quote: “The option prefixed with "rd." is honored only in the initial RAM disk (initrd), while the one that is not prefixed only in the main system.”
At the point when we're starting systemd services, aren't we already past initrd (initramfs) territory? Adrian5 (talk) 08:32, 17 February 2021 (UTC)Reply[reply]

Mention console=ttyxxx?

the whole purpose of this page is to avoid output to the console. if there is no output, the boot is silent. additional, no output means, the vendor logo stays on. all instructions here tinker with different parts of the system to prevent them printing to the console. unfortunately, this may be extensive work and is likely unreliable anyway.

if you just provide the kernel-parameter ie "console=tty2", all output is printed behind the scene, nothing is visible on monitor-out. no other settings are necessary and it seems to be reliable and easy. with this, on my machine the vendor logo shows up, nothing else, then the login manager comes up. thats nice!

see https://wiki.archlinux.org/index.php/Working_with_the_serial_console#Kernel

i dont know how to add this to the page, though.

what do you think?

Lshappy (talk) 08:12, 4 August 2020 (UTC)Reply[reply]

I think this is the best method, it's basically the definition of silent boot (and the vendor logo remaining active is pretty nice as well), thanks for sharing I definitely suggest that you add this to the wiki.
Sigmasd (talk) 09:33, 7 August 2020 (UTC)Reply[reply]

Major restructuring

Sorry, i wanted to add more info to my edit, but my keyboard was too fast... here is what and why:

  • changed the order and level of the topics so its clearer where each step belongs to and why
  • added info about the framebuffer and what it means/does in perspektive of silent boot so there is a basic understanding of the topic
  • split up some topics so they are clearer to see what and why do do, ie udev and systemd
  • added info about console-redirection
  • added info / split between redirection and preventing mechanismns
  • removed info about vga=current, that info was from 2012, testet vga=current, saw no difference in behaviour
  • corrected link to xorg-article
  • added some infos to fsck and the init script
  • extended infos for loglevel

please check for typos and grammar, non native-english speaker here

Lshappy (talk) 15:48, 7 August 2020 (UTC)Reply[reply]

I'm sorry too, but the page needs to be updated slowly in accordance with ArchWiki:Contributing#The 3 fundamental rules. The first step is now done - you started the discussion. -- Lahwaacz (talk) 17:40, 7 August 2020 (UTC)Reply[reply]
Hello Archers, sorry for that, i'm new to this wiki-thing, read the rules now. I think this page would greatly benefit from a new structure and new information. Thats what i tried here: https://wiki.archlinux.org/index.php?title=Silent_boot&diff=630344&oldid=630343 I understand i have to split this up in little packets and each change have to be discussed. Unfortunatly, i really have no time for that. Please, you are free to take the new information and structure in the undo'd change and work with it. I understand thats the arch way here. no offence intended, i simply have no time, just wanted to contribute, regards, Lshappy (talk) 19:26, 7 August 2020 (UTC)Reply[reply]

/etc/udev/udev.conf log_level defaults to info?

It seems to me that the default log level is not err rather info? That shows an ugly banner when udev starts: https://pasteboard.co/7TRv19vlv06h.jpg ModestDirac25 (talk) 19:12, 20 November 2023 (UTC)Reply[reply]

Yes, that's why this article suggests changing it to rd.udev.log_level=3 which is err. -- andreymal (talk) 20:05, 20 November 2023 (UTC)Reply[reply]