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:
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…
I have attached the syslog from that latest installation attempt.
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).
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.
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.
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 ?
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 100:35:24 |
Calls: | 9,681 |
Calls today: | 2 |
Files: | 13,725 |
Messages: | 6,174,831 |