Re: Bug#1077845: release.debian.org: Should non-free-firmware require being built on buildd?
On 03/08/2024 18:30, Niels Thykier wrote: Had a quick look at the testing `Sources` file for non-free-firmware. We are 10/15 on `Autobuild: yes` with remaining 5 not having the header. ... The 5 that are not `Autobuild: yes` would be: atmel-firmware bluez-firmware dahdi-firmware live-tasks-non-free-firmware This is a 'meta' package, that only refers to other firmware packages, it does not contain firmware itself. midisport-firmware (as far as my wetware was able to eyeball) With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076043: task-kde-desktop: synaptic not installed by default with task-kde-desktop
+debian-kde Hello vajdao, On 09/07/2024 22:14, vajdao wrote: When installing KDE Desktop Environemt (task-kde-desktop) Synaptic package manager doesn't get installed by default. On other DE's such as gnome, lxqt, xfce, mate etc-etc Synaptic is installed with the system. Please provide Synaptic to be installed by default in KDE too, as it is a handy tool to have out of the box. There is already a software center installed per default: plasma-discover. The dependency chain is: task-kde-desktop -> kde-standard -> kde-plasma-desktop -> plasma-workspace -> plasma-desktop -> plasma-discover. Can that fullfill this wishlist ticket? Or @kde-list: would you like to have Synapic (or something else) added? With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Problem with Debian debian-live-12.6.0-amd64-mate.iso
Hello Andre, Steve, On 07/07/2024 17:41, Steve McIntyre wrote: On Sun, Jul 07, 2024 at 12:47:28PM +0200, Andre Gompel wrote: The answer is the typical message "Verifying SBAT shim failed, etc" Let me add that with the very same hardware, and software (sha256sum validation, and very reliable Fedora media writer), everything works fine with two other distros Fedora, and the latest Open Suse Leap, both shim-EFI signed. > What exact OSes have you booted on this hardware in the last 6 months > or so? It's likely that one of those has revoked older versions of > shim. The latest openSUSE Leap contains shim 15.8, which causes this issue. https://download.opensuse.org/distribution/leap/15.6/repo/oss/x86_64/ You can see the shim lockdown being requested: cat /sys/firmware/efi/efivars/SbatLevelRT* The output (after installing openSUSE 15.6 LEAP) is: sbat,1,2024010900 shim,4 grub,3 grub.debian,4 The line 'shim,4' causes the mentioned error message. As Steve already wrote, the next stable version will fix this. If you are unable to access the UEFI firmware, and to reset the boot keys, you can't boot many other ISO files either (e.g. older versions of LEAP). With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: SBAT revocation. Do we need a 12.6.1 release? (Was: Heads-up: Verifying shim SBAT data failed: Security Policy Violation)
On 05/07/2024 02:20, Steve McIntyre wrote: ... The thornier problem is the shim-signed that's in unstable right now. It hasn't migrated to testing yet (and won't without an unblock AFAICS), so there is a comparatively limited set of machines with it installed. I'm *tempted* to revert shim-signed and go back to using the previous 15.7 shim *for now* there. Then move forward to 15.8 again just before the point release. > > How does that sound? Feedback welcome... As far as I understood the documentation for SBAT [1][2], the SBAT mechanism is working as it is intended (i.e. blocking when the UEFI firmware somehow learns about revoked SBAT levels). Debian will not be alone in increasing the shim SBAT level to 4, every distro that uses shim 15.8 (released 2024-01-23) will effectively block the current bookworm and bullseye bootable images. (With 'whohas', I've seen at least Gentoo and Ubuntu) The error message 'Verifying shim SBAT data failed: Security Policy Violation' does not contain many details, and I expect that there will be several bug reports coming in, or frustrated users shying away from Debian. Since the 12.7 release is currently being planned (second half of August), this leaves a window of about 6 to 8 weeks for incoming issues. The easiest short-term fix looks indeed to be a revert to 15.7, however, anyone using 1) sid, 2) secure boot UEFI and 3) unattended-upgrades since 2024-06-26 would find their computer to be unbootable, unless the revert can somehow reduce these SBAT levels to values that allow for a boot. (Or if that is not automatically possible, a NEWS entry might be required, prompting the user to do things manually) Alternatively, the Debian installer images and live images could be re-generated to have the newer shim version patched in, to provide 12.6.1 versioned images (a kind of security update, that's what the third number was reserved for, isn't it?) With kind regards, Roland Clobus [1] https://github.com/rhboot/shim/blob/main/SBAT.md [2] https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt OpenPGP_signature.asc Description: OpenPGP digital signature
Re: SBAT revocation. Do we need a 12.6.1 release? (Was: Heads-up: Verifying shim SBAT data failed: Security Policy Violation)
On 03/07/2024 18:21, Roland Clobus wrote: Thanks! That did the trick, it shows one offending entry, which causes this issue: grub,3 (see screenshot) Oops. Actually, it is shim which causes the issue, as the screenshot shows that shim has version 3, and at least version 4 is required. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: SBAT revocation. Do we need a 12.6.1 release? (Was: Heads-up: Verifying shim SBAT data failed: Security Policy Violation)
Hello list, On 03/07/2024 08:38, Pascal Hambourg wrote: On 03/07/2024 at 08:13, Roland Clobus wrote: Who can find out which part in this file is causing the issue? Or which tools do I need to use to debug this? Maybe increase shim verbosity with # mokutil --set-verbosity true Thanks! That did the trick, it shows one offending entry, which causes this issue: grub,3 (see screenshot) Whenever the virtual machine was booted in secure UEFI boot with a newer version, that would revoke the version for GRUB. To reproduce: * Use the stock OVMF_VARS_4M.ms.fd * Boot with the live 12.6.0 bookworm image (I used 'standard') [1] or the netinst image [2] * mokutil --list-sbat-revocations shows: sbat,1,2022052400 grub,2 * Boot with a freshly built live sid image [3] * mokutil --list-sbat-revocations shows: sbat,1,2024010900 shim,4 grub,3 grub.debian,4 * Boot with the bookworm image again -> the SBAT error message is shown. This would mean that any machine that got an SBAT revocation would not be able to boot the official Debian Bookworm images any more. Does this mean that it would be necessary to release a set of 12.6.1 images? (i.e. live, netinst, etc.) Further reading regarding SBAT: [4] With kind regards, Roland Clobus --- [1] https://get.debian.org/images/release/current-live/amd64/iso-hybrid/ [2] https://get.debian.org/images/release/current/amd64/iso-cd/debian-12.6.0-amd64-netinst.iso [3] e.g. from openQA: https://openqa.debian.net/tests/278991/asset/iso/smallest-build_sid_20240703T081003Z.iso [3] https://github.com/rhboot/shim/blob/main/SBAT.md OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Heads-up: Verifying shim SBAT data failed: Security Policy Violation
Hi, On 28/06/2024 12:52, Cyril Brulebois wrote: > Cyril Brulebois (2024-06-28): >> I've just built a netboot-gtk mini.iso against unstable, including the >> new kernel. A regular “almost all defaults” (except French to check >> things like translations, keymap fun, etc.) install on UEFI gave an >> overall successful installation according to d-i, but it doesn't boot: >> >> Verifying shim SBAT data failed: Security Policy Violation I see this too in my QEMU with UEFI secure boot turned on (I am running testing on my host). I've used an older live ISO image, which I have successfully booted in the past, and it shows the same error message, before turning the VM off. I've rebuilt some live images (standard) [2], and only the sid image is booting fine. The official debian-live-12.6.0-amd64-standard.iso has the same issue (I've verified the sha256sum) The error message originate from shim: https://sources.debian.org/src/shim/15.8-1/shim.c/#L1932 https://sources.debian.org/src/shim/15.7-1/shim.c/#L1736 It turns out, that my UEFI variables are causing this issue. When I use the unmodified OVMF_VARS_4M.ms.fd, all images I mentioned earlier boot properly. The offending file could not be attached, it is too big for this mailing list. I can send it by private mail. Who can find out which part in this file is causing the issue? Or which tools do I need to use to debug this? With kind regards, Roland Clobus [1] debian-live-12.4.0-amd64-gnome.iso [2] bookworm, testing and sid OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian on arm64 (Was: Contacting Debian Boot team)
Hello Andreas, On 24/06/2024 10:18, Andreas Tille wrote: ... Argh, I need Windows to install Linux. That's IMHO a no-go. I do not buy and hardware which has Windows preinstalled / needs Windows for whatever purpose. Do you think that this could/should be a topic to talk about with some Lenovo representative at DebConf? For details of the work done on the kernel/installer/cd/live images: https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Rocca There has been some progress since Cambridge, e.g. at the MiniDebConf in Hamburg. See the debian-cd mailing list [1], where I requested to add the Debian Live image for GNOME for arm64. Preliminary tests on openQA have shown no major differences in functionality with regard to the amd64 live images. With kind regards, Roland Clobus [1] https://lists.debian.org/debian-cd/2024/06/msg00020.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1036315: rootskel-gtk: Alpha/missing pixels on the borders of the PNG banner
Control: tags +patch Hello maintainers of rootskel-gtk, On Fri, 19 May 2023 10:58:35 +0200 Cyril Brulebois wrote: When building the package on bullseye, I'm getting transparency on both left and right borders. When building it on sid, I'm get that at the bottom. It would be great if we had some better or at least reproducible export. In the file `build/config/x86.cfg`, rsvg-convert is called without additional options. If the option `--background-color black` is used, all transparency will be pre-rendered and the image will have no transparency left. The colour black would be suitable, since that would match the 'nothingness' at the border of the screen. The slight stretching of the svg image in [1] could then be reverted. Old: rsvg-convert $(SPLASH_SVG) > $(SPLASH_PNG); New: rsvg-convert --background-color black $(SPLASH_SVG) > $(SPLASH_PNG); With kind regards, Roland Clobus [1] https://salsa.debian.org/installer-team/debian-installer/-/commit/698311cb81e26512a86a7b94682367cd047f491c OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
On 30/05/2024 00:55, Pascal Hambourg wrote: On 26/05/2024 at 22:29, Roland Clobus wrote: Your patch series works fine, the firmware is correctly identified and loaded. Unfortunately for me, it still needs a reconnect cycle. See the attached syslog for their effect. (I've used sid) Thank you for testing my patches but I did not expect them to solve the reattachment issue, only to identify the right module. After the r8712u module is first loaded without the firmware then unloaded and reloaded, what is the output of ls -d /sys/bus/usb/drivers/r8712u/1-3* ls -d /sys/bus/usb/devices/1-3/1-3* assuming the wireless adapter is identified as 1-3 ? I've used the following to reproduce: * A live-build-based image with the Debian installer, generated for sid with in config/packages the hw-detect.udeb with the patches from #1033679 * Virtual-Manager boots the ISO image (UEFI secure boot) * When the GRUB menu is shown, I attach the USB network adapter from the host * I select the Debian installer * Moment 1: the first d-i screen is shown. The USB device is seen by the kernel, but the module is not yet loaded ls -d /sys/bus/usb/drivers/r8712u/1-3* No such file or directory ls -d /sys/bus/usb/drivers/usb/1-3* /sys/bus/usb/drivers/usb/1-3 ls -d /sys/bus/usb/devices/1-3/1-3* /sys/bus/usb/devices/1-3/1-3:1:0 lsmod | grep r8712u * Moment 2: the d-i screen 'No Ethernet card was detected' is shown (The firmware has been placed where it can be found, module r8712u has been removed and added) ls -d /sys/bus/usb/drivers/r8712u/1-3* No such file or directory ls -d /sys/bus/usb/drivers/usb/1-3* No such file or directory ls -d /sys/bus/usb/devices/1-3/1-3* No such file or directory lsmod | grep r8712u r8712u 262144 0 cfg80211 1355776 1 r8712u usbcore409600 5 xhci_hcd,usbhib,r8712u,usb_storage,xhci_pci * Moment 3: I disconnect and reconnect the USB device in virt-manager and select 'Detect network hardware' from the d-i menu. d-i shows a list of SSIDs ls -d /sys/bus/usb/drivers/r8712u/1-3* /sys/bus/usb/drivers/r8712u/1-3:1.0 ls -d /sys/bus/usb/drivers/usb/1-3* /sys/bus/usb/drivers/usb/1-3 ls -d /sys/bus/usb/devices/1-3/1-3* /sys/bus/usb/devices/1-3/1-3:1:0 lsmod | grep r8712u r8712u 262144 0 cfg80211 1355776 1 r8712u usbcore409600 5 xhci_hcd,usbhib,r8712u,usb_storage,xhci_pci With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hello Pascal, On 25/05/2024 23:49, Pascal Hambourg wrote: On 25/05/2024 at 22:10, Roland Clobus wrote: When I run the Debian installer, the missing firmware file is correctly identified and installed by 'check-missing-firmware.sh'. However, the kernel module is mis-identified as 'usb'. This is a more generic issue already reported in #1033679 Can you give a try to the attached patches ? They came to late for bookworm, maybe it is time to reconsider them. Your patch series works fine, the firmware is correctly identified and loaded. Unfortunately for me, it still needs a reconnect cycle. See the attached syslog for their effect. (I've used sid) At 19:30:58 the 'no network card is detected' dialog from the installer is shown At 19:32:30 I disconnected the USB device from KVM (which is attached on the host) At 19:32:45 I reconnected the USB device in KVM At 19:34:06 the SSID scan shows the available wireless networks Attached is a patch that allows the module to be identified correctly. If desired, I can send the patch instead as a merge request on Salsa. IMO $address should be included in the search pattern. Else if there is another device reported as "usb" then your patch will wrongly resolve it as r8712u too. Your patch is better and more generic. It would be a good candidate for at least trixie. However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient to enable the adapter, it still needs a physical reconnect. In the attached screenshot from the installer (sid) the result of the patch is shown. Also in the QEMU environment, I need to disconnect and reconnect the USB device from the host. Looks like a driver/device issue. Given that within kvm (virt-manager) I can simulate a reconnect, I would expect that it can be simulated otherwise, but haven't found a proper way yet. With kind regards, Roland Clobus May 26 19:30:27 syslogd started: BusyBox v1.36.1 May 26 19:30:27 kernel: klogd started: BusyBox v1.36.1 (Debian 1:1.36.1-7) May 26 19:30:27 kernel: [0.00] Linux version 6.8.9-amd64 (debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.9-1 (2024-05-15) May 26 19:30:27 kernel: [0.00] Command line: BOOT_IMAGE=/install/gtk/vmlinuz vga=788 --- quiet May 26 19:30:27 kernel: [0.00] BIOS-provided physical RAM map: May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x-0x0002] usable May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x0003-0x0004] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x0005-0x0009efff] usable May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x0010-0x7e8ecfff] usable May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x7e8ed000-0x7eb6cfff] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x7eb6d000-0x7eb7efff] ACPI data May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x7eb7f000-0x7ebfefff] ACPI NVS May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x7ebff000-0x7eff] usable May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x7f00-0x7fff] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved May 26 19:30:27 kernel: [0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable May 26 19:30:27 kernel: [0.00] NX (Execute Disable) protection: active May 26 19:30:27 kernel: [0.00] APIC: Static calls initialized May 26 19:30:27 kernel: [0.00] e820: update [mem 0x7cc12018-0x7cc1ba57] usable ==> usable May 26 19:30:27 kernel: [0.00] e820: update [mem 0x7cc12018-0x7cc1ba57] usable ==> usable May 26 19:30:27 kernel: [0.00] extended physical RAM map: May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x-0x0002] usable May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x0003-0x0004] reserved May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x0005-0x0009efff] usable May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x0009f000-0x0009] reserved May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x0010-0x7cc12017] usable May 26 19:30:27 kernel: [0.00] reserve setup_data: [mem 0x7cc12018-0x7cc1ba57] usable May 26 19:30:27 kernel: [0.00] reserve setup_data
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
On 25/05/2024 23:34, Cyril Brulebois wrote: Hoi, Roland Clobus (2024-05-25): Source: hw-detect Version: 1.160 Severity: normal Tags: patch d-i Just to confirm, which linux version was this tested against? The current kernel from sid: 6.8.9-1 I've used a locally built live image based on sid (live-build) with the patched hw-detect. I have an USB wireless adapter that uses the r8712u kernel module and that requires firmware from non-free-firmware. ... I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… As far as I can see, r8712u entered staging in 2012 and has been there since... I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? In which repo can I find this hash value? When I disconnect the adapter and reconnect it, the installer is able to use the adapter properly. ... I tried several options, but could not get them to work ...>> Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Thanks. I'll try to look some more. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Source: hw-detect
Version: 1.160
Severity: normal
Tags: patch d-i
Hello maintainers of hw-detect,
I have an USB wireless adapter that uses the r8712u kernel module and
that requires firmware from non-free-firmware.
When I run the Debian installer, the missing firmware file is correctly
identified and installed by 'check-missing-firmware.sh'. However, the
kernel module is mis-identified as 'usb'. When I disconnect the adapter
and reconnect it, the installer is able to use the adapter properly.
Attached is a patch that allows the module to be identified correctly.
If desired, I can send the patch instead as a merge request on Salsa.
However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not
sufficient to enable the adapter, it still needs a physical reconnect.
In the attached screenshot from the installer (sid) the result of the
patch is shown. Also in the QEMU environment, I need to disconnect and
reconnect the USB device from the host.
I tried several options, but could not get them to work: bind/unbind [1]
authorized, usbreset [2]
Do you know a solution (apart from a physical reconnect)?
With kind regards,
Roland Clobus
[1]
https://superuser.com/questions/1707773/how-to-turn-usb-connected-device-on-and-off-in-linux
[2]
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index a89f62fb..cca00687 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -29,6 +29,14 @@ get_usb_module() {
# Make sure there's a single subdirectory (e.g. 4-1.5:1.0 below 4-1.5):
subdirs=$(find -L "$device" -maxdepth 1 -type d -name "$address:*")
subdirs_n=$(echo "$subdirs" | wc -w)
+ if [ $subdirs_n -eq 0 ]; then
+ # If the driver is unbound, perhaps it is r8712u
+ dmesg | grep "r8712u: Firmware request failed" >/dev/null
+ if [ $? -eq 0 ]; then
+ echo 'r8712u'
+ return
+ fi
+ fi
if [ $(echo "$subdirs" | wc -w) != 1 ]; then
log "failed to perform usb $address lookup (got: $subdirs_n entries, expected: 1)"
log "=> sticking with the usb module"
OpenPGP_signature.asc
Description: OpenPGP digital signature
Are follow-up steps for Lomiri desktop required?
Hello installer team, I've noticed that (currently as draft) preparations [1] are ongoing to add Lomiri as task-lomiri-desktop into task-desktop. Is it intended to have Lomiri available in the installer and to have live images? If so, it would need some coordination to have it all set up. (I'm thinking of d-i, regular builds, openQA, Jenkins, live-build, ...) With kind regards, Roland Clobs [1] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065033: debootstrap: Fails for *sid* with `cannot move /lib/x86_64-linux-gnu/libpam.so.0 as its destination exists as a symlink`
Hello Paul, On 29/02/2024 06:52, Paul Menzel wrote: ... I am unable to bootstrap Debian sid/unstable. It worked some weeks ago. ... This is part of the t64 transition. It will start to work soon, as more packages have transitioned. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Immediate fallouts from the big linux changes, and actions
On 29/12/2023 12:14, Holger Levsen wrote: On Fri, Dec 29, 2023 at 08:04:19AM +0100, Roland Clobus wrote: Yesterday I published 3 fixes which got merged really quickly. [...] Now Jenkins is running fine for the live sid images again :-) In the next step, I'll check the trixie live builds. awesome, thank you! And today the live-build scripts got support for trixie, for which the regular weekly builds start tomorrow. The hack that I made for live-build, it properly implemented in a MR for debian-installer: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/43 That change will automatically deactivate when the newer kernel enters trixie. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Immediate fallouts from the big linux changes, and actions
On 25/12/2023 12:43, Holger Levsen wrote: Hi Roland, FYI, you might want to read the full thread! ;) ... On Sun, Dec 24, 2023 at 08:38:57AM +0100, Cyril Brulebois wrote: This is mostly for information: linux went through a lot of big changes, initially staged in experimental, and uploaded to unstable as of linux 6.6.8-1. ...> this change also lead to failing live-builds, for trixie (the unstable live-builds are of course also affected but fail earlier due to #1058994), this can be seen in https://jenkins.debian.net/job/reproducible_debian_live_build_xfce_trixie/35/console which failed with cp: cannot stat 'chroot/debian-installer/build/dest/cdrom/vmlinuz': No such file or directory Yesterday I published 3 fixes which got merged really quickly. 1) The live-build scripts automatically selects the newest kernel version, but did not account for '6.6.8' instead of '6.6.8-1' 2) The chroot which is used for building the d-i image does no longer contain fakeroot, which is still used by the d-i script (#1058994) 3) Also grub-pc (and dependencies) were no longer present for the installer, they needed to be provided as .deb images Now Jenkins is running fine for the live sid images again :-) In the next step, I'll check the trixie live builds. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Writable partition for D-I ISO images
Hello Thomas, lists, First: I think it is a good idea to provide such mechanism out-of-the-box A few months ago another approach was presented on the live-build project: for computers that are able to boot with EFI (secure or not), preparing a live USB-stick (based on the ISO file) is nearly trivial [1]. It is called FST (File System Transposition) [2]. It requires a FAT32 formatted USB stick on which the whole (including the hidden .disk folder) content of the ISO file is copied. There is no need for magic boot sectors, update-grub or similar. (On Windows the tool Rufus can do all this for you). Since the files are now on a regular FAT32 partition, they can be modified as required. As far as I understood, the installer images already support this, and for the live images this is on the TODO list [3]. And yet another approach which was shown to me on the openSUSE conference 2022: with kiwi it is possible to build live images for Debian as well, and IIRC one of boot steps involves filling the remainder of the USB-stick with a writeable partition. I can look up further details, if you are interested. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/323 [2] https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html [3] https://wiki.debian.org/DebianLive/TODO OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058994: debian-installer: fakeroot is pseudo-required
Source: debian-installer Version: 20230217 Severity: normal Tags: d-i Hello Debian-installer team, Recently the dependency tree of the packages that are required for building the Debian Installer (using mk-build-deps) has changed, now fakeroot is no longer installed per default in chroot environments. However, the 'daily-build' script still has the default value for 'ROOTCMD' as 'fakeroot'. This issue was seen on Jenkins, where the installer is rebuilt from git for the sid images (as part of the live image build) [1] I've built 2 variants of the bookworm image, one with additionally installing fakeroot in my chroot environment and one with 'ROOTCMD=" "'. Both are identical, so fakeroot is indeed not required for a proper build. Can the default value for ROOTCMD be changed to an empty value (and the corresponding check be removed)? [3] With kind regards, Roland Clobus --- [1] https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_standard_sid/671/console P: building the debian-installer ./daily-build: line 117: fakeroot: command not found E: An unexpected failure occurred, exiting... [2] /home/roland/git.nobackup/live-build/test/rebuild.sh --configuration standard --debian-version bookworm --timestamp archive --installer-origin git [3] https://sources.debian.org/src/debian- installer/20230607%2Bdeb12u4/build/daily-build/#L52 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921815: Versionnumber for closing the bug report
On 27/11/2023 09:25, Thorsten Glaser wrote: On Mon, 27 Nov 2023, Roland Clobus wrote: But did you also test whether /proc was not umounted? Before and after the debootstrap command, the output of mount inside the docker container is identical. Ah, okay. Your message read as if you only tested that debootstrap itself worked but didn’t mention the /proc parts. If this is indeed fixed, might be useful to figure out which version fixed it and then close with a version? Do you want to have a more exact version? Which I closed this issue, I used the version that is present in Buster. (Version: 1.0.114+deb10u1) Going deeper into older versions didn't seen necessary to me. With kind regards Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#921815: Extra information about /proc
Hello Thorsten, On 27/11/2023 05:58, Thorsten Glaser wrote: reopen 921815 thanks But did you also test whether /proc was not umounted? Before and after the debootstrap command, the output of mount inside the docker container is identical. Then I exit the docker container, and in the host (running sid) /proc is still mounted. So all is as expected. What did you see when you tested while reopening this bug report? With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051846: installation-reports: gnome_flashback installation fails on openQA with daily netinst image
Package: installation-reports Severity: normal X-Debbugs-Cc: p...@hands.com Boot method: CD netinst image Image version: https://get.debian.org/images/daily-builds/daily/arch- latest/amd64/iso-cd/debian-testing-amd64-netinst.iso from 20230913_0524 Date: Machine: QEMU with UEFI secure boot as on openqa.debian.net, 2GB memory Partitions: wipe all from a 10GB virtual HD Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installation proceeds without error. After rebooting, the screen with 'Oh no! Something has gone wrong' is shown. My attempts to reproduce and pinpoint the cause: I've tested with QXL and VGA graphical cards on openQA. In both cases the 'Oh no!' is shown. With the netinst image from 20230909_0504, the flashback GUI started initially with the grey top menu bar, but that got replaced by the black menu bar of the regular GNOME desktop. The last known good netinst image was from 20230910_0509. The first netinst image with this issue is from 20230910_1109. This narrows down the number of possible causes a bit. To see more installation attempts (every 6 hours): * Go to https://openqa.debian.net/group_overview/10 * Take a build that has no running jobs (i.e. no blue bar) * Click on the red part of the bar * Click on the red circle behind 'gnome_flash_flash' (before '_graphical_wait_login' or 'complete_install') * Installation logs and additional information can be found in the 'Logs & Assets' tab of the test With kind regards, Roland Clobus -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613+deb7u2+b1" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux silent 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell DRAM Controller [8086:0c00] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5000] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell Integrated Graphics Controller [8086:0412] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:d000] lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell HD Audio Controller [8086:0c0c] (rev 06) lspci -knn: Subsystem: Intel Corporation Device [8086:2010] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB xHCI Host Controller [8086:8c31] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5007] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Lynx Point MEI Controller #1 [8086:8c3a] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Lynx Point KT Controller [8086:8c3d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: Kernel driver in use: serial lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:e000] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation Lynx Point USB Enhanced Host Controller #2 [8086:8c2d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Lynx Point High Definition Audio Controller [8086:8c20] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:a002] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Lynx Point PCI Express Root Port #1 [8086:8c10] (rev d4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d4) lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation Lynx Point USB Enhanced Host Controller #1 [8086:8c26] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Lynx Point LPC Controller [8086:8c4a] (rev 04) lspci -knn:
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
Follow-up redirected to debian-live Hello Sakkra Billa, On 18/08/2023 15:27, Sakkra Billa wrote: I followed the tutorial from: https://www.willhaley.com/blog/custom-debian-live-environment/ That tutorial is a summary/excerpt from https://live-team.pages.debian.net/live-manual/ to which it also points. > ... Please guide me that where did i > go wrong and how can i make my live iso installable. I would recommend to use the live-build tool instead of doing each step manually. [1] The official Debian 12 (Bookworm) live images are generated by live-build. If you want to extend your local version, I would recommend you to read [2] as well. With kind regards, Roland Clobus [1] Disclaimer: I'm one of the maintainers of live-build, so I'm biased [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
Control: affects 1039710 grub-installer Hello Arnaud, This looks to be very similar that I reported in the first part of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039710 On BIOS-boots the EFI /sys mount is not present. With kind regards, Roland Clobus On 12/07/2023 16:30, Arnaud Rebillout wrote: The postinst still fails at this point. The error can be reproduced from the console: mkdir -p /target/sys/firmware/efi/efivars mkdir: can't create directory '/target/sys/firmware/efi': Operation not permitted I suppose the mkdir call must also be allowed to fail when fstype is efivarfs (following the same logic that is already used for mount). Do you want me to submit a patch? NB: the issue only affects a BIOS VM. If I boot a UEFI VM, everything works fine. OpenPGP_signature Description: OpenPGP digital signature
Bug#1039710: busybox-udeb: /var/log/syslog is empty
Control: retitle -1 busybox-udeb: /var/log/syslog is empty On 28/06/2023 22:54, Cyril Brulebois wrote: With a local build, confirmed -3 is buggy, and that reverting only busybox-udeb to -1 is sufficient to restore syslog support in the installer. Confirmed and details to reproduce: * Download the busybox binary file from [1] and extract the file `busybox` * Run the latest netinst image in Qemu/KVM (sid) * Select the installer * Answer all the questions and let it run until an error (to make sure that the network is properly configured) * Select a shell in the installer * Download the older busybox binary file (you can use my server) `cd /` `wget http://pioneers.game-host.org/busybox` `chmod a+x busybox` * Kill the running syslogd `ps | grep syslogd` `kill ` * Restart syslogd from the older busybox `/busybox syslogd -m 0 -O /var/log/syslog -S` * Log something `logger -t Test It works now` * Send Ctrl-Alt-F4, to see the output in the log With kind regards, Roland Clobus [1] https://snapshot.debian.org/archive/debian/20230608T144245Z/pool/main/b/busybox/busybox-udeb_1.36.1-1_amd64.udeb OpenPGP_signature Description: OpenPGP digital signature
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Package: debian-installer Version: daily build 2023-06-28T05:19Z Severity: grave Tags: d-i Justification: renders package unusable X-Debbugs-Cc: p...@hands.com Hello Debian-installer maintainers, On openQA [1] the installation tests with the latest netinst image [2] fail, because GRUB cannot install. I've tried to look a bit deeper into the issue, but I cannot proceed, because /var/log/syslog is empty. So effectively there are possibly two issues in this report: 1) Failure in grub 2) No logging to /var/log/syslog My findings so far: * The command line arguments of syslogd and klogd (both from Busybox) have not changed between Bookworm and Trixie. * At the moment of the failure, the /var/log folder contains only 3 files [3]: syslog (a single line, stating that syslog was started from Busybox [4]), partman and Xorg.0.log * When running `logger`, an entry should have been created in /var/log/syslog, but that doesn't happen. The netinst image from Bookworm works correctly. * Possibly relevant packages that have been updated: busybox, libc, linux- image, bsdutils With kind regards, Roland Clobus [1] https://openqa.debian.net/tests/167456 [2] https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso- cd/debian-testing-amd64-netinst.iso [3] https://openqa.debian.net/tests/167456/file/grub-var_log.tar [4] https://openqa.debian.net/tests/167456/logfile?filename=DI_syslog.txt PS: Attached system information is from my personal computer, not the installed system -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1036319: installation-reports: Multiple Installation report for RC3 on openQA
Package: installation-reports Severity: normal X-Debbugs-Cc: p...@hands.com Boot method: CD in openQA Image version: https://cdimage.debian.org/cdimage/bookworm_di_rc3/amd64/iso-cd/debian- bookworm-DI-rc3-amd64-netinst.iso Date: Machine: openQA x86_64 qemu video: qxl memory: 2GB. SeaBIOS and Tianocore UEFI (non-secure) Comments/Problems: See https://openqa.debian.net/tests/overview?distri=debian&version=bookworm&build=DI_rc3&groupid=10 On the page 'Logs & Assets' the file '_graphical_wait_login-journal.txt' contains the output of journalctl. The following issues are detected: Cinnamon: For BIOS boot, on first boot, a dialog is shown 'You are currently running in fallback mode'. The UEFI installation works fine. GNOME: For BIOS boot, on first boot, a dialog is shown 'On no! Something has gone wrong'. The UEFI installation works fine. The journalctl file has the following suspect snippet: May 18 17:16:17 debian org.gnome.Shell.desktop[610]: LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! May 18 17:16:17 debian org.gnome.Shell.desktop[610]: == Stack trace for context 0x55aacc0f37c0 == KDE: For BIOS boot, on first boot, the screen stays black (no plymouth splash screen is shown). The UEFI installation works fine. The journalctl file has the following suspect snippet: May 18 18:14:03 debian systemd-coredump[584]: Process 536 (sddm-greeter) of user 110 dumped core. LXQt: For BIOS boot, on first boot, the screen stays black (no plymouth splash screen is shown). Due to #1023472, this might be the same issue as for KDE. The UEFI installation shows the KDE login, as reported in #1023472. The other desktops (LXDE, Mate and XFCE) install correctly in both BIOS and UEFI installations. In all cases, the installation itself runs fine. (Even though a screensaver might not be ideal -> #787279). It is 'only' the first boot that causes issues. Note that some issues on the public openQA server (running on AMD hardware) were not reproducible on my local openQA server (running on Intel hardware) With kind regards, Roland Clobus -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613+deb7u2+b1" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux silent 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell DRAM Controller [8086:0c00] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5000] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell Integrated Graphics Controller [8086:0412] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:d000] lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell HD Audio Controller [8086:0c0c] (rev 06) lspci -knn: Subsystem: Intel Corporation Device [8086:2010] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB xHCI Host Controller [8086:8c31] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5007] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Lynx Point MEI Controller #1 [8086:8c3a] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Lynx Point KT Controller [8086:8c3d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: Kernel driver in use: serial lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:e000] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation Lynx Point USB Enhanced Host Controller #2 [8086:8c2d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Lynx Point High Definition Audio Controller [8086:8c20] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:a002] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Lynx Point PCI Express Root Port #1 [8086:8c10] (rev d4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d4) lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation Lynx Point USB Enhanced Host Controller #1 [8086:8c26] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006] lspci -kn
Bug#1023472: Workaround implemented for live images
Hello Cyril,
On 19/05/2023 00:59, Cyril Brulebois wrote:
Speaking as someone who happen{ed,s} to come across live-build things for
unrelated reasons:
Roland Clobus (2023-05-18):
I've implemented a workaround for the live images at [1].
As a result, the xfwm4 desktop manager is now the only desktop manager.
This seems to have been merged in live-build master.
I'm not sure whether this is a workaround or a real fix; if that's the
latter, it should probably be reassigned to live-build?
I consider it a workaround, because the netinst D-I is still affected.
If the LXQt desktop is selected in the installer, the Wayland desktop
manager is used instead of xfwm4.
The MR for a proposed fix (in tasksel) is at [1].
Two questions, with RC 4 in mind (and as a reminder, while I'll be dealing
with D-I Bookworm RC 4 with a focus on… the installer primarily, live images
are being built and released at the same time):
- Is there a live-build upload planned to publish this fix to unstable?
There is no (direct) need for an upload due to this workaround. The
building process is primarily tied to git, not to the Debian archive:
The daily live images are generated reproducibly by using the timestamp
of the last DAK run to time travel back to the corresponding git commit
of live-build.
That same procedure is used for the weekly live builds (which have not
been as thoroughly tested as the daily builds in openQA [3]).
- With or without an extra upload, is there a plan to ask for an unblock?
It seems best to ship in $codename the tools being built to build
$codename. (Similar example: debian-cd.)
The script to build the live images is not present in any Debian
package, it lives only in Salsa [2].
With kind regards,
Roland Clobus
[1] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/23
[2]
https://salsa.debian.org/live-team/live-build/-/blob/master/test/rebuild.sh
[3] https://openqa.debian.net/group_overview/14
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1023472: Workaround implemented for live images
Hello Holger, LXQt-list, I've implemented a workaround for the live images at [1]. As a result, the xfwm4 desktop manager is now the only desktop manager. The results can be seen in openQA for the live image [2] and netinst daily [3] and RC3 [4]. The daily and the RC3 netinst installer shows the wrong desktop manager after installation, they could be fixed by the patch I proposed. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/305 [2] https://openqa.debian.net/tests/overview?distri=debian&version=sid_lxqt&build=20230517T141208Z_sid_lxqt&groupid=14 [2] Breadcrumb: Debian Live | Build20230517T141208Z_sid_lxqt [3] https://openqa.debian.net/tests/148148#step/_graphical_wait_login/2 [3] Breadcrumb: Debian (amd64) | Build20230518_1104-testing-amd64 | lxqt@uefi | _graphical_wait_login [4] https://openqa.debian.net/tests/overview?build=DI_rc3&distri=debian&version=bookworm&groupid=10 [4] Breadcrumb: Debian (amd64) | DI_rc3 | lxqt@uefi | _graphical_wait_login OpenPGP_signature Description: OpenPGP digital signature
Bug#1035588: installation-reports: Installation of GNOME desktop fails (in openQA)
On 05/05/2023 22:26, Roland Clobus wrote: Sorry, I mixed up KDE and GNOME reports... Fixing the URLs to point to the GNOME issue Boot method: CD Image version: daily netinst 20230505_1104 from https://get.debian.org/images/daily-builds/daily/current/amd64/iso-cd/ Date: 2023-05-05T15:57:23 Machine: qemu running on AMD64 server osuosl3.debian.net See: https://openqa.debian.net/tests/144876 Partitions: https://openqa.debian.net/tests/144876/logfile?filename=complete_install-gdisk.txt -- GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *** Disk /dev/vda: 20971520 sectors, 10.0 GiB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 2E91D03B-B669-42AF-9A53-D4DD7C273F31 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 20971486 Partitions will be aligned on 2048-sector boundaries Total free space is 6077 sectors (3.0 MiB) Number Start (sector)End (sector) Size Code Name 1204818970623 9.0 GiB 8300 Linux filesystem 51897267220969471 975.0 MiB 8200 Linux swap -- Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: After the reboot the GNOME login screen is not shown, instead the screen shows 'Oh no! Something has gone wrong'. This is a suspicious parts from `journalctl -b`: https://openqa.debian.net/tests/144876/logfile?filename=_graphical_wait_login-journal.txt May 05 13:59:35 debian org.gnome.Shell.desktop[610]: LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! May 05 13:59:35 debian org.gnome.Shell.desktop[610]: == Stack trace for context 0x5560643b27d0 == I've used the same ISO file on my Intel-based computer, that worked fine. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1035588: installation-reports: Installation of GNOME desktop fails (in openQA)
Package: installation-reports Severity: normal User: debian...@lists.debian.org X-Debbugs-Cc: p...@hands.com Boot method: CD Image version: daily netinst 20230505_1104 from https://get.debian.org/images/daily-builds/daily/current/amd64/iso-cd/ Date: 2023-05-05T15:57:23 Machine: qemu running on AMD64 server osuosl3.debian.net See: https://openqa.debian.net/tests/144783 Partitions: https://openqa.debian.net/tests/144783/logfile?filename=complete_install- gdisk.txt -- GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *** Disk /dev/vda: 31457280 sectors, 15.0 GiB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 71C86CFF-DC9F-4BC4-B99D-DB5CF15F1DB3 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 31457246 Partitions will be aligned on 2048-sector boundaries Total free space is 6077 sectors (3.0 MiB) Number Start (sector)End (sector) Size Code Name 1204829456383 14.0 GiB8300 Linux filesystem 52945843231455231 975.0 MiB 8200 Linux swap -- Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: After the reboot the GNOME login screen is not shown, instead the screen stays black. Judging from the output of `journalctl -b`, sddm-greeter causes a core dump https://openqa.debian.net/tests/144783/logfile?filename=_graphical_wait_login- journal.txt systemd-coredump[917]: Process 873 (sddm-greeter) of user 113 dumped core. I've used the same ISO file on my Intel-based hardware, with a similar invocation of qemu, and there the ISO images worked fine. With kind regards, Roland Clobus PS: The netinst-RC2 image has the same issue -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613+deb7u2+b1" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux silent 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell DRAM Controller [8086:0c00] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5000] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell Integrated Graphics Controller [8086:0412] (rev 06) lspci -knn: Subsystem: Giga-byte Technology Device [1458:d000] lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell HD Audio Controller [8086:0c0c] (rev 06) lspci -knn: Subsystem: Intel Corporation Device [8086:2010] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB xHCI Host Controller [8086:8c31] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5007] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Lynx Point MEI Controller #1 [8086:8c3a] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Lynx Point KT Controller [8086:8c3d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a] lspci -knn: Kernel driver in use: serial lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:e000] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation Lynx Point USB Enhanced Host Controller #2 [8086:8c2d] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Lynx Point High Definition Audio Controller [8086:8c20] (rev 04) lspci -knn: Subsystem: Giga-byte Technology Device [1458:a002] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Lynx Point PCI Express Root Port #1 [8086:8c10] (rev d4) lspci -knn: Kernel driver in use: pcieport
Labels for the netinst iso images
Hello Debian-boot, While replying to #1035381, I noticed that the label of the ISO netinst images is quite different for each of the variants: 11-released: Debian 11.7.0 amd64 n [1] daily: Debian testing amd64 n [2] RC2: Debian bookworm-DI-rc2 amd64 n [3] This complicates the detection in e.g. osinfo-db and other sources for running virtual images, which 'autodetect' the ISO image type. Could/Should the labels be changed to have a more consistent structure? e.g. Debian 12(.\d+.\d+|rc\d+|daily) amd64 n With kind regards, Roland Clobus [1] https://get.debian.org/images/release/current/amd64/iso-cd/ [2] https://get.debian.org/images/daily-builds/daily/current/amd64/iso-cd/ [3] https://get.debian.org/images/bookworm_di_rc2/amd64/iso-cd/ OpenPGP_signature Description: OpenPGP digital signature
Re: netboot's kernel version does not match linux-image-amd64
Hello Ignisc, On 25/04/2023 17:38, ign...@tuta.io wrote: Package: debian-installer-12-netboot-amd64 Version: 20230217 That's an old image. For Bookworm (Debian 12) the kernel is currently at 6.1.20-2. Where did you find this installer? Could you try a newer one? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1034562: installation-reports: "Works", graphical corruption & flashing once in Gnome
Hello Adam, I've seen some issues on openQA which run on AMD hardware, but I personally only have Intel processors, so I cannot reproduce such issues. [1] Can you confirm that the microcode is active? sudo journalctl --boot | grep microcode Could you try uninstalling the package 'amd-microcode'? sudo apt-get remove amd-microcode sudo update-initramfs -u Does that fix your graphical issues? With kind regards, Roland Clobus [1] https://openqa.debian.net/tests/140684#step/_graphical_wait_login/9 OpenPGP_signature Description: OpenPGP digital signature
Re: Starting the weekly live images for Bookworm building again
My last cross-post. Follow-up please on debian-live Hello Steve and lists, On 19/03/2023 16:13, Steve McIntyre wrote: So, after some delay from me and some further delays from various Debian machines committing suicide, I've got bookworm live builds running again. \o/ Thanks for merging the changes. I've taken Roland's updated patches and tweaked a little more in the setup.git and live-setup.git repos, and we now have live builds integrated. Changes I've added: * turned on source tarball generation using LB_SOURCE=true, and disable the external source build that we did for the older live-wrapper builds That's a good way to enable the source tarballs. I haven't looked at that part of live-build for a while, so the source tarball might need some love. * when building on casulana, warn about archive updates rather than restarting builds * don't attempt to build i386 live images any more, they're not useful * tweaked logging And an additional change to use the installer images from the repository instead of rebuilding them from git [1]. That change is now causing the missing kernel modules for d-i. I've rebuilding the installer images from git, after the discussion in #1006800 [2], to save the d-i team from doing an upload for every single kernel bump, while bookworm was not yet in freeze. (That is a recurring issue for every release [3]) So, *builds* work fine but I've not *yet* tested actually booting/using one of these images in any way. I've just triggered a full build of "testing" live images now, please help test if you can once they're in place at [2] in a couple of hours from now. > [2] https://get.debian.org/images/weekly-live-builds/ In openQA [4] the live images that were generated by Jenkins [5] have been tested for a while now. Now we can switch and use these new images instead of the images from Jenkins. Since both images are generated by the same script, I wouldn't expect many issues. I don't yet know how close we are to having full non-free-firmware integration with the live images; I expect there might be some more work needed there yet, but I'd love to be proven wrong. :-) This weekend I've written the missing parts, non-free-firmware images are now generated by default by live-build, and the ISO images are still bit-for-bit reproducible. With kind regards, Roland Clobus [1] 3cef309a5cfa4758ba33480b170734133b7104b5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006800 [3] #986506, https://lists.debian.org/debian-boot/2021/03/msg00166.html [4] https://openqa.debian.net/group_overview/14 [5] https://jenkins.debian.net/view/live/ OpenPGP_signature Description: OpenPGP digital signature
Bug#1023472: Fix for double Window Manager in LXQt
Hello Holger, lists,
On 22/01/2023 18:27, Roland Clobus wrote:
On 22/01/2023 16:48, Holger Wansing wrote:
Your proposal
Depends: ${misc:Depends},
task-desktop,
+ # Mention the preferred theme before sddm, otherwise another theme
will be used
+ sddm-theme-debian-elarun | sddm-theme,
sddm,
- sddm-theme-debian-elarun | sddm-theme-debian-elarun,
lxqt,
will not work.
I've done some additional tests: installing 'lxqt' and
'task-desktop-lxqt' both without and with the command line switch
'--no-install-recommends'.
The package 'lxqt' pulls in 'sddm-theme-debian-elarun' and 'sddm'.
The next bigger package 'task-desktop-lxqt' additionally pulls in
'kde-config-sddm', 'sddm-theme-breeze' and 'sddm-theme-debian-breeze'
When the switch '--no-install-recommends' is used, 'lxqt' does not pull
in 'sddm' any more. 'task-desktop-lxqt' has the same sddm-releated
packages as 'lxqt' without the command line switch.
So the test case of 'task-desktop-lxqt' without
'--no-install-recommends' is the failing case.
Could the dependency chain in the 'task-desktop-lxqt' package instead be
changed to mention 'lxqt' before the 'sddm*' dependencies?
I've tested that with live-build, and I get a correct ISO image.
With kind regards,
Roland Clobus
--- Commands to reproduce the test cases
--- Note: I work on /dev/shm and use my apt-cacher-ng proxy on 192.168.0.15
mount /dev/shm -odev,exec,remount,size=24G
mkdir /dev/shm/task
cd /dev/shm/task
debootstrap testing chroot http://deb.debian.org/debian/
cp -a chroot chroot.orig
chroot chroot /bin/bash -c "http_proxy=http://192.168.0.15:3142
DEBIAN_FRONTEND=noninteractive apt --yes install lxqt"
chroot chroot dpkg-query -l | grep sddm
-> sddm, sddm-theme-debian-elarun
rm -fr chroot
cp -a chroot.orig chroot
chroot chroot /bin/bash -c "http_proxy=http://192.168.0.15:3142
DEBIAN_FRONTEND=noninteractive apt --yes install task-lxqt-desktop"
chroot chroot dpkg-query -l | grep sddm
-> kde-config-sddm, sddm, sddm-theme-breeze, sddm-theme-debian-breeze,
sddm-theme-debian-elarun
rm -fr chroot
cp -a chroot.orig chroot
chroot chroot /bin/bash -c "http_proxy=http://192.168.0.15:3142
DEBIAN_FRONTEND=noninteractive apt --yes --no-install-recommends install
lxqt"
chroot chroot dpkg-query -l | grep sddm
-> sddm-theme-debian-elarun
rm -fr chroot
cp -a chroot.orig chroot
chroot chroot /bin/bash -c "http_proxy=http://192.168.0.15:3142
DEBIAN_FRONTEND=noninteractive apt --yes --no-install-recommends install
task-lxqt-desktop"
chroot chroot dpkg-query -l | grep sddm
-> sddm, sddm-theme-debian-elarun
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1023472: Fix for double Window Manager in LXQt
Hello Holger, On 22/01/2023 21:02, Holger Wansing wrote: Am 22. Januar 2023 18:27:18 MEZ schrieb Roland Clobus : In sddm's control I see: ... snip ... So a Recommends. Sorry. I was reading the information on https://packages.debian.org/sid/sddm-theme-debian-elarun incorrectly. Indeed, it is a recommends relationship. In the default case of generating a live image (only depend and recommend is followed), this is sufficient to fulfil the recommends (sddm-theme-debian-breeze | sddm-theme) in sddm with sddm-theme-debian-elarun, which is mentioned earlier and therefore the second part of the or-statement will be met. My tests in a freshly installed bookworm system showed, that sddm is indeed installed by sddm-theme-debian-elarun installation (and that matches the Recommends), so don't know, what is right. I see this issue in openQA for two separate test cases: 1) Running the Debian installer with the LXQt desktop enabled Latest result: https://openqa.debian.net/tests/117521#step/_graphical_wait_login/13 2) Starting the live image for LXQt Latest result: https://openqa.debian.net/tests/117381#step/bootwalk_0/7 The issue isn't the sddm-theme-debian-elarun is not installed, but the additionally sddm-theme-debian-breeze gets installed too. And sddm-theme-debian-breeze additionally brings in kwin. With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Bug#1023472: Fix for double Window Manager in LXQt
On 22/01/2023 16:48, Holger Wansing wrote:
Hi,
Roland Clobus wrote (Sun, 22 Jan 2023 09:57:36 +0100):
... now sending to the bug, to show the full text ...
The proposed patch is at Salsa:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/23
By mentioning the sddm theme before sddm, it will prevent the default
theme of sddm to be installed.
Also in the MR: for some reason the theme was mentioned twice, it was
probably intended to allow for other sddm themes.
Your proposal
Depends: ${misc:Depends},
task-desktop,
+ # Mention the preferred theme before sddm, otherwise another theme will be
used
+ sddm-theme-debian-elarun | sddm-theme,
sddm,
- sddm-theme-debian-elarun | sddm-theme-debian-elarun,
lxqt,
will not work.
sddm-theme-debian-elarun itself recommends sddm, so installing
sddm-theme-debian-elarun will pull in sddm anyway, no matter what you do else.
And sddm pulls in most of the KDE environment, including kwin.
So I guess we will need to remove both, sddm-theme-debian-elarun and sddm,
from the list here, if we don't want kwin (and all the other KDE stuff).
Leaves us (or lxqt people, in CC) with the question, if some other theme package
is needed as a replacement from the above...
To test this, I've prepared a local version of tasksel with this change.
Then, by pushing the newer tasksel, tasksel-data, task-desktop and
task-lxqt-desktop .deb files into the live image, I was able to generate
a live image for LXQt with sddm-theme-debian-elarun as the only sddm
theme. With the current tasksel 3.71, both sddm-theme-debian-elarun and
sddm-theme-debian-breeze will get installed.
This MR solved the issue for me.
However, it might be that I've found a case where the resolving of
dependencies by apt is not 100% deterministic...
sddm-theme-debian-elarun does not recommend sddm, it only suggests it.
In the default case of generating a live image (only depend and
recommend is followed), this is sufficient to fulfil the recommends
(sddm-theme-debian-breeze | sddm-theme) in sddm with
sddm-theme-debian-elarun, which is mentioned earlier and therefore the
second part of the or-statement will be met.
With kind regards,
Roland
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1029393: debian-installer: Missing glyph detection
Source: debian-installer Severity: minor Tags: l10n Hello maintainers of the Debian installer, As a follow-up on #101435, I've updated the script to detect more cases where glyphs are missing, but used in translations. The steps required to run the script are mentioned in the header of the script. If needed, I can provide the file 'collect' (the currently used translations of all udebs in Bookworm) Attached is also the output of the script, which lists the missing glyps With kind regards, Roland Clobus -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled E: Glyph: '' 173 is used in translations for language(s): da,tg, but not mentioned in any build/needed-chars/*.utf E: Glyph: '·' 183 is used in translations for language(s): ar,el,kab,ku,lt, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'Ĩ' 296 is used in translations for language(s): vi, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ĩ' 297 is used in translations for language(s): vi, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ɛ' 603 is used in translations for language(s): kab, but not mentioned in any build/needed-chars/*.utf E: Glyph: '́' 769 is used in translations for language(s): el,vi, but not mentioned in any build/needed-chars/*.utf E: Glyph: '̆' 774 is used in translations for language(s): bg, but not mentioned in any build/needed-chars/*.utf E: Glyph: '̉' 777 is used in translations for language(s): vi, but not mentioned in any build/needed-chars/*.utf E: Glyph: '־' 1470 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ו' 1493 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ע' 1506 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ף' 1507 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: '׳' 1523 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: '״' 1524 is used in translations for language(s): he, but not mentioned in any build/needed-chars/*.utf E: Glyph: '؛' 1563 is used in translations for language(s): ar,fa,ug, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ء' 1569 is used in translations for language(s): ar, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'آ' 1570 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'أ' 1571 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ؤ' 1572 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'إ' 1573 is used in translations for language(s): ar, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ة' 1577 is used in translations for language(s): ar, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ت' 1578 is used in translations for language(s): ar,fa,ug, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ث' 1579 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ح' 1581 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'خ' 1582 is used in translations for language(s): ar,fa,ug, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ذ' 1584 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ز' 1586 is used in translations for language(s): ar,fa,ug, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ص' 1589 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ض' 1590 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ط' 1591 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ظ' 1592 is used in translations for language(s): ar,fa, but not mentioned in any build/needed-chars/*.utf E: Glyph: 'ع' 1593 is used in transla
Bug#1023472: Fix for double Window Manager in LXQt
... now sending to the bug, to show the full text ... The proposed patch is at Salsa: https://salsa.debian.org/installer-team/tasksel/-/merge_requests/23 By mentioning the sddm theme before sddm, it will prevent the default theme of sddm to be installed. Also in the MR: for some reason the theme was mentioned twice, it was probably intended to allow for other sddm themes. With kind regards, Roland Clobus PS: The old URL went stale, current openQA results can be seen here: 1) https://openqa.debian.net/group_overview/14 2) Select the most recent build that has '_sid_lxqt' 3) Look to 'walk-boot-options' 4) Select the red circle 5) At 'bootwalk_0' the Windows Manager selection window is shown (The current temporary deep link is https://openqa.debian.net/tests/116996#step/bootwalk_0/8) The ISO image can be downloaded from the tab 'Logs & Assets' OpenPGP_signature Description: OpenPGP digital signature
Re: Starting the weekly live images for Bookworm building again
Hello lists (sorry for cross-posting to so many lists), This is a follow-up of my mail from 2022-11-21 [A1]. I've made progress in the last two months, but would like to have some merge requests approved, to get more traction and to allow others to jump aboard and make the live images for Bookworm possible. As you can see, this affects many teams: * live-setup: a MR to generate all live images for Bookworm [A2] * localechooser: A minor fix [A3] * live-installer: A better user experience after the installer is finished [A4] * live-build: Various installer improvements, including off-line installation [A5] With kind regards, Roland Clobus [A1] https://lists.debian.org/debian-devel/2022/11/msg00221.html [A2] https://salsa.debian.org/images-team/live-setup/-/merge_requests/2 [A3] https://salsa.debian.org/installer-team/localechooser/-/merge_requests/7 [A4] https://salsa.debian.org/installer-team/live-installer/-/merge_requests/3 [A5] https://salsa.debian.org/live-team/live-build/-/merge_requests/297 OpenPGP_signature Description: OpenPGP digital signature
Bug#1017435: debian-installer: georgian text mode fails to render all characters
On 09/01/2023 18:01, Roland Clobus wrote: On 07/01/2023 11:59, Samuel Thibault wrote: Roland Clobus, le sam. 07 janv. 2023 11:31:29 +0100, a ecrit: Or... are additional udebs downloaded on demand? It seems from the list.gz files that udebs are on the first iso, and from the debian-cd exclude files that the only udebs which are not there are the ones which are already included in the d-i initrd. I doesn't seem that your current script looks at the udebs included in the initrd? I have a local build of a live image that downloads all udebs but did not remove any udeb (due to a bug, soon to be fixed), so I have looked at a total of 386 udeb files (which includes the udebs in the initrd) I'll take a closer look, because http://deb.debian.org/debian/dists/sid/main/debian-installer/binary-amd64/Packages.gz appears to mention 393 udeb files, so I'm missing 7. And found: I was comparing bookworm with sid... The ones that are extra in sid are: +depthcharge-tools-installer +libdns-export1110 +libirs-export161 +libisccc-export161 +libisccfg-export163 +libisc-export1105 +squid-deb-proxy-client-udeb With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Bug#1017435: debian-installer: georgian text mode fails to render all characters
On 07/01/2023 11:59, Samuel Thibault wrote: Roland Clobus, le sam. 07 janv. 2023 11:31:29 +0100, a ecrit: Or... are additional udebs downloaded on demand? It seems from the list.gz files that udebs are on the first iso, and from the debian-cd exclude files that the only udebs which are not there are the ones which are already included in the d-i initrd. I doesn't seem that your current script looks at the udebs included in the initrd? I have a local build of a live image that downloads all udebs but did not remove any udeb (due to a bug, soon to be fixed), so I have looked at a total of 386 udeb files (which includes the udebs in the initrd) I'll take a closer look, because http://deb.debian.org/debian/dists/sid/main/debian-installer/binary-amd64/Packages.gz appears to mention 393 udeb files, so I'm missing 7. With kind regards, Roland
Bug#1017435: debian-installer: georgian text mode fails to render all characters
On 08/01/2023 18:49, Holger Wansing wrote: Roland Clobus wrote (Sat, 7 Jan 2023 11:31:29 +0100): I agree. But the work for the translators can be reduced by automatically parsing the work they have already done (i.e. the translations). That would leave only some characters that have not been used in any translated text, but might be present i.e. on the keyboard. @Translators: It that something you might want to use? For a translator, it's just a matter of 1 minute, to write down the alphabet for his language, I guess. But anyway, we can still use your script, if we cannot get such info from translator (if there is no active translator, for example). Attached: 1) chars_v2.py: The updated script 2) sample.summary: Its output to the console 3) ka.utf: Automatically generated Georgian list of use characters The ka.utf you attached is conspicuously (nearly) identical to what I grabbed from Wikipedia, so: good work!!! Note the 'nearly'... :-) In the translations the following code points are used, which are not in your list yet: 10f2 (Georgian Letter Hie), used in 'retriever/media/loadnow' and 'partman-auto-raid/notenoughparts' 201c (Left Double Quotation Mark) 16x used 201d (Right Double Quotation Mark) 38x used 201e (Double Low-9 Quotation Mark) 56x used 21b5 (Downwards Arrow With Corner Leftwards), used in 'partman-md/deleteverify' and 'mdcfg/deleteverify' Note that 10f1 (Georgian Letter He) and 10f3-10fe are not used in any translated text. The last four code points will be included by other languages, so it's probably not important to have them missing in ka.utf. With kind regards, Roland Clobus PS: The strings with the missing letters were found be enabling lines 36 and 37 of the script. OpenPGP_signature Description: OpenPGP digital signature
Bug#1017435: debian-installer: georgian text mode fails to render all characters
On 06/01/2023 16:20, Samuel Thibault wrote:
Roland Clobus, le ven. 06 janv. 2023 13:38:34 +0100, a ecrit:
With the attached script you can generate a list of all characters that are
used in the translations. That can be used to determine the minimal set of
required characters.
We already do that in the debian installer, but that is not enough to be
reasonably sure that this covers all questions that might happen during
installation, since questions could be asked by any udeb. That's why we
rather request for a an explicit file from actual translators.
I agree. But the work for the translators can be reduced by
automatically parsing the work they have already done (i.e. the
translations).
That would leave only some characters that have not been used in any
translated text, but might be present i.e. on the keyboard.
@Translators: It that something you might want to use?
If those additional characters would be listed in a second line in the
file, it would even allow for friction-less merges.
(I.e. the first line would be autogenerated from the provided
translations and the second line would be a list of additional characters)
In order not to miss any translated text, I've updated the script to
parse all .udeb files that are present on the installation medium and
extract the template from them. This ensures that all questions that
might happen during installation will be could.
Or... are additional udebs downloaded on demand?
# How to run this script:
# 1) cd path_of_git_workdirectory_of_debian-installer
# 2) find mount_point_of_installer_image -name "*.udeb" | awk -e '{
print "dpkg-deb --control ", $1; print "if [ -e DEBIAN/templates ]; then
cat DEBIAN/templates >> collect; fi"; print "rm -fr DEBIAN" }' | sh
# 3) python3 chars_v2.py
# Carefully evaluate the proposed modifications in build/needed-characters
With kind regards,
Roland Clobus
Attached:
1) chars_v2.py: The updated script
2) sample.summary: Its output to the console
3) ka.utf: Automatically generated Georgian list of use characters
import re
# Generate a list of all characters that are used in translations in udeb files
#
# How to run this script:
# 1) cd path_of_git_workdirectory_of_debian-installer
# 2) find mount_point_of_installer_image -name "*.udeb" | awk -e '{ print "dpkg-deb --control ", $1; print "if [ -e DEBIAN/templates ]; then cat DEBIAN/templates >> collect; fi"; print "rm -fr DEBIAN" }' | sh
# 3) python3 chars.py
# Carefully evaluate the proposed modifications in build/needed-characters
write_to_file = True
dump_to_console = True
file = open("collect", "r")
content = file.read()
file.close()
lines = content.split("\n")
language = "C"
chars = dict();
for line in lines:
# Sample:
# Description-am.UTF-8: የሚጫኑ የተካይ አካሎች፦
match = re.split("\w+-([a-zA-Z@_]+).UTF-8: (.*)", line)
if (len(match) > 2): # A translated text
language = match[1]
translation = match[2]
elif line.startswith(" "): # Extended description
translation = line[1:]
else: # Not for translation -> reset
language = "C"
translation = ""
for char in translation:
# Debug part to find which translated text contains a specific character
#if language == "nl" and char == 'ı':
# print(line)
if not language in chars:
chars[language] = set(());
if ord(char) >= 128: # Add only non-ASCII characters
chars[language].add(char)
if write_to_file:
for language in sorted(chars):
file = open("build/needed-characters/" + language + ".utf", "w")
file.write(''.join(sorted(chars[language])))
file.close()
if dump_to_console:
for language in sorted(chars):
print(f"Language: {language}")
print(f"Characters: {''.join(sorted(chars[language]))}")
Language: C
Characters:
Language: am
Characters:
Åáãçéíôüሀሁሂሃሄህሆለሉሊላሌልሎሏሐሑሒሓሔሕመሙሚማሜምሞሟሠሡሢሣሤሥረሩሪራሬርሮሯሰሱሲሳሴስሶሷሸሹሺሻሼሽሾሿቀቁቂቃቄቅቆቋበቡቢባቤብቦቧቨቪቫቬቮተቱቲታቴትቶቷቸቹቺቻቼችቾኁኂኄኅኋነኑኒናኔንኖኗኘኙኚኛኝኞአኡኢኣኤእኦከኩኪካኬክኮኳኸኻኽወዉዊዋዌውዎዐዑዓዕዘዙዚዛዜዝዞዟዡዢዥየዩያይዮደዱዲዳዴድዶጀጁጂጃጄጅጆገጉጊጋጌግጎጐጒጓጔጕጘጠጡጢጣጤጥጦጧጨጪጫጭጮጵጸጹጻጽፁፃፄፅፈፉፊፋፌፍፎፐፑፒፓፔፕፖፘፙ፠፡።፣፤፥፦
Language: ar
Characters: ·ü،؛؟ءآأؤإئابةتثجحخدذرزسشصضطظعغـفقكلمنهوىيًٌٍَُِّْ٣٥…ﻷ
Language: ast
Characters: ¡«º»¿ÁÅÉÍÚáãçéíñóôúüḤḥ…
Language: be
Characters: «»ЁІЎАБВГДЕЖЗКЛМНОПРСТУФХЦЧШЫЬЭЮЯабвгдежзийклмнопрстуфхцчшыьэюяёіў—
Language: bg
Characters: ü̆АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЮЯабвгдежзийклмнопрстуфхцчшщъьюяѝ–“„…№
Language: bn
Characters:
ü।ঁংঃঅআইউএঐওকখগঘঙচছজঝঞটঠডঢণতথদধনপফবভমযরলশষসহ়ািীুূৃেৈোৌ্ৎড়ঢ়য়০১২৩৪৫৬৮৯…
Language: bo
Characters:
Åçéôü་།༢༣༤ཀཁགངཅཆཇཉཏཐདནཔཕབམཙཚཛཝཞཟའཡརལཤསཧཨིེོུྐྒྔྗྙྟྡྣྤྥྦྨྩྫྭྱྲླྷ“”、。盘键，：
Language: bs
Characters: ÅçéíôüĆćČč𩹮ž
Language: ca
Characters: «·»ÀÉÍÒÚàãçèéíïòóúü—
Language: cs
Characters: ÁÅÉÍáãçéíóôúüýČčďĚěňŘřŠšťŮůŽž“„
Language: cy
Characters: ÂÅÔáâãçéêëíîïôüŵ
Langua
Bug#1017435: debian-installer: georgian text mode fails to render all characters
On 01/01/2023 20:49, Holger Wansing wrote:
Hi,
Samuel Thibault wrote (Sun, 1 Jan 2023 20:14:36 +0100):
Hello,
Holger Wansing, le mar. 16 août 2022 22:59:34 +0200, a ecrit:
Philip Hands wrote (Tue, 16 Aug 2022 11:22:30 +0200):
openQA just noticed that the rendering of certain characters just changed,
highlighting the fact that the rendering was already broken.
...
The solution is simply to add the required characters in
debian-installer/build/needed-characters/ka.utf:
So, we need a Georgian translator, providing us a file with all non-ascii
characters needed for the Georgian language.
Can anyone help us, please?
With the attached script you can generate a list of all characters that
are used in the translations. That can be used to determine the minimal
set of required characters.
With kind regards,
Roland Clobus
import re
# Generate a list of all characters that are used in translations
#
# Generate the file templates.dat as follows:
# 1) Boot an image with the debian-installer
# 2) Proceed until the end, but do not 'Finish' yet
# 3) Open a console
# 4) cp /var/lib/cdebconf/templates.dat /target
# 5) chroot /target
# 6) scp templates.dat some_u...@example.com:/path_of_git_workdirectory_of_debian-installer
#
# Run this script:
# 1) cd path_of_git_workdirectory_of_debian-installer
# 2) python3 chars.py
#
# Carefully evaluate the proposed modifications in build/needed-characters
write_to_file = True
dump_to_console = True
file = open("templates.dat", "r")
content = file.read()
file.close()
lines = content.split("\n")
active_language = "C"
chars = dict();
for line in lines:
# Sample:
# Description-am.UTF-8: የሚጫኑ የተካይ አካሎች፦
match = re.split("\w+-(\w+).UTF-8: (.*)", line)
if (len(match) > 2): # A translated text
language = match[1]
translation = match[2]
for char in translation:
if not language in chars:
chars[language] = set(());
if ord(char) >= 128: # Add only non-ASCII characters
chars[language].add(char)
if write_to_file:
for language in sorted(chars):
file = open("build/needed-characters/" + language + ".utf", "w")
file.write(''.join(sorted(chars[language])))
file.close()
if dump_to_console:
for language in sorted(chars):
print(f"Language: {language}")
print(f"Characters: {''.join(sorted(chars[language]))}")
OpenPGP_signature
Description: OpenPGP digital signature
Re: Bug#1016809: [UEFI] Installed (minimal) bookworm system hangs at boot
Hello Holger, On 07/08/2022 21:52, Holger Wansing wrote: I wonder why this is not detected by tests on https://openqa.debian.net/group_overview/10 I see there are specific runs for UEFI, so it should be possible to detect this? Your command: qemu-system-x86_64 -boot order=d -vga vmware -bios OVMF.fd -L . -m 1024M --enable-kvm -hda ~/qemu-img-disk-10G.img -cdrom /home/ned/installation-images/debian-daily_2022-08-07_amd64-netinst.iso You have a different configuration compared to the openQA VMs. Your VM has only 1GB of memory, on openQA the VMs in openQA all have 2GB. Could you try again with more memory available? With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Daily installer image FTBFS
Hello debian-boot, the daily installer image fails to build. Unfortunately, bumping the kernel version [1] is not sufficient. Two days ago a new udeb as uploaded: x11-xkb-utils-udeb_7.7+6_amd64.udeb The Depends line in control changed from: Depends:·libc6-udeb·(>=·2.29),·libx11-6-udeb·(>=·2:1.6.0),·libxkbfile1-udeb to Depends:·libc6-udeb·(>=·2.33),·libx11-6-udeb·(>=·2:1.6.0),·libxkbfile1-udeb·(>=·1:1.1.0),·libxrandr2·(>=·2:1.5) Now the build complains about libxrandr2. Should it have used 'libxrandr2-udeb' instead? With kind regards, Roland Clobus [1] f8a6734b049a7e9ee2d81f5423349258efaf7def OpenPGP_signature Description: OpenPGP digital signature
Re: d-i user questions, web proxies, automated installation
Hello Marc, On 27/03/2022 15:43, Marc Haber wrote: ... And then: Can I have a single pre-seed file that would allow me to configure the Installer and Apt to choose the first web proxy from a list of proxies defined in some pre-seed data field, ... This looks like a use-case for FAI (Fully Automatic Installation): https://wiki.debian.org/FAI Did you look already whether that would fit your purpose? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1006800: debian-installer: kernel mismatch for bookworm and sid installer. New release needed?
Removed: rb-gene...@lists.reproducible-builds.org Hello Cyril, On 05/03/2022 18:45, Cyril Brulebois wrote: Roland Clobus (2022-03-05): On 05/03/2022 12:40, Cyril Brulebois wrote: We could, and should, release a new d-i and possibly an Alpha 1 at some point, but I don't have a specific timeline for that. Understood. I assume that an Alpha 1 release will be made somewhere near the release date of bookworm. In the past I've tried to have an Alpha 1 released after a few months into the new release cycle, then aim for something like a release every 1-2 months. But the archive can disagree from time to time, and lately, I'm rather busy with other things… Understood. So I've focussed on building the daily image myself, using the git version. This will 1) allow me to generate installer snapshots for testing and unstable that have their correct kernel version (because you diligently fix that in the git repo) 2) save you the time of doing new releases for testing and unstable. After some hick-ups, I've got a working version now. (See my aborted MR27: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/27) I'm currently preparing a 'rebuild' script for live-build, that will reproducibly re-generate an image, including the installer that matches that specific point in time. If you are interested, it might be usable for the daily-build script as well, because it will not use the timestamp for SOURCE_DATE_EPOCH of midnight (the time the script is started), but the timestamp of the last completed snapshot of the archive. How long do you need to go back / how long do you need to keep a given build? I can go back as far as I want right now. There is no need any more for the d-i.debian.org snapshots when I recreate the installer. With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Bug#1006800: debian-installer: kernel mismatch for bookworm and sid installer. New release needed?
+mailing list rb-general Hi, On 05/03/2022 12:40, Cyril Brulebois wrote: Roland Clobus (2022-03-05): I have noticed that the officially released version debian-installer [2][3] will not work for bookworm and sid, because the kernel version in the debian- installer does not match the current kernel version. You recently fixed this in git [4]. Could you release a new version of debian-installer for bookworm and sid? We could, and should, release a new d-i and possibly an Alpha 1 at some point, but I don't have a specific timeline for that. Understood. I assume that an Alpha 1 release will be made somewhere near the release date of bookworm. Or do you recommend a different (release) strategy? A new debian-installer upload (prelude to the aforementioned Alpha 1) is only going to help until src:linux gets a new ABI bump, so that's only going to be temporary anyway. Indeed. A new debian-installer upload would need to happen in lock-step with every new ABI in src:linux, to guarantee a consistent state of d-i. This could mean quite some work on your side. I'm aware of the daily images [5], but they are currently not being snapshotted, which makes it impossible to reproduce an image after the older images have been removed from [5]. If you're using a specific build, you could mirror it on your side, and then have a way to point at the mirrored copy so that you wouldn't depend on d-i.d.o's contents (that's an approach seen in various projects, e.g. time-based snapshots and tagged snapshots in Tails, even if that's for Debian as a whole, not d-i)? I do not know how much work it is to release a new version of debian-installer. Currently the state of the official repository (deb.debian.org) is a non-working installer for bookworm and sid. I'm looking at possible solutions here (that's why I've added the rb-general mailing list): * (Manually) do official releases of debian-installer more often (as I wrote, openQA will soon have some tests that detect when the kernel version got out-of-sync) * Automatically release git snapshots to deb.d.o instead of d-i.d.o * Extend snapshot.d.o and/or snapshot.notset.fr to cover d-i.d.o in addition to deb.d.o * No changes, and accept that older images cannot be recreated (this option is not preferred by me) * Other ... How long do you need to go back / how long do you need to keep a given build? Maybe we could just keep (some) builds for a longer while there, but that's at 90 days already. Looking at https://d-i.debian.org/daily-images/amd64/, the current history I can see is about 15 days. While investigating reproducible issues I personally tend to pick some timestamp and work on that for a longer period of time. 90 days would suffice completely for my purpose. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1006800: debian-installer: kernel mismatch for bookworm and sid installer. New release needed?
Package: debian-installer Version: 20210731+deb11u2 Severity: normal Dear maintainer(s) of debian-installer, I've been working on reproducible live ISO images for some time now [1] and the images can be generated in a reproducible manner. As the next step, I want to test the functionality of the live ISO images and recently I started working with Philip Hands to get them being tested in openQA. I have noticed that the officially released version debian-installer [2][3] will not work for bookworm and sid, because the kernel version in the debian- installer does not match the current kernel version. You recently fixed this in git [4]. Could you release a new version of debian-installer for bookworm and sid? Or do you recommend a different (release) strategy? I'm aware of the daily images [5], but they are currently not being snapshotted, which makes it impossible to reproduce an image after the older images have been removed from [5]. With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://snapshot.debian.org/archive/debian/20220305T025031Z/dists/sid/main/installer- amd64/20210731/ [3] https://deb.debian.org/debian/dists/sid/main/installer-amd64/current/ [4] https://salsa.debian.org/installer-team/debian- installer/-/blob/f810235e642e7ed266cc6a41b8fccd864180714a [5] https://d-i.debian.org/daily-images/amd64/daily/ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#999399: preseed: Mention the current Debian version name instead of lenny
Hello, On 10/11/2021 18:01, Holger Wansing wrote: Am 10. November 2021 16:59:42 MEZ schrieb Roland Clobus : Could this be replaced by either 'stable' or the current version name? (If you choose the latter, would it then also need to be mentioned in the 'howto prepare the next Debian release' document?) What exactly would be the rationale for such change? That's all just examples, they will have to be adapted to user's needs anyway ... Rationale: I was surprised by finding a reference to a really old version of Debian (released in 2012) in the examples that have been provided. There is no functional need to change the text. To me, it looks like a remnant of the earlier days of Debian, whose change was forgotten when the next release took place. The word 'stable' will make it look more modern (and still translator-friendly). I've marked this low-prio issue as 'cosmetic', please feel free to close it as WONTFIX. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#999399: preseed: Mention the current Debian version name instead of lenny
Source: preseed Version: 1.109 Severity: minor Hello maintainers of the preseed package, While testing Debian live images based on live-build, I noticed that the description that provides examples for the preseeding file still mentions lenny. See https://sources.debian.org/src/preseed/1.109/debian/network- preseed.templates/?hl=20#L20 Could this be replaced by either 'stable' or the current version name? (If you choose the latter, would it then also need to be mentioned in the 'howto prepare the next Debian release' document?) With kind regards, Roland Clobus -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Replacing live-wrapper for live images by live-build?
Hello Debian-Live list, Debian-Images list, debian-boot list, About a year ago I wrote [2] about my steps to reproduce the command line that is currently used to generate the live images. By then it was already clear that live-wrapper needs a replacement. Steve McIntyre wrote at that time: "The current live-wrapper code, and vmdebootstrap, are both basically dead IMHO. I've suggested moving to something else supported like FAI instead, like the Debian cloud images. highvoltage has other ideas. I'm not working on anything live-related at all any more." In November [1] I wrote to the live list about 'Porting the standard image from live-wrapper to live-build'. Since then I've continued working on live-build, which is now IMHO in a good shape (it even creates reproducible images [3]), but live-build would need some final features to be a proper replacement. These final features can be subdivided in a few categories: * Accessibility: better support for speech-synthesis and adding beeps to isolinx/grub * Localisation: support for running the live image in another language starting from the boot * Cosmetic: using the official Debian 11 artwork during the boot * Branding: the live image might need to differ between 'official' and 'unofficial' images Each of these categories can be tackled with reasonable effort, but some coordination might be required. My questions: * Has it already been decided what the replacement for live-wrapper will be? * If no, would you consider using live-build again? With kind regards, Roland Clobus [1] https://lists.debian.org/debian-live/2020/11/msg1.html [2] https://lists.debian.org/debian-live/2020/03/msg00225.html [3] https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature Description: OpenPGP digital signature
Re: The released version of debian-installer still has the old kernel
reopen 986506 thanks On 14/04/2021 08:58, Tomas Pospisek wrote: > debian-installer now has 5.10.0-5 kernel > ... thus I'm closing the bug report Hello Tomas, I think this bug report is closed a little too early. I've seen in the git commit cb6b94900c27495ed58b698fb8a4d4e00d0962b1 that the kernel version even has been bumped to 5.10.0-6, but only for the *daily builds*. The *released version* of the debian-installer still is 20201202 [1]. This is the version that is used per default by the live-build tool, which downloads from the regular location [2]. I known that the final deadline for releasing Debian 11 is getting real close, so I'm not sure whether you should be burdened by creating intermediate releases. With kind regards, Roland Clobus [1] https://packages.debian.org/bullseye/debian-installer [2] http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current OpenPGP_signature Description: OpenPGP digital signature
Bug#986506: debian-installer: Please rebuild the installer images (Bullseye) in order to get a newer kernel version
Package: debian-installer Version: 20201202 Severity: important Tags: d-i Hello maintainers of the Debian installer, Now that Debian Bullseye is in hard freeze, could you consider to update the Debian installer images to use the current kernel from Bullseye [2]? This would help in building live images using live-build [3]. The last published image of the Debian installer is from 2020-12-02 [1], and the kernel version is 5.9.0-4-amd64, while in Bullseye the kernel currently is 5.10.0-5-amd64. The daily-built images contain the current kernel [4]. With kind regards, Roland Clobus PS: This was also posted to the mailing list [5], without a reply so far [1] http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/ [2] http://deb.debian.org/debian/dists/bullseye/main/installer- amd64/current/images/cdrom/ [3] https://wiki.debian.org/ReproducibleInstalls/LiveImages [4] https://d-i.debian.org/daily-images/amd64/daily/cdrom/ [5] https://lists.debian.org/debian-boot/2021/03/msg00166.html -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'testing- debug'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Rebuilding the installer in order to get a newer kernel version
Hello maintainers of the Debian installer, Now that Debian Bullseye is in hard freeze, could you consider to update the Debian installer to use the current kernel from Bullseye? This would help in building live images using live-build [3]. The last published image of the Debian installer is from 2020-12-02 [1], and the kernel version is 5.9.0-4-amd64, while in Bullseye the kernel is 5.10.0-4-amd64. The daily-built images contain the current kernel [4]. With kind regards, Roland Clobus [1] http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/ [2] http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/20201202/images/cdrom/ [3] https://wiki.debian.org/ReproducibleInstalls/LiveImages [4] https://d-i.debian.org/daily-images/amd64/daily/cdrom/ OpenPGP_signature Description: OpenPGP digital signature
Re: "--debian-installer" of `lb config` not work in order.
Hello Xiao, Thank you for the detailed report. On 11/03/2021 04:18, ZhangXiao wrote: > On bullseye, I tried to make an ISO used to install a specific Debian > system, but seems `lb config --debian-installer live" can't make it. My > operation is: > > $ rm -rf *; lb clean; lb config --debian-installer live; lb build > > Then I get an ISO image, when I boot with it, it gives me several > choices including "Live (amd64)" and "Start installer". If I choose the > "Start installer", it will fail for "no kernel modules found", then I > "Execute a shell" in the installer and the uname tells me the kernel > version is "5.9.0.4". > > While if I choose to run the "Live (amd64)", it will boot up with the > newest kernel: 5.10.0.4 > > So I wonder if there are any issues on my operations or there is a bug > in lb? And how to make a live-cd to install a debian system with > kernel-5.10.0.4? It appears that the Debian-Installer images have not been updated yet to reflect the newer kernel version. I've copied this mail to the DebianInstaller team at debian-boot@lists.debian.org For the moment, you'll need the daily build of the installer: --parent-debian-installer-distribution daily With kind regards, Roland Clobus https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature Description: OpenPGP digital signature
