[gentoo-user] Kernel boot messages are no longer displayed

[Hilco Wijbenga]

Hi all,

Since kernel 3.12.13 (3.12.13-gentoo), the kernel boot messages have
disappeared, i.e. they are no longer displayed at boot time. All I get
is a line like "Loading kernel 3.12.13". (I just upgraded to
3.12.20-gentoo, so now it's something like "Loading kernel 3.12.20".)

I have no idea why. I checked my grub config and it does not add a
"quiet" argument. I see nothing in /etc/rc.conf about quiet (or
verbose). And X86_VERBOSE_BOOTUP is set to 'y'. I also looked for
"quiet", "boot", and "messages" (while running "make xconfig") and
nothing untoward showed up.

How do I get back to a normal and sane boot process?

Cheers,
Hilco

[walt]

What is the next thing you see after "Loading kernel 3.12.20" ?

What was the last kernel that booted normally? Does it still boot
normally?

The kernel config files for each kernel are installed as
/boot/config-3.12.nn so you can compare them to see what changed.

[Hilco Wijbenga]

On 24 May 2014 16:53, walt <w41...@gmail.com> wrote:
> On 05/24/2014 01:20 PM, Hilco Wijbenga wrote:
>> Since kernel 3.12.13 (3.12.13-gentoo), the kernel boot messages have
>> disappeared, i.e. they are no longer displayed at boot time. All I get
>> is a line like "Loading kernel 3.12.13". (I just upgraded to
>> 3.12.20-gentoo, so now it's something like "Loading kernel 3.12.20".)
>>
>> I have no idea why. I checked my grub config and it does not add a
>> "quiet" argument. I see nothing in /etc/rc.conf about quiet (or
>> verbose). And X86_VERBOSE_BOOTUP is set to 'y'. I also looked for
>> "quiet", "boot", and "messages" (while running "make xconfig") and
>> nothing untoward showed up.
>>
>> How do I get back to a normal and sane boot process?
>
> What is the next thing you see after "Loading kernel 3.12.20" ?

Nothing. There is a pause of a dozen seconds or so and then the login
panel appears.

By the way, I checked again and it says "Loading Linux 3.12.20-gentoo
..." (just to be complete and precise).

> What was the last kernel that booted normally? Does it still boot
> normally?

I don't quite remember. :-( Probably whatever kernel came before
3.12.13 but I don't have any leftover configs or anything like that. I
ran the sys-kernel/aufs-sources (to be able to use Docker) so it might
have been one of those but I doubt it.

> The kernel config files for each kernel are installed as
> /boot/config-3.12.nn so you can compare them to see what changed.

Well, not by default... :-) In any case, I have deleted it all. It
didn't seem a difficult thing to fix and whenever I had logged in
other stuff happened that made me forget about the boot messages. :-)
It's just today I decided to google for it. Surprisingly, nobody is
complaining about this so it must be something specific to my
environment. I just have no clue what. I certainly did nothing (on
purpose) to get rid of boot messages.

[Greg Turner]

The essence of your problem is: you need a working console during your boot sequence if you want to see anything.  For an X86 'puter the main two ways to get that are: the VGA console, and the framebuffer console (CONFIG_VGA_CONSOLE, almost always works in a pinch unless you boot from EFI, in which case it probably doesn't work at all).

A working framebuffer console needs a working framebuffer.  The glue that says (as best I understand it): "hey, Mr. kernel, please don't just leave that framebuffer of mine just lying around doing nothing, let's use it as a console" is CONFIG_FRAMEBUFFER_CONSOLE.

Furthermore, CONFIG_EARLY_PRINTK is required if you want the really early junk to whiz by illegibly at the beginning of your boot sequence (the stuff that looks about like the output of "dmesg|head -n 500")

If you compiled your framebuffer as a module, it also won't load until that module does.  Which means, either until udev starts (and successfully loads the module) or until it gets loaded by some other means, i.e., by script code in an initrd/initramfs.

The's a migration, in linuxville, underway now, from the old-school "userspace modesetting" paradigm (where graphic card configuration sorta worked like Windows 95: the "drivers" were hyper-privileged user-land programs running amok) to the newer, shinier "kernel modesetting" paradigm, which finally brings linux, let's say, into a "Windows NT 3.5" sort-of epoch (i.e.: working drivers, at least, finally, in the kernel, where they belong -- but, God help you, if you start hot-plugging stuff or want to use suspend, that stuff all broke).  There has been some pain and upheaval.  Recipes that used to work have been breaking and you just have to read your logs and some wikis and figure it out, sometimes, the old fashioned way.

If you run radeon, well, read the wiki, most of the advice in there is correct and necessary to get a working accelerated system these days -- disabling KMS will break your xorg and your framebuffer entirely!  also be /sure/ CONFIG_FB_RADEON and CONFIG_DRM_RADEON_UMS are both OFF (that's the /opposite/ of on!!  I mean it!!!) and CONFIG_DRM_RADEON is on (preferably compiled into the kernel).  Finally: if you you are using fglrx...  well, frankly, your drivers are a sinking ship, bail now while you are still breathing.  I'm not up to speed on the latest nvidia trouble but, read the wiki is probably the best advice.

[Wang Xuerui]

Hi, I also experienced this change earlier this year, and it seems the
old behavior can be restored by setting loglevel=7 in kernel cmdline.
Actually, not printing that much message can lead to a small
performance gain, as some console drivers tend to not be very fast;
but you certainly can have the messages if you want.

Hope that helps~

[Michael Orlitzky]

On 05/24/2014 04:20 PM, Hilco Wijbenga wrote:
> Hi all,
>
> Since kernel 3.12.13 (3.12.13-gentoo), the kernel boot messages have
> disappeared, i.e. they are no longer displayed at boot time. All I get
> is a line like "Loading kernel 3.12.13". (I just upgraded to
> 3.12.20-gentoo, so now it's something like "Loading kernel 3.12.20".)
>

What version was the previous kernel? These two options appeared
recently and are capable of clobbering your console:

* Mark VGA/VBE/EFI FB as generic system framebuffer (X86_SYSFB)
* Simple framebuffer support (FB_SIMPLE)

The first time I set them incorrectly, I got a blank screen until XFCE
popped up.

[Hilco Wijbenga]

Ka-ching! X86_SYSFB was indeed set and after I enabled FB_SIMPLE,
everything went back to normal. Thanks Michael!