Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #71537 > unrolled thread

Bug#985956: #985956 - missing kernel module in installer

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#985956: #985956 - missing kernel module in installer Wookey <wookey@wookware.org> - 2021-05-14 04:20 +0200
    Bug#985956: #985956 - missing kernel module in installer Pete Batard <pete@akeo.ie> - 2021-05-14 13:50 +0200
      Bug#985956: #985956 - missing kernel module in installer Salvatore Bonaccorso <carnil@debian.org> - 2021-05-16 17:00 +0200

#71537 — Bug#985956: #985956 - missing kernel module in installer

[Multipart message — attachments visible in raw view] — view raw

Pete Batard <pete@akeo.ie> wrote:

> Thus, I'm going to leave people who are more familiar with Debian linux 
> configuration with the action of ensuring that mdio-bcm-unimac.ko does 
> get included in the install image.

OK. So I took a look at this, and it is indeed somewhat involved getting the module in the right place.

It turns out that the kernel build is already building it, and it's
inthe main kernel image, it's just not in the installer nic-modules package.

So the patch to fix this is:
diff -Nru linux-5.10.28/debian/installer/modules/arm64/nic-modules linux-5.10.28/debian/installer/modules/arm64/nic-modules
--- linux-5.10.28/debian/installer/modules/arm64/nic-modules    2021-04-07 08:28:57.000000000 +0100
+++ linux-5.10.28/debian/installer/modules/arm64/nic-modules    2021-04-26 19:20:12.000000000 +0100
@@ -1 +1,3 @@
 #include <nic-modules>
+
+mdio-bcm-unimac

Then (to get a test installer image) build the linux package
Then install the resulting linux-support-5.10.0-6, linux-image-5.10.0-6-arm64-unsigned, linux-image-5.10.0-6-cloud-arm64-unsigned, linux-image-5.10.0-6-rt-arm64-unsigned packages, and build linux-signed-arm64 to get a set of udebs
Then copy those into build/localudebs and build debian-installer

I've done this, and if you want to test the mini.iso image at: http://wookware.org/software/rpi4-test.iso
That would be good. (I don't have an rpi4 to test on)
sha256: 595e57c2bcf153d05986261cf82fbfd0593787fb755139b8ceb726be2b471e3e

The one thing I'm not clear about is whether making the
mdio-bcm-unimac module available in the nic-modules-5.10.0-6-arm64-di
package on the installer image is sufficient, or if something needs to
be done about the initramfs too? I think this should be enough for the
installer to boot and install stuff from its own iso image and thus
get the networking working. Note that the image above will install the
standard linux-image-5.10.0-6-arm64 (v5.10.28-1 from the debian repo)
in /boot, but that has mdio-bcm-unimac available so should work fine.

So I _think_ that means we don't need to change the initrd because
both the installer and normal boot have the ethernet mdio driver
available on localmedia, but I may be misunderstanding things.

Right at the start of this bug you said:
> Note that this is a rather critical regression (since it used to work 
> fine with previous bullseye ISOs)

I don't understand this. This module has presumably been missing from
the installer packages all along, so I don't see how it could have
worked before? 

If it really is a regression then this could be deemed an RC bug and
it is possible that it will get fixed for stable, but if it isn't then
I think we've missed the boat on kernel changes for the next stable.
However this is the sort of important platform-support bug that should
go into the -r1 point release soon after the stable release.

First we have to prove that this fix does actually work and is
correct. Then we can ask the kernel people what the situation is. I
agree that broken rPi4 ethernet on the installer is quite bad. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

[toc] | [next] | [standalone]

#71540

Hi Wookey,

Thanks a lot for looking into this!

On 2021.05.14 03:08, Wookey wrote:

> I've done this, and if you want to test the mini.iso image at: http://wookware.org/software/rpi4-test.iso
> That would be good. (I don't have an rpi4 to test on)

Just tested it, and I can confirm it fixes the NIC setup in the installer.

Just a small note that, because your image is ISOHybrid and only had EFI 
support when copied in DD mode (basically, it was missing formal 
/EFI/Boot/bootaa64.efi and /EFI/Boot/grubaa64.efi in the ISO9660 file 
system structure) I had to add those manually for boot to work, since we 
can't use straight DD copy for Pi boot.

In case you are interested, some information about how an installation 
media can be created for the Pi 4, and why a mere dd copy of an 
ISOHybrid won't do, can be found at: 
https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839#p1713105.

> The one thing I'm not clear about is whether making the
> mdio-bcm-unimac module available in the nic-modules-5.10.0-6-arm64-di
> package on the installer image is sufficient, or if something needs to
> be done about the initramfs too?

For the Pi 4 netint purpose, the fix you applied should be enough.
For good measure, I went through a full system install using your ISO 
and saw no issues. Especially I validated that networking in the 
resulting installed system also worked fine.

> So I _think_ that means we don't need to change the initrd because
> both the installer and normal boot have the ethernet mdio driver
> available on localmedia, but I may be misunderstanding things.

My testing indicates that the assumption above should be correct.

> Right at the start of this bug you said:
>> Note that this is a rather critical regression (since it used to work
>> fine with previous bullseye ISOs)
> 
> I don't understand this. This module has presumably been missing from
> the installer packages all along, so I don't see how it could have
> worked before?

My guess is that kernel must have split Genet into Genet + MDIO recently 
because myself and a bunch of other people validated that the Bullseye 
testing netinst ISOs worked fine up to January this year, and we started 
to get "Unable to find mii" kernel messages with the 2021.01.04 ISO:
https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839&start=50#p1791942

> If it really is a regression

 From our perspective it is, though it does not appear to be one that 
was introduced by Debian, but something that was most likely inherited 
from kernel.

> then this could be deemed an RC bug and
> it is possible that it will get fixed for stable,

That would really help, because we spent a lot of time last year ironing 
things out to make sure that a distro like Bullseye could be installed 
easily on the Raspberry Pi 4 on release day (by fixing bugs such as 
#967918), and it's been very disappointing to see that what looks like a 
relatively straightforward issue to fix, such as adding a missing 
module, could bring us short of that goal. Once Bullseye is released, I 
expect a lot more people than the ones we had for testing, to want to 
give it a go, and having to tell them to wait for -r1 may just make them 
switch to a different distro.

But of course, it's up to Debian maintainership to decide the pros and 
cons of delaying the integration of this fix.

At any rate, thanks a lot for figuring out a proper fix.

Regards,

/Pete

[toc] | [prev] | [next] | [standalone]

#71662

Control: tags -1 + pending confirmed

Hi,

On Fri, May 14, 2021 at 12:44:17PM +0100, Pete Batard wrote:
> Hi Wookey,
> 
> Thanks a lot for looking into this!
> 
> On 2021.05.14 03:08, Wookey wrote:
> 
> > I've done this, and if you want to test the mini.iso image at: http://wookware.org/software/rpi4-test.iso
> > That would be good. (I don't have an rpi4 to test on)
> 
> Just tested it, and I can confirm it fixes the NIC setup in the installer.
> 
> Just a small note that, because your image is ISOHybrid and only had EFI
> support when copied in DD mode (basically, it was missing formal
> /EFI/Boot/bootaa64.efi and /EFI/Boot/grubaa64.efi in the ISO9660 file system
> structure) I had to add those manually for boot to work, since we can't use
> straight DD copy for Pi boot.
> 
> In case you are interested, some information about how an installation media
> can be created for the Pi 4, and why a mere dd copy of an ISOHybrid won't
> do, can be found at:
> https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839#p1713105.
> 
> > The one thing I'm not clear about is whether making the
> > mdio-bcm-unimac module available in the nic-modules-5.10.0-6-arm64-di
> > package on the installer image is sufficient, or if something needs to
> > be done about the initramfs too?
> 
> For the Pi 4 netint purpose, the fix you applied should be enough.
> For good measure, I went through a full system install using your ISO and
> saw no issues. Especially I validated that networking in the resulting
> installed system also worked fine.
> 
> > So I _think_ that means we don't need to change the initrd because
> > both the installer and normal boot have the ethernet mdio driver
> > available on localmedia, but I may be misunderstanding things.
> 
> My testing indicates that the assumption above should be correct.
> 
> > Right at the start of this bug you said:
> > > Note that this is a rather critical regression (since it used to work
> > > fine with previous bullseye ISOs)
> > 
> > I don't understand this. This module has presumably been missing from
> > the installer packages all along, so I don't see how it could have
> > worked before?
> 
> My guess is that kernel must have split Genet into Genet + MDIO recently
> because myself and a bunch of other people validated that the Bullseye
> testing netinst ISOs worked fine up to January this year, and we started to
> get "Unable to find mii" kernel messages with the 2021.01.04 ISO:
> https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839&start=50#p1791942
> 
> > If it really is a regression
> 
> From our perspective it is, though it does not appear to be one that was
> introduced by Debian, but something that was most likely inherited from
> kernel.
> 
> > then this could be deemed an RC bug and
> > it is possible that it will get fixed for stable,
> 
> That would really help, because we spent a lot of time last year ironing
> things out to make sure that a distro like Bullseye could be installed
> easily on the Raspberry Pi 4 on release day (by fixing bugs such as
> #967918), and it's been very disappointing to see that what looks like a
> relatively straightforward issue to fix, such as adding a missing module,
> could bring us short of that goal. Once Bullseye is released, I expect a lot
> more people than the ones we had for testing, to want to give it a go, and
> having to tell them to wait for -r1 may just make them switch to a different
> distro.
> 
> But of course, it's up to Debian maintainership to decide the pros and cons
> of delaying the integration of this fix.
> 
> At any rate, thanks a lot for figuring out a proper fix.

FTR, commited the change for the next upload:
https://salsa.debian.org/kernel-team/linux/-/commit/bb0dbee4901603637d817736dbbb8e900b445d08

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web