XPost: linux.debian.maint.boot

Hi,

Am 9. Mai 2025 19:06:43 MESZ schrieb Felix Crux <felixc@felixcrux.com>:: installation-reports

Image version: Trixie Alpha 1 netinst amd64
[https://cdimage.debian.org/cdimage/trixie_di_alpha1/amd64/iso-cd/debian-trixie-DI-alpha1-amd64-netinst.iso]
Also tried weekly snapshot amd64 netinst image as of 2025-05-01:

The alpha1 image has gotten a bit outdated.
Maybe you could retry with the netinst.iso from https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/

... just to make sure we are not hunting a bug which is no longer there ...


Thanks
Holger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Nothing like hitting the Send button to have another idea pop up.

Cyril Brulebois <kibi@debian.org> (2025-05-10):

Felix Crux <felixc@felixcrux.com> (2025-05-09):

Issue #1 - Installation media device (/dev/sda) disappears, failing install

This is really weird to me.

Possible hint for people trying to understand this bug: forgetting
possible firmware fun for a second, could this be some kind of hardware
fault, like some power surge, some bad cable, some bad storage, etc.? Of course, looking into the installer's dmesg (made persistent in /var/log/installer/syslog alongside the rest) is likely to be a good
place to start instead of relying on a (very) (wild) hunch of mine…


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgemgsACgkQ/5FK8MKz VSD3hxAAqKLdck1oxNd2KDP+AKQILB1Ix1IkEJG0ONDC+YjxlJ+222q4B+oWFQPg sFiy9+LKxbqQIufGJjgL4iApVUwUfHOKT8JHO76J7Zj0vGJPGaJ6L82jve+Vuyjl 7qk2r7vTHrt+1Vuzz1G1UJpEpDuQUwEGgjRa0UlOAAIZkGFcT0+JJ6Hc6Jk17kDK Y+IG1TxaoYWu2ySI+58u+iETGVsUC7/dhLEOg+QP0r9iKc/fKIlhrAjTnsDDU2LU sLgjmuzEY2hxG5zZ2M4i17mQ/MGAEio5b9yl2WUZ/0NNMZENtKQuaECalHaNM++7 nRnP6SEzE5gbZxK3KedW0UqCbeHIQ0d5tv8yLsi4xzbiSTf9P5zdcJckDcM+oBAr 0n79hWMVjsNwiQvWgeVPcCGsdHM+aVPBeK31xoaT/UIjn8IES3iYymQyA6F4mLgo Ex0w74Sa94+RzJTjYVPMUxQT9A943ydJBhWZlXmtcvAtafILKDhLDAymXpq2Pw5p ApMGBYFwBfA6cKUO1XLMC6B7uaNrfHmwTOVBEELNd5WrL2i0zUVgf1oDOg9woXZd dqboz3kCe+/qRJWdyaw/qcCw/cb2uBpUSxGyE8od0PTzvZEhqh68CbnmCFPr3dNs YbEZIpf5FSfe8YA+hkunohPy9Eo2FVaFiEnHTFi23MZuD6pbcbY=
=Q1l9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot

On 10/05/2025 at 02:12, Cyril Brulebois wrote:

Possible hint for people trying to understand this bug: forgetting
possible firmware fun for a second, could this be some kind of hardware fault, like some power surge, some bad cable, some bad storage, etc.?

That was my first thought. But the fact that it happens after the
missing firmware detection may not be just a coincidence. Could it
happen when modules are unloaded and reloaded ?

Of course, looking into the installer's dmesg (made persistent in /var/log/installer/syslog alongside the rest) is likely to be a good
place to start instead of relying on a (very) (wild) hunch of mine…

Yes, we really need the installer syslog.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

On 11/05/2025 at 04:18, Felix Crux wrote:

I have attached the syslog from that latest installation attempt.

The log confirms that the issue is caused by check-missing-firmware when unloading and reloading the xhci-pci-renesas module.

I was able to reproduce it on my laptop by unloading and reloading
ehci-pci. I naively assumed that a mounted partition on the USB drive
would mark all drivers in the path as used and prohibit unloading them,
but it seems I was wrong.

On Sat, May 10 02:09, Cyril Brulebois wrote:

Unfortunately (to the best of my knowledge at the time, and I didn't
check if that changed recently) the firmware file is not distributable
and cannot be shipped in any packages. We could and probably should
filter out this specific filename in d-i, like iwl-debug-yoyo.bin
(that'd be in hw-detect's check-missing-firmware.sh).

The Renesas USB controller seems to work fine without it, and according
to the kernel log, a default firmware is loaded from non-volatile memory:

xhci-pci-renesas 0000:a3:00.0: failed to load firmware
renesas_usb_fw.mem, *fallback to ROM*

So I think this is the way to go. The fix is trivial, do you wish to
take care of it or shall I prepare a MR ?

Incidentally -- and I apologize for bundling yet another unrelated issue
into this; I can file a separate bug if that's better -- I wasn't able to
get the installer to automatically load the firmware from removable media
the way it suggests in the error message. I tried putting the file on the root of a FAT32-formatted drive, and also in a directory named "firmware", but in both cases the installer couldn't find it and load it. I had to mount the drive and copy it myself from /mnt to /lib/firmware, at which time the installer did recognize that it was present and the error cleared.

You could also just mount the partition containing the firmware file to
/media and re-run the firmware detection.

This is a known issue, the loose firmware file search is unreliable.
Firmware package search is much better. See #740503 and #1029962. I
proposed a fix but the required change was rather invasive and the time
was not ideal (before bookworm release), then it kind of stalled...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-05-11):

The log confirms that the issue is caused by check-missing-firmware
when unloading and reloading the xhci-pci-renesas module.

Thanks for looking/confirming.

I was able to reproduce it on my laptop by unloading and reloading
ehci-pci. I naively assumed that a mounted partition on the USB drive
would mark all drivers in the path as used and prohibit unloading
them, but it seems I was wrong.

Lots of fun can be had with USB… :(

The Renesas USB controller seems to work fine without it, and
according to the kernel log, a default firmware is loaded from
non-volatile memory:

xhci-pci-renesas 0000:a3:00.0: failed to load firmware renesas_usb_fw.mem, *fallback to ROM*

So I think this is the way to go. The fix is trivial, do you wish to
take care of it or shall I prepare a MR ?

That might leave other users on the side of the road, since the ROM
might not be available or might not have been equipped with firmware
data.

Seeing how that particular system would (presumably) work fine without
the check+reload plus how bad the side effects are, it might be prudent
to just ignore renesas_usb_fw.mem / xhci-pci-renesas as a first step.
I'm not sure if the iwl-debug-yoyo.bin code is the best way to do that,
but feel free to look into proposing an MR (based or not on that code
path, as you see fit).

For users that would actually miss the firmware (file and/or ROM) and
need it, meaning they would be missing devices, it's important that we
are able to put the finger on the issue. As long as we have the “failed
to load […]” log line on the kernel, and/or whatever “let's ignore this particular case” in check-missing-firmware, I would consider this topic covered.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmggufgACgkQ/5FK8MKz VSChBA/9H9VLecCf9LyFAXH9Jvpkd7JHl9VsER4AB3+3eXs1PbwMBkS3JBgGQwp9 78/MhOc+R7BCFZy2bT3ceYoXsj/NTl7PU/95dsRUYUw1LG7qeqs6AS9edD3J9YnB Ce9egxFCkPw8PTKLuuDkzKtJ9SxvfW1L4Zdk13tm1hep8fLHbqd94pD3XtGswy8q 0wqYSY7gkNiSCowtLa9sz3PyN8TC3KSxoOeZe8FiWgD1JJwDaldGuWJuDt4I6u01 ssdHPH04xYOsv8gGSrtLwyLE97jG7AVFya1/uI4spzvA7cK2B3om5WUaluzK0HiE kAGHAz80a0zF+nqqlm102kCbT3sn1v3lYi2bYBlbx+FnVM/qp9mnrq88pqvUCg7o K8ovOBTTxAzB6bUbx+P5ui7O8TOkgUTTC09j8x2W9CPdO4agfAGF5vAnA4eyJ4M0 ZYg/iwLkgGn6IwbFzAwUnwRg0yEPakAyWrbgHbXG12iw8ClYc7WVRZ64rQkm16H+ w9i1z4IN+np/xcBQc0gd1dlyxd5LM2gIn5y21qWf+uOOPZvT/HkkJ9vgzq92MuaL QKRx549Hv69VE4Wxuiyy4HVC1q27sjVRzA/ogx0cFwXMJ50evp5+Mx/lRu0qVuMW DkVleeWn9QsDdvnCG3/khYEWoeBC1n0MgBBTT+XtDJS9zmBhzsc=
=/Rhi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot

On 11/05/2025 at 16:53, Cyril Brulebois wrote:

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-05-11):

The Renesas USB controller seems to work fine without it, and
according to the kernel log, a default firmware is loaded from
non-volatile memory:

xhci-pci-renesas 0000:a3:00.0: failed to load firmware renesas_usb_fw.mem, >> *fallback to ROM*

So I think this is the way to go. The fix is trivial, do you wish to
take care of it or shall I prepare a MR ?

That might leave other users on the side of the road, since the ROM
might not be available or might not have been equipped with firmware
data.

You are right, the driver source code confirms it.

Seeing how that particular system would (presumably) work fine without
the check+reload plus how bad the side effects are, it might be prudent
to just ignore renesas_usb_fw.mem / xhci-pci-renesas as a first step.

What about adding an extra check ?
- "failed to load firmware renesas_usb_fw.mem, fallback to ROM" in
kernel messages;
- or some indication in /sys that the driver actually works (in my
experience, just being bound to a device is not reliable enough; maybe
the existence of child devices)

I'm not sure if the iwl-debug-yoyo.bin code is the best way to do that,
but feel free to look into proposing an MR (based or not on that code
path, as you see fit).

This code looks generic enough to be extended. MR opened: <https://salsa.debian.org/installer-team/hw-detect/-/merge_requests/13>

Felix might want to test the mini-ISO: <https://salsa.debian.org/pham/hw-detect/-/jobs/7568796/artifacts/file/debian/output/debian-202501XX+salsaci+20250511+10-amd64-gtkmini.iso>

It does not mount the installation media but you can test if it does not
ask for renesas_usb_fw.mem nor unload+reload xhci-pci-renesas. No need
to go further "detect network devices".

For users that would actually miss the firmware (file and/or ROM) and
need it, meaning they would be missing devices, it's important that we
are able to put the finger on the issue.

I agree.

As long as we have the “failed
to load […]” log line on the kernel, and/or whatever “let's ignore this particular case” in check-missing-firmware, I would consider this topic covered.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)