[SOLVED] Kernel suddenly showing logs during boot

finnblue8 · 2024-01-21 17:37:21

Hi all:

I use EFISTUB as a boot loader. I've been using this configuration for a year and a half:

 

#!/bin/bash
efibootmgr --disk /dev/sdb --part 1 --create --label "ArchLinux" --loader /vmlinuz-linux --unicode 'root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img loglevel=3 quiet nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1'
exit 0
# See man efibootmgr

I specifically do not want text output on the screen during boot, since that slows my boot by 2-3 seconds. This configuration has had zero issues since creation.

Suddenly in the last week, despite not updating the above, the kernel has started outputting text to the screen during boot. I've deleted the UEFI entry for Arch and remade it with the above script - still outputting text. I'm not sure why - "quiet" usually suppresses that.

Did something change recently or in kernel 6.7 that affects suppressing the boot log? To be clear - I have not touched EFISTUB in months. Even after redoing EFISTUB with this script the system refuses to not show logs.

Kind of at a loss as to why this is happening. Hoping someone here can educate me.

Thanks!

Last edited by finnblue8 (2024-05-29 04:21:26)

ua4000 · 2024-01-29 11:06:05

finnblue8 wrote:

still outputting text.

And the content is ?
Are these the usual outputs when you would have used no "quiet" option?
Please post:

cat /proc/cmdline

seth · 2024-01-29 16:00:28

I specifically do not want text output on the screen during boot, since that slows my boot by 2-3 seconds.

WHAT??
Like in WHAT THE FUCK?!?

Is that some bullshit theory, a phoronix benchmark or did you actually measure this?
This is nuts, the output itself doesn't stall anything unless you're using a serial or printer console. I'd be rather worried about what causes that output.

finnblue8 · 2024-01-30 03:34:31

ua4000 wrote:

finnblue8 wrote:
still outputting text.
And the content is ?
Are these the usual outputs when you would have used no "quiet" option?
Please post:
cat /proc/cmdline

Don't really know because I usually don't read them since they're hidden by "quiet." No errors in red that I can tell. For some odd reason there are messages appearing in blue text all of a sudden, though, never seen that before. Could you please tell me how to access this log after boot so I can copy it?

 
cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3 vt.global_cursor_default=0 nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1

I switched around "quiet" and "loglevel=3" in the last week to the above since I read on the wiki having them in the reverse order can cause problems. Also never had systemd.show_status=auto or vt.global_cursor_default=0 prior to last week.

Last edited by finnblue8 (2024-01-30 03:35:02)

finnblue8 · 2024-01-30 03:38:26

seth wrote:

I specifically do not want text output on the screen during boot, since that slows my boot by 2-3 seconds.
WHAT??
Like in WHAT THE FUCK?!?
Is that some bullshit theory, a phoronix benchmark or did you actually measure this?
This is nuts, the output itself doesn't stall anything unless you're using a serial or printer console. I'd be rather worried about what causes that output.

So if you're worried it'd be more productive to help find a solution rather than resorting to expletives.

This is the Newbie Corner. The questions here are not of the highest caliber. Comments like this do nothing but contribute to the reputation Arch has of being full of snobby, elitist keyboard warriors. An honestly ridiculous comment. Same with you utterly insisting every single commenter use code tags.

It feels like 2-3 seconds to me when I boot my own system. That's what I'm going to call it. I couldn't care less exactly how much longer it's taking - point is, it's taking longer than I'd like. Is there a number that'd be more pleasing to you? 1 second? Load time = bad.

If you don't want to contribute to a solution I'd ask that you please don't comment.

Last edited by finnblue8 (2024-01-30 03:43:31)

Head_on_a_Stick · 2024-01-30 06:56:18

Reduce the loglevel to avoid unwanted messages.

Did you actually read the messages? They might be important.

kokoko3k · 2024-01-30 07:54:25

Same with you utterly insisting every single commenter use code tags.

Because "every single commenter needs use code tags."
Because it gives legibility to the post, hence It is a form of respect versus the ones you're asking help from.
Keep asking for such simple thing and not giving up on that is not certainly to blame, quite the opposite.

seth · 2024-01-30 09:01:26

If you don't want to contribute to a solution I'd ask that you please don't comment.

Ok.
Your asserted behavior is categorically false.
The mere message printout doesn't stall the system.
Please provide the actual output you're seeing, in doubt point a camera at the monitor.

Then post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

because
1. it will out some hard data behind your feelings about the boot time
2. if the boot slows down there's some actual issue that's probably gonna be logged there

And get your fucking head out of your ass.

finnblue8 · 2024-01-30 18:27:31

seth wrote:

If you don't want to contribute to a solution I'd ask that you please don't comment.
Ok.
Your asserted behavior is categorically false.
The mere message printout doesn't stall the system.
Please provide the actual output you're seeing, in doubt point a camera at the monitor.
Then post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
because
1. it will out some hard data behind your feelings about the boot time
2. if the boot slows down there's some actual issue that's probably gonna be logged there
And get your fucking head out of your ass.

For a continued dialogue I'm just going to ignore your thoughts on how long it takes. I don't care. As I said, it's not important exactly how much longer it's taking. Outputting text to screen takes time.

 
sudo journalctl -b | curl -F 'file=@-' 0x0.st

http://0x0.st/HDBy.txt

At loglevel = 3 the only *new* errors that I notice in the log I can see on screen are

 
Jan 30 13:10:34 LiDe kernel: usb 1-14: 3:1: cannot get freq at ep 0x84

and

 
Jan 30 13:10:34 LiDe kernel: usb 1-14: Failed to query (GET_INFO) UVC control 5 on unit 1: 0 (exp. 1).

but neither of these seem to affect the system in noticeable ways. I have no problems with any of my USB devices. I *have* had issues with my Logitech speakers connected via 3.5mm AUX since kernel 6.7, but I'm confident that's a kernel issue related to snd_hda_intel like we've been seeing problems with.

The other errors regarding ACPI region are due to bugs in my Dell BIOS that I've had for ages.

Still don't understand why things are appearing in blue - that's not something I ever intentionally set, and I've never seen that in 2 years on this Arch system.

Last edited by finnblue8 (2024-01-30 18:32:30)

finnblue8 · 2024-01-30 18:59:15

Head_on_a_Stick wrote:

Reduce the loglevel to avoid unwanted messages.
Did you actually read the messages? They might be important.

Even

quiet loglevel=0

is showing the boot log. This strikes me as unusual.

quiet loglevel=3

worked fine to suppress everything up until about the 15th of this month.

loglevel=2 at least suppresses the blue messages.

Last edited by finnblue8 (2024-01-30 18:59:35)

seth · 2024-01-30 21:23:52

No idea about the color (some plymouth thing? do you have a photo of the screen?), but this shows up because it's an error and you should first an foremost check
a) older journals whether it exists there as well¹
b) if not, the behavior of the LTS kernel to make sure that it's not an issue w/ the firmware/BIOS or your HW (it's the webcam)

The proposed loglevel behavior would either indicate a bug in the kernel (error message handling, check your pacman log whether you upgraded the kernel around the 15th) or a fluke
Maybe the actual output is also controlled by "systemd.show_status=auto rd.udev.log_level=3" if the message "leaked" there.
You could add "boot_delay=250" to slow down printk

¹the pattern shows up for the particular device in https://forum.manjaro.org/t/gui-extraor … -ti/117800

---

It's perfectly valid to pursue a silent boot or be worried about (new) error messages, but

I specifically do not want text output on the screen during boot, since that slows my boot by 2-3 seconds.

grossly misrepresents the situation (the actual overhead of really printing stuff on screen is measured in nanoseconds) and created a false perception of the problem.
I'm not sure whether I've to explain why that's not particularly helpful when seeking technical support.

finnblue8 · 2024-01-31 02:01:09

seth wrote:

No idea about the color (some plymouth thing? do you have a photo of the screen?), but this shows up because it's an error and you should first an foremost check
a) older journals whether it exists there as well¹
b) if not, the behavior of the LTS kernel to make sure that it's not an issue w/ the firmware/BIOS or your HW (it's the webcam)
The proposed loglevel behavior would either indicate a bug in the kernel (error message handling, check your pacman log whether you upgraded the kernel around the 15th) or a fluke
Maybe the actual output is also controlled by "systemd.show_status=auto rd.udev.log_level=3" if the message "leaked" there.
You could add "boot_delay=250" to slow down printk
¹the pattern shows up for the particular device in https://forum.manjaro.org/t/gui-extraor … -ti/117800

Blue text

It's still logging to screen on linux-lts, with or without "systemd.show_status=auto rd.udev.log_level=3." I only added that in troubleshooting and never needed it for silent boot prior. Regardless of kernel I don't remember it doing this before the 15th.

Not surprising that webcam has problems. It was only about $20. I'd unplug it but I need it for work (which I do on Windows on the same machine). I can't edit BIOS settings because Windows 10 has full disk encryption with Bitlocker and is a requirement of my employer. Fast Boot should be off anyway.

In switching back and forth between LTS and mainline kernel for testing I unplugged/plugged back in webcam and removed i915 from my modprobe blacklist. The latter fixed my sound card not being detected on >=6.7. One or both of those actions has also fixed the blue text - but it's still not respecting my kernel parameters for silent boot, even with "quiet loglevel=0."

Last edited by finnblue8 (2024-01-31 02:04:31)

ewaller · 2024-01-31 02:16:55

finnblue8 wrote:

I use EFISTUB as a boot loader.

Just thinking out loud here. Are you sure you are using EFISTUB? You also said you use MS Windows. It f**ks with things and plays poorly in the sandbox.
On this system, I boot Windows about twice a year. I did so this weekend. It updated itself.

I also use EFISTUB to boot Arch. And, use the uEFI pre-boot environment to pick Windows when necessary. Long story short, Windows 'helped' me be changing my boot order without consulting me. Badly.

My point is, assuming you have some kind of bootloader installed, or perhaps you have have multiple EFI entries for your Arch Linux, and you have recently launched that fine OS from the US Pacific Northwest; perhaps your uEFI boot order isn't what you think it is. OTOH, I think I recall your saying your /proc/cmdline was okay. Regardless, check your uEFI variables.

Last edited by ewaller (2024-01-31 02:17:40)

finnblue8 · 2024-01-31 02:22:11

ewaller wrote:

finnblue8 wrote:
I use EFISTUB as a boot loader.
Just thinking out loud here. Are you sure you are using EFISTUB? You also said you use MS Windows. It f**ks with things and plays poorly in the sandbox.
On this system, I boot Windows about twice a year. I did so this weekend. It updated itself.
I also use EFISTUB to boot Arch. And, use the uEFI pre-boot environment to pick Windows when necessary. Long story short, Windows 'helped' me be changing my boot order without consulting me. Badly.
My point is, assuming you have some kind of bootloader installed, or perhaps you have have multiple EFI entries for your Arch Linux, and you have recently launched that fine OS from the US Pacific Northwest; perhaps your uEFI boot order isn't what you think it is. OTOH, I think I recall your saying your /proc/cmdline was okay. Regardless, check your uEFI variables.

As sure as I can be - I've only ever used GRUB and EFISTUB as boot loaders on this system. I ditched GRUB after the kerfuffle that screwed up everyone's systems a couple years ago. There's no other boot loaders installed on this system to launch Arch.

In switching between LTS and mainline I updated my EFISTUB script but forgot to run it, so I ended up trying to boot LTS with EFISTUB referencing mainline. It obviously didn't boot because it couldn't find the mainline initramfs. That makes me 100% sure the commands I'm writing are being updated in NVRAM.

 
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,001A,001B,0014,0015,0019,0016
Boot0000* ArchLinux	HD(1,GPT,c6cd8545-1acc-46b8-a068-751ec15c990a,0x800,0x32000)/File(\vmlinuz-linux)72006f006f0074003d002f006400650076002f007300640062003300200072007700200069006e0069007400720064003d005c0069006e00740065006c002d00750063006f00640065002e0069006d006700200069006e0069007400720064003d005c0069006e0069007400720061006d00660073002d006c0069006e00750078002e0069006d00670020006c006f0067006c006500760065006c003d00330020007100750069006500740020006e006f007700610074006300680064006f00670020006c0073006d003d00610070007000610072006d006f0072002c006c006f0063006b0064006f0077006e002c006c0061006e0064006c006f0063006b002c00790061006d0061002c0062007000660020006e00760069006400690061005f00640072006d002e006d006f00640065007300650074003d003100
Boot0001* Windows Boot Manager	HD(1,GPT,cff741af-10ff-4179-a1ae-e09ca27ca896,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000074000100000010000000040000007fff0400
Boot0014* Diskette Drive	BBS(0,,0x0)0000474f00004e4f930000000100000063004400690073006b00650074007400650020004400720069007600650000000501090000000000007fff040002010c00d041030a000000000101060000140305060004007fff040001043600ef47642dc93ba041ac194d51d01b4ce6300031003700360030003000320030003600300037003000300030003300350000007fff04000000424f
Boot0015* Hard Drive	BBS(Floppy,,0x0)0000474f00004e4fad000000010000008500480061007200640020004400720069007600650000000501090001000000007fff040002010c00d041030a0000000001010600001d01010600000003171000010000000025385a81b21e8a7fff040001044800ef47642dc93ba041ac194d51d01b4ce6530061006d00730075006e006700200053005300440020003900370030002000450056004f0020003200350030004700420000007fff04000000424f00004e4f97000000010000006f00480061007200640020004400720069007600650000000501090001000000007fff040002010c00d041030a0000000001010600001703120a000100ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000200020002000200020002000320020004e003700500035005600420053004d0000007fff04000000424f00004e4f97000000010000006f00480061007200640020004400720069007600650000000501090001000000007fff040002010c00d041030a0000000001010600001703120a000200ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce63100320030003500310033003000380037003000370035002000200020002000200020002000200000007fff04000000424f00004e4f97000000010000006f00480061007200640020004400720069007600650000000501090001000000007fff040002010c00d041030a0000000001010600001703120a000300ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000200020002000200020002000200020004e005a0050003100330036005300420000007fff04000000424f
Boot0016* NetWork	BBS(PCMCIA,,0x0)0000474f00004e4f91000000010000006f004e006500740057006f0072006b0000000501090004000000007fff040001041a00ae84b11df581724e85442bab0c2cac5c0400000200007fff040001044000ef47642dc93ba041ac194d51d01b4ce65100750061006c0063006f006d006d002000410074006800650072006f007300200042006f006f00740000007fff04000000424f
Boot0019* USB Storage Device	BBS(HD,,0x0)0000474f00004e4f9b0000000100000063005500530042002000530074006f007200610067006500200044006500760069006300650000000501090002000000007fff040002010c00d041030a000000000101060000140305060013007fff040001043600ef47642dc93ba041ac194d51d01b4ce6300033003700340035003200310030003600300030003000370030003600320000007fff04000000424f
Boot001A* Onboard NIC (IPV4)	PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(de7c6ad34f33,0)/IPv4(0.0.0.00.0.0.0,0,0)0000424f
Boot001B* Onboard NIC (IPV6)	PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(de7c6ad34f33,0)/IPv6([::]:<->[::]:,0,0)0000424f

I only ever have one Arch entry at a time.

Last edited by finnblue8 (2024-01-31 02:24:35)

d.ALT · 2024-01-31 07:21:35

seth wrote:

No idea about the color (some plymouth thing? do you have a photo of the screen?)

finnblue8 wrote:

Blue text

Since the last (linux 6.7.2.arch1-1? , 6.7.1.arch1-1?) update I also got the blue-colored output (which didn't happen before).

seth · 2024-01-31 08:50:52

The blue text on the screnshot doesn't mention the usb device at all but ACPI errors (ie. the earlymost stuff) and w/

removed i915 from my modprobe blacklist

I bet everybody elses right arms that it's the simpledrm device. Pot. in combination w/ efistub, @d.Alt?

That makes me 100% sure the commands I'm writing are being updated in NVRAM.

To be 101% sure, simply check whether /proc/cmdline gets applied.

also fixed the blue text - but it's still not respecting my kernel parameters for silent boot

?
https://wiki.archlinux.org/title/Silent … parameters
Try "systemd.show_status=false" and use the "0" loglevels

d.ALT · 2024-01-31 13:51:58

seth wrote:

The blue text on the screnshot doesn't mention the usb device at all but ACPI errors (ie. the earlymost stuff) and w/
removed i915 from my modprobe blacklist
I bet everybody elses right arms that it's the simpledrm device. Pot. in combination w/ efistub, @d.Alt?

@seth: ~~I'll let you know as soon as I'll put my fingers onto my own computer's keyboard again~~ can confirm it's happening on my Intel iGPU (915) machines only: both EFISTUB and GRUB.
The NVIDIA machine (nvidia_drm.modeset=1) does NOT presents the blue-colored output.

Last edited by d.ALT (2024-01-31 19:08:51)

finnblue8 · 2024-01-31 19:19:42

seth wrote:

The blue text on the screnshot doesn't mention the usb device at all but ACPI errors (ie. the earlymost stuff) and w/
removed i915 from my modprobe blacklist
I bet everybody elses right arms that it's the simpledrm device. Pot. in combination w/ efistub, @d.Alt?
That makes me 100% sure the commands I'm writing are being updated in NVRAM.
To be 101% sure, simply check whether /proc/cmdline gets applied.
https://wiki.archlinux.org/title/Silent … parameters
Try "systemd.show_status=false" and use the "0" loglevels

cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img quiet loglevel=3 nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1

On boot *with i915 not blacklisted* system shows boot log with no blue errors.

Adding "systemd.show_status=false":

cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img quiet loglevel=3 systemd.show_status=false nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1

On boot with i915 not blacklisted system shows boot log with ACPI errors appearing in blue.

Changing loglevel to 0:

cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img quiet loglevel=0 systemd.show_status=false nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1

On boot with i915 not blacklisted system shows boot log without blue ACPI errors.

cat /proc/cmdline is always returning the correct kernel parameters, so I'm confident EFISTUB isn't the issue here. If I use loglevel=0 kernel errors are correctly omitted from the log. What's left is systemd.

I use systemd in the initramfs.

 
cat /etc/mkinitcpio.conf 

HOOKS=(autodetect systemd modconf block filesystems keyboard numlock fsck)

The silent boot page of the wiki suggests systemd is prone to odd behavior if used in the initramfs. The suggested "quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3" configuration doesn't work to suppress systemd.

 
cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3 nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf nvidia_drm.modeset=1

On boot with i915 not blacklisted system shows boot log without blue ACPI errors.

I have to keep i915 not blacklisted apparently until whatever kernel bug that makes my sound card not load is fixed. It's been present since 6.7.0 and still present in 6.7.2-arch1-1. Having i915 blacklisted has never made issues with sound in the past.

Last edited by finnblue8 (2024-01-31 19:24:49)

seth · 2024-01-31 20:59:36

I have to keep i915 not blacklisted apparently until whatever kernel bug that makes my sound card not load is fixed.

That's not necessarily a bug.

Summary (just reg, the ACPI output, please confirm)

 bad: loglevel=3 quiet # from your OP
good: quiet loglevel=3 
 bad: quiet loglevel=3 systemd.show_status=false 
good: quiet loglevel=0 systemd.show_status=false 
good: quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3

The quiet/loglevel order was wrong™ (but in accordance w/ the wiki)?
And apparently adding systemd.show_status (even as false!) can throw the output off.
Did you update systemd during the critical time?

finnblue8 · 2024-02-01 01:56:44

seth wrote:

I have to keep i915 not blacklisted apparently until whatever kernel bug that makes my sound card not load is fixed.
That's not necessarily a bug.
Summary (just reg, the ACPI output, please confirm)
 bad: loglevel=3 quiet # from your OP
good: quiet loglevel=3 
 bad: quiet loglevel=3 systemd.show_status=false 
good: quiet loglevel=0 systemd.show_status=false 
good: quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3
The quiet/loglevel order was wrong™ (but in accordance w/ the wiki)?
And apparently adding systemd.show_status (even as false!) can throw the output off.
Did you update systemd during the critical time?

I did update to 255.3 on the 24th, but I already had this issue before that release.

If we say that ACPI errors appearing are "bad", then:

"loglevel=3 quiet" = bad, shows ACPI/blue errors (and on this I might add, I've been using this order to achieve silent boot for years and never knew this was apparently backwards until trying to diagnose this issue. Might the wiki be mistaken?)

"quiet loglevel=3" = bad, shows ACPI/blue errors

"quiet loglevel=3 systemd.show_status=false" = bad, shows ACPI/blue errors - I've never needed systemd.show_status *ever* to achieve silent boot

"quiet loglevel=0 systemd.show_status=false" = good, no ACPI/blue errors

"quiet" only, nothing else = good, no ACPI/blue errors

"loglevel=0 systemd.show_status=false" = good, no ACPI/blue errors

"loglevel=3 systemd.show_status=auto" = bad, shows ACPI/blue errors - according to wiki "quiet" is also passed when systemd.show_status=auto is passed so shouldn't theoretically need it (?)

"systemd.show_status=auto" has interesting behavior when used on its own - the kernel actually boots like it would with "loglevel=3 quiet", but then systemd decides to do whatever it wants once it takes over and shows output for successful items anyway, which is the behavior "=auto" is supposed to suppress.

"systemd.show_status=false" has the same behavior as above.

I tried moving NVIDIA KMS earlier in the parameter sequence, because I read here that NVIDIA DRM KMS has changed (?) since version 545, and I am on 545.29.06:

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img nvidia_drm.modeset=1 fbdev=1 quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3 nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf

but that's got ACPI errors and does not suppress systemd.

Last edited by finnblue8 (2024-02-01 17:30:51)

seth · 2024-02-01 17:13:27

The correct parameter would be "nvidia_drm.fbdev=1", but don't use that, it seems nvidia rushed that and it's causing issues w/ framebuffer switches.
Otherwise the position of the "nvidia_drm.modeset=1" in the parameter list should not matter at all.

"loglevel=3 quiet" = bad, shows ACPI/blue errors
"quiet loglevel=3" = bad, shows ACPI/blue errors (and on this I might add, I've been using this order to achieve silent boot for years and never knew this was apparently backwards until trying to diagnose this issue. Might the wiki be mistaken?)

This seems to contradict your OP (the order there is "loglevel=3 quiet") and #18 where the second pattern is in the first item along

On boot *with i915 not blacklisted* system shows boot log with no blue errors.

zgrep -i loglevel /proc/config.gz

"quiet" is most likely "1", so setting the loglevel to "3" *afterwards* is counterproductive.

Try just "systemd.show_status=false quiet" rsp. "systemd.show_status=auto quiet" (I'd trust systemd a bit less than the kernel here)

Edit: the obvious contender for 1/15 would be https://gitlab.archlinux.org/archlinux/ … b43b0bc9d7 though.

Last edited by seth (2024-02-01 17:15:42)

finnblue8 · 2024-02-01 17:43:09

This seems to contradict your OP (the order there is "loglevel=3 quiet")

Comment in parentheses should be for "loglevel=3 quiet." I'm typing these posts out in a text editor before publishing them on the forum and got the line messed up. To be clear, as mentioned in my OP I've always used the "loglevel=3 quiet" order, and it's worked. I've edited that post to correct this.

cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img nvidia_drm.modeset=1 systemd.show_status=false quiet nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf

No ACPI, still shows systemd log

 
cat /proc/cmdline 

root=/dev/sdb3 rw initrd=\intel-ucode.img initrd=\initramfs-linux.img nvidia_drm.modeset=1 systemd.show_status=auto quiet nowatchdog lsm=apparmor,lockdown,landlock,yama,bpf

Identical results to above, no ACPI, still shows systemd log

Last edited by finnblue8 (2024-02-01 17:44:05)

seth · 2024-02-01 20:48:13

For a sanity check, what are the default loglevels?

zgrep -i loglevel /proc/config.gz

But the blue ACPI messages where likely down to a contradiction between the explicit (3) and quiet (1) loglevel.
Are the systemd messages new as well?

Add "rd.udev.log_level=0 rd.systemd.show_status=false"

finnblue8 · 2024-02-01 23:06:47

seth wrote:

For a sanity check, what are the default loglevels?
zgrep -i loglevel /proc/config.gz
But the blue ACPI messages where likely down to a contradiction between the explicit (3) and quiet (1) loglevel.
Are the systemd messages new as well?
Add "rd.udev.log_level=0 rd.systemd.show_status=false"

zgrep -i loglevel /proc/config.gz

CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4
CONFIG_CONSOLE_LOGLEVEL_QUIET=1
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4

Systemd output is your standard output, nothing unusual at all - starting this, starting that. It just refuses to be quiet.

"rd.udev.log_level=0 rd.systemd.show_status=false" produces a lot of new blue errors. Systemd refuses to be silent.

https://0x0.st/HDyT.txt

seth · 2024-02-01 23:09:08

Sorry, the idea was to keep the "quiet" parameter no matter what.

Arch Linux

#1 2024-01-21 17:37:21

[SOLVED] Kernel suddenly showing logs during boot

#2 2024-01-29 11:06:05

Re: [SOLVED] Kernel suddenly showing logs during boot

#3 2024-01-29 16:00:28

Re: [SOLVED] Kernel suddenly showing logs during boot

#4 2024-01-30 03:34:31

Re: [SOLVED] Kernel suddenly showing logs during boot

#5 2024-01-30 03:38:26

Re: [SOLVED] Kernel suddenly showing logs during boot

#6 2024-01-30 06:56:18

Re: [SOLVED] Kernel suddenly showing logs during boot

#7 2024-01-30 07:54:25

Re: [SOLVED] Kernel suddenly showing logs during boot

#8 2024-01-30 09:01:26

Re: [SOLVED] Kernel suddenly showing logs during boot

#9 2024-01-30 18:27:31

Re: [SOLVED] Kernel suddenly showing logs during boot

#10 2024-01-30 18:59:15

Re: [SOLVED] Kernel suddenly showing logs during boot

#11 2024-01-30 21:23:52

Re: [SOLVED] Kernel suddenly showing logs during boot

#12 2024-01-31 02:01:09

Re: [SOLVED] Kernel suddenly showing logs during boot

#13 2024-01-31 02:16:55

Re: [SOLVED] Kernel suddenly showing logs during boot

#14 2024-01-31 02:22:11

Re: [SOLVED] Kernel suddenly showing logs during boot

#15 2024-01-31 07:21:35

Re: [SOLVED] Kernel suddenly showing logs during boot

#16 2024-01-31 08:50:52

Re: [SOLVED] Kernel suddenly showing logs during boot

#17 2024-01-31 13:51:58

Re: [SOLVED] Kernel suddenly showing logs during boot

#18 2024-01-31 19:19:42

Re: [SOLVED] Kernel suddenly showing logs during boot

#19 2024-01-31 20:59:36

Re: [SOLVED] Kernel suddenly showing logs during boot

#20 2024-02-01 01:56:44

Re: [SOLVED] Kernel suddenly showing logs during boot

#21 2024-02-01 17:13:27

Re: [SOLVED] Kernel suddenly showing logs during boot

#22 2024-02-01 17:43:09

Re: [SOLVED] Kernel suddenly showing logs during boot

#23 2024-02-01 20:48:13

Re: [SOLVED] Kernel suddenly showing logs during boot

#24 2024-02-01 23:06:47

Re: [SOLVED] Kernel suddenly showing logs during boot

#25 2024-02-01 23:09:08

Re: [SOLVED] Kernel suddenly showing logs during boot

Board footer