Messages in this thread | | | From | Jörg Otte <> | Date | Fri, 31 Jan 2020 11:35:04 +0100 | Subject | Re: 5.6-### doesn't boot |
| |
Am Fr., 31. Jan. 2020 um 07:43 Uhr schrieb Ingo Molnar <mingo@kernel.org>: > > > * Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Thu, Jan 30, 2020 at 9:32 AM Jörg Otte <jrg.otte@gmail.com> 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
....
| |