Re: 5.6-### doesn't boot
From: Ingo Molnar
Date: Fri Jan 31 2020 - 01:43:36 EST
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 30, 2020 at 9:32 AM Jörg Otte <jrg.otte@xxxxxxxxx> wrote:
> >
> > my notebook doesn't boot with current kernel. Booting stops right after
> > displaying "loading initial ramdisk..". No further displays.
> > Also nothing is wriiten to the logs.
> >
> > last known good kernel is : vmlinuz-5.5.0-00849-gb0be0eff1a5a
> > first known bad kernel is : vmlinuz-5.5.0-01154-gc677124e631d
>
> It would be lovely if you can bisect a bit. But my merges in that
> range are all from Ingo:
>
> Ingo Molnar (7):
> header cleanup
> objtool updates
> RCU updates
> EFI updates
> locking updates
> perf updates
> scheduler updates
If I had to guess then perhaps the EFI changes look the most dangerous
ones from these trees - but in principle most of these trees could
contain a boot crasher/hang bug.
> but not having any messages at all makes it hard to guess where it
> would be.
To improve debug output:
Removing any 'fbcon' options in /boot/grub/grub.cfg and adding this to
the boot options might improve the debug output:
earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn
So for example if the relevant kernel boot entry in grub.cfg looks like
this:
linux /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro splash $vt_handoff
Then editing it to the following could in principle produce (much) more
verbose boot output:
linux /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn $vt_handoff
If this produces more output than just "loading initial ramdisk..' then a
photo of the hung screen would be sufficient, no need to transcribe it.
> A few bisect runs would narrow it down a fair amount. Bisecting all the
> way would be even better, of course,
Agreed!
If compiling full kernels for bisections takes too long (for example
because the .config is from a distro kernel) then running "make
localmodconfig" to create a config tailored to the currently active
modules will cut down significantly on build time.
Also, a warning: if the normal boot log contains spurious warnings then
the new 'panic_on_warn' option will cause additional trouble on good
kernels.
Thanks,
Ingo