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.


On Sat, May 24, 2014 at 8:19 PM, Hilco Wijbenga <hilco.wijbe...@gmail.com>wrote:

> 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.
>
>

Reply via email to