Re: 5.6-### doesn't boot

From: JÃrg Otte
Date: Fri Jan 31 2020 - 05:35:21 EST


Am Fr., 31. Jan. 2020 um 07:43 Uhr schrieb Ingo Molnar <mingo@xxxxxxxxxx>:
>
>
> * 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.

It's bisected.
The first bad commit is :
1db91035d01aa8bfa2350c00ccb63d629b4041ad
efi: Add tracking for dynamically allocated memmaps

Unfortunately I can not revert because of compile errors!

In file included from /media/jojo/deftoshiba/kernel/linux/init/main.c:48:
/media/jojo/deftoshiba/kernel/linux/include/linux/efi.h:975:1: error:
version control conflict marker in file
<<<<<<< HEAD
^~~~~~~
/media/jojo/deftoshiba/kernel/linux/include/linux/efi.h:980:1: error:
version control conflict marker in file
=======
^~~~~~~
/media/jojo/deftoshiba/kernel/linux/include/linux/efi.h:982:1: error:
version control conflict marker in file
>>>>>>> parent of 1db91035d01a... efi: Add tracking for dynamically allocated memmaps


....