linux-kernel - Re: 5.6-### doesn't boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200131064327.GB130017@gmail.com>
Date:   Fri, 31 Jan 2020 07:43:27 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jörg Otte <jrg.otte@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: 5.6-### doesn't boot

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Thu, Jan 30, 2020 at 9:32 AM Jörg Otte <jrg.otte@...il.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.

Thanks,

	Ingo