Your message dated Mon, 22 Jul 2024 18:16:04 +0200
with message-id <3762619.0MlLrn18Ui@bagend>
and subject line Re: Bug#1074111: [arm64] boot stops at 'Starting kernel ...' 
without any further output when kernel built with recent binutils
has caused the Debian Bug report #1074112,
regarding [arm64] boot stops at 'Starting kernel ...' without any further 
output when kernel built with recent binutils
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1074112: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: linux
Version: 6.9.2-1~exp1
Severity: serious

Hi,

to reproduce this locally, on arm64, run the following:

    $ debvm-create -- --include=linux-image-generic/experimental "deb 
http://deb.debian.org/debian unstable main" "deb http://deb.debian.org/debian 
experimental main"
    $ debvm-run

The debvm-run output will stop at the point where it starts qemu and then print
nothing.  It works fine with kernel 6.8 in unstable.

Now comes my naive attempt to figure out what triggered this regression. Please
bear in mind that I'm far from an expert on this topic.

We observed this problem when we built the linux kernel for the MNT Reform
which is the Debian linux kernel plus some additional patches. Compiling the
same kernel version 6.8.12 in *unstable* within a more recent build environment
results in a vmlinuz that just prints on boot:

    Starting kernel ...

And then nothing else. Since neither the linux sources in debian unstable
changed, nor our patch stack changed between these rebuilds, the culprit is
likely in the build environment. Kernel 6.9 from experimental exhibits the same
problems. We also observed that copying the vmlinuz from an earlier build in
the good chroot environment made the system boot fine again. We also observed
how the good vmlinuz has a size of 31M and the bad vmlinuz a size of only 26M.
This is with the same sources, just different build chroot environment. An
old-enough build environment can be constructed using snapshot.d.o.

One of the differences in the build environment between good and bad builds is
binutils-arm-linux-gnueabihf with version 2.42-4 in the good environment and
version 2.42.50.20240618-1 in the bad environment. To test whether this indeed
triggers the problem, we tested building our kernel with current unstable but
with binutils (= 2.42-4) and gcc-13 (= 13.2.0-25). We also have to choose an
older gcc from snapshot.d.o because recent gcc-13 requires recent binutils.
This makes the kernel work again.

So, given that the problem affects linux in unstable *if* built with a more
recent build environment, the problem might not be in src:linux but elsewhere
(maybe binutils or gcc-13). I'm still filing it here as I lack the skills to
investigate this problem further. Since the issue shows up with qemu, I'm sure
that you can get to the bottom of it and can re-assign this bug to the package
to which it belongs.

Gratitude is due to Chris Hofstaedtler who convinced me that maybe this is a
problem even with vanilla Debian kernel and not only with the Debian kernel
with our patches on top.

Thanks!

cheers, josch

--- End Message ---
--- Begin Message ---
Version: 2.42.90.20240720-1

On Monday, 22 July 2024 17:53:01 CEST Emanuele Rocca wrote:
> Hi Diederik,

Hi Emanuele,

> On 2024-07-22 10:15, Diederik de Haas wrote:
> > The referenced commit is part of 2.42.90.20240720-1, so this bug can be
> > closed (and the workaround for the kernel dropped)?
> 
> Indeed, I just built Linux 6.10 with CONFIG_RELR=y and binutils
> 2.42.90.20240720. It booted fine:
> 
> Linux version 6.9.10-arm64 (debian-ker...@lists.debian.org)
> (aarch64-linux-gnu-gcc-13 (Debian 13.3.0-3) 13.3.0, GNU ld (GNU Binutils
> for Debian) 2.42.90.20240720) #1 SMP Debian 6.9.10-2 (2024-07-22)

Awesome, closing this but with that version then ...

> MR opened to revert the workaround and close this bug:
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1135

I already mentioned this in the MR, but the workaround can be reverted 
*because* binutils has been fixed. As this bug and 1074112 are assigned to 
binutils, I'm closing both bugs with the the version that fixed them.

Thus, the MR doesn't fix the bug(s).

Cheers,
  Diederik

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---

Reply via email to