Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD
I just discovered that a MR is already open that will fix this bug and wanted to add the link here. https://salsa.debian.org/live-team/calamares-settings-debian/-/merge_requests/3 It would be great to get this merged to fix live installs of testing. Thanks. Brandon
Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD
I found the solution to this bug, and was able to successfully install a testing live image and boot it. The problem is actually in the calamares-settings-debian package. The problem is caused by changes in the syntax of an upstream Calamares configuration file. Calamares has a mounts.conf which mounts additional filesystems needed for the chroot to work correctly, like /sys, /dev, and /proc. This file includes a way to indicate that filesystems should only be mounted on uefi systems, and this has changed. IN the old config syntax, there were two groups of filesystems, "extraMounts:" and "extraMountsEfi:". In the new config syntax, "extraMountsEfi:" was removed, with all filesystems instead being listed under "extraMounts:". An additional key value pair is added to each entry which must be mounted for uefi systems "efi: true". After deleting extraMountsEfi from mounts.conf on the live image, and adding "efi: true" at the end of the file in the "efivarfs" entry, the install worked with an efi variable being created in my firmware. The file that needs to be updated is in the calamares-settings-debian package "calamares/modules/mount.conf". The file containing corrected syntax in upstream calamares is "src/modules/mount/mount.conf". It may be worth synchronizing the other changes in this file as well.
Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD
package: calamares version 3.3.1-1 Hi: I attempted to install testing using the Debian live Mate CD. The install completes, however, no boot entry is added to the efi firmware. A partial install of grub is occurring, since the grub files are installed to the efi partition. I tried to determine why the installer isn't creating the entry by examining the log file at /root/.cache/calamares/session.log on the live cd. I can see the grub-install command being run there, however, the output from the command isn't being recorded in the file, and I haven't found this output yet somewhere else to determine why things might be failing. I'll keep looking and update this bug if I find more info on this On systems with secure boot turned off, the system might boot if no other operating system is installed, because the firmware will load the default path /boot/bootx64.efi on one of the disks in the system. I was able to produce this on a system with secure boot turned off (in my case, the installed Debian booted, because my ssd was the only disk in the system). When secure boot is turned on, boot will fail, since no firmware entry has been created pointing to shimx64.efi. I was able to reproduce this failing boot scenario by enabling secure boot. One thing worth noting is that when I boot into the system with secure boot off, and run grub-install, the firmware entry pointing to shimx64.efi is correctly created at that point, so this is definitely a problem in the installer. After installing grub from the installed system, I can then enable secure boot, and boot the installed Debian successfully.
Bug#1059227: Firmware Missing from recent live builds (I think due to usr transition)
package: live-build version: 1:20230502 I noticed that in recent weekly builds, many firmware packages are missing from the live desktop images. I believe that the problem is in this file https://salsa.debian.org/live-team/live-build/-/blob/master/functions/firmwarelists.sh. Its logic depends on firmware being in /lib/firmware, however, firmware has moved as a part of the usr transition to /usr/lib/firmware. I didn't have a chance to test, however, it seems likely that updating this path to /usr/lib/firmware in that file would get detection for firmware packages working again.
Bug#1055541: In Trixie, /etc/localtime incorrectly set to UTC in some cases due to the installer including mappings to removed legacy timezones
package: tzsetup In bug #1040997 legacy symlinks were moved out of the tzdata package to tzdata-legacy. The "post-base-installer.d/05tzsetup" script does not set the /etc/localtime symlink because db_get is returning these legacy time zones that no longer exist in the tsdata package. I think the fix is to modify the mappings in debian/common.templates.in to remove the legacy time zones and replace them with the versions shipped in the new version of tzdata.
Bug#1055353: Debian installer not setting locale in Trixie daily builds
On Sat, Nov 4, 2023, at 2:27 PM, Brandon Werner wrote: > > > Hi, > After installing via the daily images, my locale isn't set. I took a brief > look, and my best guess is the trouble is being caused in the file > post-base-installer.d/05localechooser. There, I noticed > "DESTFILE="/target/etc/default/locale"". > I believe this file was retired recently in Debian. I tried a reinstall, changing the above line to "DESTFILE="/target/etc/locale.conf"" in the installer after I booted the daily netinst, and my locale was set in the installed system
Bug#1055353: Debian installer not setting locale in Trixie daily builds
package: locale-chooser Hi, After installing via the daily images, my locale isn't set. I took a brief look, and my best guess is the trouble is being caused in the file post-base-installer.d/05localechooser. There, I noticed "DESTFILE="/target/etc/default/locale"". I believe this file was retired recently in Debian. If I manually set my locale in /etc/locale.conf, things work as expected.
Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included
On Mon, Feb 6, 2023, at 7:34 AM, Cyril Brulebois wrote: > > That's not to say I won't try and get a tentative patch before then… > Would you be happy to test a custom netinst that I would build locally > (i.e. outside cdimage.debian.org and the official infrastructure)? I'd be happy to test an image you build locally on your machine to streamline the testing process.
Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included
On Mon, Feb 6, 2023, at 5:33 AM, Cyril Brulebois wrote: > Hi Brandon, > > Brandon Werner (2023-02-06): >> Thanks for your response. I have included the syslog lines from the >> installer log you requested. > > OK, that's basically what I thought was happening, but it's always a > good idea to check a hypothesis before deciding what to do about it. :) > > I think I might have mentioned the following in some discussion, or > in some commit, but basically: > - we have a list of requested files; > - we have a list of requesting modules; > - some modules get reloaded. > > If we maintain a module/file mapping, we could: > - decide which modules need to be reloaded, instead of iterating on all >of them (that's part of the reason why I had this idea in mind in the >first place, looking around how to “reload dance” was implemented: >walking through all modules unconditionally); > - decide that a module is “good to go” as soon as it's been reloaded >once, i.e. some of the files it requested have been found. > > The second part would make the point about “required” vs. “optional” > firmware moot, and would prevent extra dialogs. One could argue that > maybe some other *.deb somewhere could be more recent or could have > extra files, but then we don't implement anything when it comes to > multiplicity anyway, so that wouldn't be a regression. > > Alternatively, we could keep the unconditionally reload dance, while > still keeping track of files requested by each module over time. > When the list gets smaller, its files start getting ignored. > > > Does that make sense to you? This makes sense, and both solutions seem like they would work. It seems like the second solution of keeping the unconditional reload and testing if the list of files was smaller after the reload would be easier to implement for Bookworm, but I think you and the rest of the installer team are better informed to make that decision. :) I think assuming the module is working if the list of requested files is smaller after a reload is a fairly safe bet for network hardware, but If the installer team implemented either of these solutions, I could test on a bunch of old and new machines that are available at a computer club I attend. I unfortunately don't feel like I personally understand the installer well enough to fix this properly, and any merge request I would create would be a sad hack. Hopefully many folks will be testing Alpha 2 of Bookworm as well, to find any problems that would result from a change like this.
Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included
On Mon, Feb 6, 2023, at 4:36 AM, Cyril Brulebois wrote: > Hi Brandon, > > Brandon Werner (2023-02-05): >> I saw the recent work to the installer surrounding firmware handling >> and thought I would test on my machines to see how this all was >> working. I used one of the daily sid_d-i netinst cds including >> firmware. I noticed some problems around the installer asking for >> firmware that was not neded for ath10k. I first tried on a laptop that >> had QCA-6174 hw2.1. I noticed the prompt telling me about missing >> firmware and asking if I wanted to load it from additional media, >> which was puzzling for the firmware image. If I select no, the >> installer continues, however, I thought this could confuse users, so >> I dug into it. > > Thanks for the tests and the report. > >> Before firmware atheros was loaded, the kernel tried to load versions >> 6 through 2 of the firmware files as well as calibration firmware >> files. After firmware atheros was installed, the card was brought up, >> and this time, only three files were missing. The cal and pre-cal >> files appear to be optional according to the driver source, and do not >> exist in linux-firmware upstream, so I think them missing is no >> problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo >> so maybe this is in the driver for future use? I guess the installer >> still thinks there is missing firmware because of the kernel failing >> to load these 3 unnecessary files. After version 5 of the firmware was >> found, the kernel stopped trying to load versions 4 3 2, so there was >> many fewer missing files on the second run of check-missing-firmware. > > We would need to see more of your log file. It starts with mainloop > iteration #1, while the first check_missing call has happened already. Thanks for your response. I have included the syslog lines from the installer log you requested. Feb 5 10:35:26 check-missing-firmware: looking at dmesg for the first time Feb 5 10:35:26 check-missing-firmware: saving timestamp for a later use: [ 57.345819] Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-:01:00.0.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-:01:00.0.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/cal-pci-:01:00.0.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/cal-pci-:01:00.0.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci Feb 5 10:35:26 check-missing-firmware: missing firmware files (ath10k/pre-cal-pci-:01:00.0.bin ath10k/pre-cal-pci-:01:00.0.bin ath10k/cal-pci-:01:00.0.bin ath10k/cal-pci-:01:00.0.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-5.bin ath10k/QCA6174/hw2.1/firmware-5.bin ath10k/QCA6174/hw2.1/firmware-4.bin ath10k/QCA6174/hw2.1/firmware-4.bin ath10k/QCA6174/hw2.1/firmware-3.bin ath10k/QCA6174/hw2.1/firmware-3.bin ath10k/QCA6174/hw2.1/firmware-2.bin ath10k/QCA6174/hw2.1/firmware-2.bin) for ath10k_pci Feb 5 10:35:26 check-missing-firmware: mainloop iteration #1 Feb 5 10:35:26 check-missing-firmware: lookup with /cdrom/firmware/Contents-firmware Feb 5 10:35:26 check-missing-firmware: installing firmware package /cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware) Feb 5 10:35:28 check-missing-firmware: removing and loading kernel module ath10k_pci Feb 5 10:35:28 kernel: [ 60.711599] D
Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included
package: hw-detect version: 1.154 Hello, I saw the recent work to the installer surrounding firmware handling and thought I would test on my machines to see how this all was working. I used one of the daily sid_d-i netinst cds including firmware. I noticed some problems around the installer asking for firmware that was not neded for ath10k. I first tried on a laptop that had QCA-6174 hw2.1. I noticed the prompt telling me about missing firmware and asking if I wanted to load it from additional media, which was puzzling for the firmware image. If I select no, the installer continues, however, I thought this could confuse users, so I dug into it. Before firmware atheros was loaded, the kernel tried to load versions 6 through 2 of the firmware files as well as calibration firmware files. After firmware atheros was installed, the card was brought up, and this time, only three files were missing. The cal and pre-cal files appear to be optional according to the driver source, and do not exist in linux-firmware upstream, so I think them missing is no problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo so maybe this is in the driver for future use? I guess the installer still thinks there is missing firmware because of the kernel failing to load these 3 unnecessary files. After version 5 of the firmware was found, the kernel stopped trying to load versions 4 3 2, so there was many fewer missing files on the second run of check-missing-firmware. I have another laptop with hw3.2 of QCA-6174 and on that machine, only pre-cal and cal are missing after firmware-atheros is loaded by the installer. I looked at hw-detect, and noticed there was a section in check-missing-firmware.sh ignoreing intel wifi debugging firmware, but I think trying to ignore all the correct files in that location might be a bit tricky, especially if other net drivers try to load optional firmware. It also seems possible that the PCI IDs searched by the driver could be different for cal and pre-cal for different ath10k hardware although I didn't dig into this. I hope the information I provided is enough for package maintainers to determine a correct solution. Thanks for all the great work on the installer recently to make firmware handling work better. Below, a bit of text from the installer log, to show the driver is loading, but the installer still thinking there is missing firmware. Feb 5 10:35:26 check-missing-firmware: mainloop iteration #1 Feb 5 10:35:26 check-missing-firmware: lookup with /cdrom/firmware/Contents-firmware Feb 5 10:35:26 check-missing-firmware: installing firmware package /cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware) Feb 5 10:35:28 check-missing-firmware: removing and loading kernel module ath10k_pci Feb 5 10:35:28 kernel: [ 60.711599] DMAR: DRHD: handling fault status reg 2 Feb 5 10:35:28 kernel: [ 60.711605] DMAR: [DMA Write NO_PASID] Request device [01:00.0] fault addr 0x7ee0 [fault reason 0x05] PTE Write access is not set Feb 5 10:35:28 kernel: [ 60.711661] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 Feb 5 10:35:28 kernel: [ 60.977712] ath10k_pci :01:00.0: firmware: failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2) Feb 5 10:35:28 kernel: [ 60.977724] ath10k_pci :01:00.0: firmware: failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2) Feb 5 10:35:28 kernel: [ 60.977735] ath10k_pci :01:00.0: firmware: failed to load ath10k/cal-pci-:01:00.0.bin (-2) Feb 5 10:35:28 kernel: [ 60.977744] ath10k_pci :01:00.0: firmware: failed to load ath10k/cal-pci-:01:00.0.bin (-2) Feb 5 10:35:28 kernel: [ 60.977755] ath10k_pci :01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2) Feb 5 10:35:28 kernel: [ 60.977762] ath10k_pci :01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2) Feb 5 10:35:28 kernel: [ 60.977973] ath10k_pci :01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/firmware-5.bin Feb 5 10:35:28 kernel: [ 60.977980] ath10k_pci :01:00.0: qca6174 hw2.1 target 0x0501 chip_id 0x003405ff sub 144d:4125 Feb 5 10:35:28 kernel: [ 60.977986] ath10k_pci :01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 Feb 5 10:35:28 kernel: [ 60.978697] ath10k_pci :01:00.0: firmware ver SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 10bf8e08 Feb 5 10:35:28 kernel: [ 61.040011] ath10k_pci :01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/board-2.bin Feb 5 10:35:28 kernel: [ 61.040387] ath10k_pci :01:00.0: board_file api 2 bmi_id N/A crc32 ae2e275a Feb 5 10:35:29 check-missing-firmware: looking at dmesg again, restarting from timestamp: [ 57.345819] Feb 5 10:35:29 check-missing-firmware: timestamp found, truncating dmesg accordingly Feb 5 10:35:29 check-missing-firmware: saving timestamp for a
Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded
On Wed, Nov 4, 2020, at 1:13 AM, Brandon Werner wrote: > > > On Tue, Nov 3, 2020, at 10:52 PM, Brandon Werner wrote: > > package: src:linux > > > > Hi, > > I downloaded one of the firmware netinstall builds of Debian from today > > (11/03/2020) to try installing on my netbook with the 8821ce wifi card > > since Debian now has the 5.9 kernel. During the text install with > > speech, I received an error that the network card could not be found. I > > opened a console and looking at dmesg showed the driver not finding the > > firmware with a -2 error, however, I noticed that the requested files > > had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and > > reloaded it using modprobe and the firmware was found, after which the > > network interface was successfully brought up. > I took a look at the installer logs and found something that looks like > it could be the likely problem. > > Nov 3 22:09:17 check-missing-firmware: removing and loading kernel > module rtw_8821ce > > I think some substitution is going wrong in the installer because it > seems like the module should be called rtw88_8821ce. It looks like what is happening is that the driver prints its messages to dmesg with a different name than what the module is actually called. When it prints its messages about missing firmware, it uses rtl_8821ce. The installer matches on that when unloading and loading modules to get the missing firmware, which results in an incorrect module name being used. Is there a list of cases in the installer for this? It needs to use rtw88_8821ce when it unloads and reloads the module. > > I was able to continue through the rest of the install without issue. I am > > not sure what logs > > would help but would be happy to provide anything requested to diagnose > > this issue.
Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded
On Tue, Nov 3, 2020, at 10:52 PM, Brandon Werner wrote: > package: src:linux > > Hi, > I downloaded one of the firmware netinstall builds of Debian from today > (11/03/2020) to try installing on my netbook with the 8821ce wifi card > since Debian now has the 5.9 kernel. During the text install with > speech, I received an error that the network card could not be found. I > opened a console and looking at dmesg showed the driver not finding the > firmware with a -2 error, however, I noticed that the requested files > had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and > reloaded it using modprobe and the firmware was found, after which the > network interface was successfully brought up. I took a look at the installer logs and found something that looks like it could be the likely problem. Nov 3 22:09:17 check-missing-firmware: removing and loading kernel module rtw_8821ce I think some substitution is going wrong in the installer because it seems like the module should be called rtw88_8821ce. > I was able to continue through the rest of the install without issue. I am > not sure what logs > would help but would be happy to provide anything requested to diagnose > this issue.
Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded
package: src:linux Hi, I downloaded one of the firmware netinstall builds of Debian from today (11/03/2020) to try installing on my netbook with the 8821ce wifi card since Debian now has the 5.9 kernel. During the text install with speech, I received an error that the network card could not be found. I opened a console and looking at dmesg showed the driver not finding the firmware with a -2 error, however, I noticed that the requested files had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and reloaded it using modprobe and the firmware was found, after which the network interface was successfully brought up. I was able to continue through the rest of the install without issue. I am not sure what logs would help but would be happy to provide anything requested to diagnose this issue.
Bug#971628: Whipper: Missing dependency on python3-distutils
Package: whipper Version: 0.9.0-4 Hello, I tried to install and use whipper and got a traceback. Installling the python3-distutils package solved the issue.
