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
