Bug#1080980: live-build still depends on bullseye
Hello Hans, list, On 06/09/2024 12:13, Hans-J. Ullrich wrote: I discovered, that live-build is still depending on bullseye. All controlling files got the entry of bullseye, whilst it should be now bookworm. Although it is not a real bug, a build is always crashing due to missing packages or wrong dependencies. I edited all entries from bullseye to bookworm and everything is working lie a charm. Please mae this be default, so that , when executing "lb config" the correct version withj bookworm entries are downloaded. Instead of changing live-build, you can use 'lb config --distribution bookworm' This is an older issue, see e.g. https://salsa.debian.org/live-team/live-build/-/merge_requests/208 I now propose the following: * Make --distribution a mandatory argument in the 'lb config' invocation series (i.e.: after validation it should be set). That solves: * No fragile logic required in the live-build code * Every user must specify the distribution version, and will not encounter surprises * No additional releases required before/during a freeze to update the distribution name Work to do: * Clean up existing logic * Remove the code that allows for 'lb build' without 'lb config' * Update the manual With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: arm64 live image working pretty well (Was: arm64 live image online!)
Hello Emanuele, lists, On 03/09/2024 20:56, Emanuele Rocca wrote: The weekly arm64 Live Image with GNOME is now available: https://get.debian.org/images/weekly-live-builds/arm64/iso-hybrid/ I have tested it under QEMU and Hyper-V and it seems to be working well, including Secure Boot. Thank you and Steve for all the work done over the past months to get to this point! And I have a preliminary test uploaded to openQA as well: https://openqa.debian.net/tests/overview?build=20240902T081351Z_sid_gnome_arm64&distri=debian&version=sid_gnome&groupid=14 live-build-apps_startstop: nearly PASS, 'Updates available' popup prevents timely detection of the proper login (this test is often flaky) live-build-desktop_browser: PASS live-build-install_to_HD_with_Calamares: the VM is slow live-build-install_to_HD_with_di: Needs adjustment in openQA to select the correct GRUB menu entry live-build-postinstall_browser: skipped (follows the di installation) live-desktop_printing: PASS walk-boot-options: Some issues with Speech synthesis and 'Automated Install' (similar to the issues with the netinst image) With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Liveid - Feedback on identifying your live cd thanks to an UUID
Hello list, On 31/08/2024 00:38, adrian15sgd wrote: ... In the live-boot MR discussion Roland Clobus has suggested to bring the discussion here in the Debian Live mailing list. So I'll try my best to make a summary so that this can discussed here. I'm primarily focussed on the scenarios, regarding booting the image, that need to be supported by live-build. I would like to know the scenarios first, before the solution is chosen. We currently have as boot test (in openQA [1]): * 'walk boot options': activates every single entry in the syslinux/GRUB menu: (BIOS, UEFI, UEFI secure boot) x (ISO as CDROM, ISO as USB device) -> 6 variants. A trimmed down version would only need to boot into the live environment (instead of testing every menu entry) To test the booting of the correct device we additionally need: * 2 different bootable devices, BIOS/UEFI is configured to boot the first device * 2 different bootable devices, BIOS/UEFI is configured to boot the second device Questions: * Would it be sufficient to differ only in desktop environment (e.g. GNOME vs KDE) or would is also need a different distribution (e.g. sid vs trixie)? * Does this need to be duplicated for BIOS/UEFI/UEFI secure? (i.e. 2 x 3 scenarios) * Would it matter if the devices are CD-ROM or USB? (i.e. a multiplication by a factor of 4 for the scenarios) Other scenarios that might need to be supported: * FST File System Transposition -> First an USB stick of suitable size (at least 5GB) needs to be prepared and then booted. This will also enable tests for persistence. This mimics how some tools for installing live images prepare an an USB stick. * Booting with the bootiso GRUB option, in which another tool chainloads one of the ISO files on a USB stick * More scenarios? If I understood from Adrian's comments correctly, in some BIOS/UEFI implementations the information about the original boot device get lost. With kind regards, Roland Clobus [1] https://openqa.debian.net/tests/overview?distri=debian&version=sid_gnome&groupid=14 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: New GRUB menu structure (Was: Live CD option for Calamares install)
Hello list, Emanuele, I'm sending my reply to debian-live for a broader audience. On 22/08/2024 20:17, Emanuele Rocca wrote: I think we should add a GRUB option to the Live CD to start Calamares directly. After using both Calamares and d-i a lot these last days, I cannot help but noticing that for desktop users Calamares is so much better in terms of... pretty much everything? Perhaps controversially, I don't think this is an opinion. :-) Having 2 installers that act (nearly) identical is 'quite interesting' from a testing perspective. The d-i variant has confused many users, since it does not do a clean install like the netinst image does, but instead installs the live image to the HD. However, I had looked at it a bit, and the d-i could be configured to run similar to the netinst image, so more user scenarios can be covered. The GRUB menu is already quite long (see e.g. https://openqa.debian.net/tests/300891), and with all options (text/GUI/speech x normal/high contrast) the testing space will explode. Additionally, the partitioning differs between Calamares and d-i. See also a long discussion in #1076952. Both installers need to synchronise when consensus has been found. It seems to me that having to answer a lot less questions and using a disk partitioning system designed for humans are two incredible advantages of Calamares. Because of this, I think there are two things we could be doing to make Calamares usage more widespread: 1) make it easier for people to know that such an option exists When starting the live image, an embedded HTML-page or similar could pop up to advertise the workings of the live image. (Not network access should be required) 2) make it easier to start Calamares once you have a live image ready Every desktop variant of the live image should have a prominent 'Install Debian' icon (1) is very difficult because it means changing the website, and doing so without making it worse is not that simple IMHO. So maybe at another point in the future. Starting a document after booting a live image is relatively easy. It needs proper content however. Hence my proposal to tackle (2): what would you say about adding a GRUB entry along the lines of "Install Debian with Calamares", which does the same thing as the current Live system but starts the Calamares installer automatically? If it is possible to start the Calamares installer via a grub line, sure, that would make it easier to install that way. This would be desirable in my view because some people may not be even aware of the fact that Debian can be installed from within the Live system, and additionally GNOME had the great idea of dropping support for desktop icons (why would you allow people to use a metaphor they've been using for decades, right?) so it's not immediately clear HOW to install Debian once the Live GNOME system has booted up. > Looking forward to your thoughts. Alternatively, the GRUB menu can be reduced to 1. Start live 2. Install the live image to the HD 3. Advanced options 3.1 UEFI settings 3.2 Safe booting (although the current safe options do not work reliably on a openQA) 3.3 Install live to HD with variants A, B, C, D... 3.4 Install from scratch with variants A, B, C, D... With kind regards, Roland OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1080202: debian-live-12.7.0-amd64-kde.iso: screensaver not disabled
Hello Simon, On 31/08/2024 17:01, Simon McVittie wrote: To reproduce: * boot debian-live-12.7.0-amd64-kde.iso * wait for the screen to blank/lock * wake up the machine and try to use it Expected result: ideally the screen would blank but not lock, since a well-known password doesn't provide any meaningful security Actual result: you have to "just know" that the password is "live" This looks like a duplicate #995364 (from 3 years ago). Effectively it is a feature request: Disable the screensaver for all live images. It would probably also be meaningful to disable the password after waking up from hibernate/sleep, since then typically the password is prompted too. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Live-Image for Debian Junior (trixie)
Hello Stefan, On 14/08/2024 22:34, Stefan Kropp wrote: On Sa, 03.08.2024 10:25:52, Roland Clobus wrote: On 29/07/2024 21:20, Andrew M.A. Cater wrote: On Mon, Jul 29, 2024 at 06:51:44PM +, Stefan Kropp wrote: is it possible to add "Debian Junior" to the live-images? Hello Roland, @Stefan, I assume you mean the weekly images that are published on https://get.debian.org/images/weekly-live-builds/amd64/iso-hybrid/ and are based on Trixie? Correct. About 6 months ago I created a branch in live-build. Now I made it more visible as a MR [1], and it can be integrated in the live-setup and images-team/setup repositories. When that is done, they will be re-generated every week. About CONFIGURATION_FROM_GIT https://salsa.debian.org/live-team/live-build/-/merge_requests/360/diffs#9221863742451e920c978c9e0eb2f9bd58bf2777_212_214 I recommend to build the image like all others. Debian Junior is also part of live-tasks: https://tracker.debian.org/pkg/live-tasks live-task-debian-junior Maybe like this: "debian-junior") INSTALLER="live" PACKAGES="live-task-debian-junior" In this case, we also following the "upload" process and the image will be build of files which are part of Debian already. I've locally generated live images for sid and trixie with this setting, and noticed the following differences to the 0.1.0-alpha-4 image: * No 'Debian Junior - Readme' in the menu * Smaller font/icons * The four coloured bubbles (in the bottom bar) with games by category are not there any more * Localization: it's now English instead of German * The icewm configuration changes that were in includes.chroot_after_packages/usr/share/debian-junior/user/config/icewm are not applied any more Perhaps you need another package in the Junior Blends namespace that overrides/adjusts the settings? See below... I've had a quick peek at the git-repo that has the configuration for the blend, it has not been updated since 2023-04-30. Is the development speeding up and do you need the images to be generated on a weekly basis? No, from my side it's not required to have a weekly build, yet. First, I would like to see if everything is working as expected. Ack, so no weekly build yet. Then: lets move the follow-up mails to debian-live instead of debian-cd. There is also a chicken-egg issue here from the QA perspective. Should there be more tests (reproducible image, openQA functionality tests, ...) before the image is spread more widely? Or will the test be created afterwards? Good question. :) The package is a meta package,.. I'm not sure about functional tests on meta packages. Be honest, I didn't think about openQA. For functionality tests, I'm thinking initially about the 'start-stop' tests. These tests start the program, look whether its initial screen shows up, optionally do a few mouse clicks or keypresses and finally check whether the program exited gracefully. Sure, when the image would be build based on the CONFIGURATION_FROM_GIT, it would be important. But I think it shouldn't be build bases on the repository itself. The CONFIGURATION_FROM_GIT variable that I introduced allows for tweaking/constructing the live image without needing to have all settings packaged. I can update the MR to just use 'live-task-debian-junior', when you give me a heads-up, but then you'll have to find another way to tweak some settings. I'm perfectly fine with using the CONFIGURATION_FROM_GIT which I introduced; I have thought about re-activating the live-images repo on Salsa again, but that will time some time... With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/360 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1078442: live-build: zsync removal from testing prevents building images based on trixie
Control: tags 1078442 +pending Hello all, I just pushed a MR on Salsa [1], which got merged already. (Thanks bluca :-) Said MR changes the default value for `--zsync` to false. Given that: a) zsync was orphaned 2021-09-19 #994648; b) zsync FTBFS with GCC-14 #1075710; c) zsync was only available for iso and iso-hybrid; d) zsync output is ignored by the live-setup package which generates the official live images; I think that changing the default to the 'safer value' is the best way forward. However, if someone would take over the maintenance of the zsync package, that's fine as well. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064408: [PATCH] duplicate aliased diversions for DEP17
Hello Helmut, On 02/08/2024 15:48, Helmut Grohne wrote: Hi Roland, On Fri, Aug 02, 2024 at 03:01:51PM +0200, Roland Clobus wrote: I've prepared a MR which takes a different approach. https://salsa.debian.org/live-team/live-build/-/merge_requests/359 Thank you for working on this matter. Since the support of live-build starts from bullseye, and symlinks are present since then, should using only '/usr/X' be sufficient? The unfortunate answer is "no". dpkg-diversions apply to the path as seen by the dpkg database only and are not affected by symlinks such as /bin -> usr/bin. Even if the symlink moves /bin/hostname to /usr/bin/hostname, as long as hostname is still named as /bin/hostname in the hostname package, it can only be diverted via /bin/hostname. As long as you want to support bullseye or bookworm, the diversions should be duplicated. I was able to generate functional ISO images for bullseye, bookworm, trixie and sid. Despite me claiming your MR to be buggy, this test result of yours is plausible. Since the live-build scripts do no need an upgrade (they are used for fixed version) do I need the doubled diversion? You convey a very crucial bit of information in this question. The diversions (doubled or not) are only really needed for upgrading. If you just create a chroot and then replace a few files normally owned some package and you never intend to use the package manager again, the benefit of using a diversion becomes questionable. It is not clear to me whether you install or upgrade packages after setting up diversions. If you do, you should keep and double diversions (as long as bookworm is supported in live-build). If you do not, you may just overwrite the files without doing any diversions. There is another bit of information that I didn't share yet: these diversions are only temporary. The diversions are made during the construction of the live image (when other packages are installed and the packages that have diversions will not upgrade), and reverted before the image is finalised. They are not present inside the live images. They 'only' serve the purpose of saving time by performing a no-op during the construction of the live image. Since during the construction the symlinks work properly and there are no upgrades in the mean time, do we need to patch anything at all? Also: do I need to update all shebangs from `/bin/sh` to `/usr/bin/sh` as well? Please don't. You already changed more places than I recommend to change. What really needs to change is the placement of files in the data.tar inside Debian binary packages (to eliminate aliasing problems). As a result of this move, the diversions need to be duplicated. However, accessing files can use either path and I recommend leaving such references as is. We will forever rely on the aliasing links. For instance, the dynamic loader explicitly uses an aliased path. Hence there is little benefit in referencing files via their /usr paths. Ah, I (erroneously) thought that the whole purpose of moving the files to /usr was to (eventually) get rid of the symlinks (in forky+N). With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian Live Testing xfce – there is no 'curl','wget'
+debian-live Hello zyli, On 06/08/2024 07:56, zyli wrote: $ cat /run/live/medium/.disk/info Auto-generated Debian GNU/Linux Live testing xfce 2024-08-05T02:13:45Z $ apt policy curl curl: Installed: (none) Candidate: 8.8.0-4 $ apt policy wget wget: Installed: (none) Candidate: 1.24.5-2+b1 I think it would be good to have one of them installed. That is a known bug: https://bugs.debian.org/1069498#32, I collect a list of known issues with live images near their tests: https://openqa.debian.net/group_overview/14 I was hoping that that bug would have been resolved by now. Alternatively, curl can be added to `live-task-recommended`, which is under control of the live team. With kind regards, Roland Clobus PS: Follow-up mail can exclude debian-cd, as debian-live is the correct mailing list OpenPGP_signature.asc Description: OpenPGP digital signature
Re: depbootstrap ARM qemu user-mode extremely slow only on trixie
+debian-live On 05/08/2024 09:17, Thore Sommer wrote: while updating our distro for ARM from bookworm to trixie, I noticed that our builds using qemu user-mode are now extremely slow. A debootstrap went from 5min for bookworm to 38min for trixie. I'll assume that you use the git version of live-build. I'm currently investigating why this happens, but before I start profiling QEMU, I thought I ask you where to look, as you might have seen the same phenomenon. Was there an change in trixie that might affect emulation performance (i.e. new security features by enabled default)? There has indeed been a change: https://salsa.debian.org/live-team/live-build/-/commit/2f1acabc41414a596b5e7552166a4082f738d0e2 changed the logic to detect whether the bootstrap phase would need to run with the architecture of the host, or under QEMU. The file `scripts/build/bootstrap_debootstrap` now checks whether LB_BOOTSTRAP_QEMU_ARCHITECTURE is set to any value (i.e. if `--bootstrap-qemu-arch` is used in `lb config`), and if set, will use a 2-stage bootstrap, which is much slower. However, if you only changed the `--distribution` commandline option, there should be no significant difference. Can you post your `lb config` line? I already tried with a variety QEMU versions (5.2, 8.1, latest git snapshot), distros (bookworm, trixie) and kernel combinations, with no effect and because the bookworm builds are still way faster, I assume something has changed in how trixie is build that makes emulation slower. I've recently posted a break-down of the execution times of a cross-build for the GNOME image (trixie): https://lists.debian.org/debian-cd/2024/08/msg1.html That also takes about 30 minutes for the bootstrap. These are my current timings: lb config --distribution bookworm --architecture arm64 --bootstrap-qemu-arch arm64 --bootstrap-qemu-static /usr/bin/qemu-aarch64-static lb bootstrap bookworm: 6 minutes trixie: 38 minutes I guess that the main cause will be debootstrap. You might want to try a pending MR as well. https://salsa.debian.org/live-team/live-build/-/merge_requests/343 With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Rescatux 2024 development and Live Build
Hello Adrian, Thanks so far for the MRs, I barely have found the time to look at them properly. On 12/07/2024 23:46, adrian15sgd wrote: Hi Debian Live, I wanted you to know that I am resuming Rescatux development. 1) Rescatux is a Debian-based live distribution featuring a graphical wizard for rescuing broken GNU/Linux and Windows installations and boot loaders. ( https://www.supergrubdisk.org/rescatux/ ). Rescatux is built thanks to live-build onto a CDROM that supports: - 686 kernel 686 is getting less support for trixie, at least the d-i will not be made available any more; I'm unsure how long a 686 kernel will be in Debian. For live-build I'm providing support for bullseye, bookworm, trixie and sid, but not older versions. - amd64 kernel - IA32 UEFI - x64 UEFI - Media with SELinux Filesystem so that the Live Media can be boot in SELinux Permissive mode. - Automatic Arch Detection for Syslinux - Automatic Arch Detection for Grub2 (This is already in upstream live-build) - LiveID so that two different isos can be differentiated. . 2) As such I will be adding either new features to live-build or recycling old features that only were found on the Rescatux's live-build ( https://github.com/rescatux/live-build ) and live-boot ( https://github.com/rescatux/live-boot ) forks. My main approach will be to send draft merge-requests onto Salsa and just discuss them there. That's what I was advised to do back in the day, probably around 2021. If you think it's much better to discuss them in a thread here in the mailing list just let me know. Having smaller bits to review will be easier to have it integrated in the main branch. 3) As a summary of what I will be working on (which might be converted onto a Merge Request or not) is: - Add SELinux support to live-build ( https://github.com/rescatux/live-build/commit/d93a98634bb915c4c943a7b53dc9f44e8c5a5e4b ) - Add LiveID support * Live-boot ( https://github.com/rescatux/live-boot/commits/liveid-001/ ) * Live-build ( https://github.com/rescatux/live-build/commits/1a895c14216fe4f3a241b456fa19d1c603558fd2/ ) * About LiveID ( https://github.com/rescatux/liveid ) > - IA32 UEFI shim not provided when 686 and amd64 are installed * https://github.com/rescatux/live-build/commit/c8738fb101859f23b3e74623e9696f5c3940a9b3 * https://github.com/rescatux/live-build/commit/0713b0c409714e1214ccbff5a5daa67f0e95164f I managed to peek at this already, while writing this mail. - Arch Detection for Syslinux * https://github.com/rescatux/live-build/commit/99ddc7bb9510ee4810b55a391e35060dd68cf9ee * https://salsa.debian.org/live-team/live-build/-/merge_requests/25 - Non-free firmware by default in Live-Build * https://lists.debian.org/debian-live/2022/12/msg2.html non-free-firmware is properly supported in live-build nowadays and is enabled when `--archive-areas "main non-free-firmware"` is used (bullseye needs 'main non-free contrib'). Be aware that the links above are branches or tags related to 2021's code so that's not what I'm going to Merge Request. I will have to rework some code and probably some of it will be written from scratch. I have added the links just in case anyone was curious about knowing more about these features. 4) So if you see that I begin to post here or in the salsa merge requests more frequently than before that's why. Your MRs are welcomed, but (as you well know) time is the limiting factor. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: debootstrap
Hello Maria, On 02/08/2024 19:32, maria.shrivinski wrote: does somebody know how to change the (base) packages that are installed during the deboostrap stage? I couldn't find anything in `/usr/lib/live/build` I would like to build with |lb config --distribution bookworm| but have the default packages that are installed during the debootstrap stage be installed from the sid (unstable) repository. Is that even possible? I'm wondering why you would need to mix bookworm and sid in the bootstrap phase. That is rather early and I would not recommend to create a mixed system at this moment, but only later during the chroot phase, where you have more control over which version you will get. Earlier this week you wrote about APT Pinning [1], is this question related to that? Could you add a hooks script that does something similar to 'apt-get install mpv -t unstable' while the pinning for all packages from sid (including mpv and its dependencies) is such that it will not automatically happen? (You can have the mpv version from bookworm installed already, then it updates only a few packages) With kind regards, Roland Clobus [1] https://lists.debian.org/debian-live/2024/07/msg00023.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064408: [PATCH] duplicate aliased diversions for DEP17
Hello Helmut, On 21/02/2024 18:04, Helmut Grohne wrote: > /bin/hostname and /sbin/start-stop-daemon are being moved from / to /usr > in trixie. Hence, these diversions become ineffective. Temporarily add > both diversions to handle both variants. I've prepared a MR which takes a different approach. https://salsa.debian.org/live-team/live-build/-/merge_requests/359 Since the support of live-build starts from bullseye, and symlinks are present since then, should using only '/usr/X' be sufficient? I was able to generate functional ISO images for bullseye, bookworm, trixie and sid. Since the live-build scripts do no need an upgrade (they are used for fixed version) do I need the doubled diversion? Also: do I need to update all shebangs from `/bin/sh` to `/usr/bin/sh` as well? With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Problems with live testing install in encrypted mode
Hello Brandon, On 03/07/2024 18:40, Brandon Werner wrote: After the patches landed to fix mounts recently in calamares-settings-debian, I decided to test the installer. https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-mate.iso <https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-mate.iso> If I check the box for encryption, and pick the radio button to erase and use the disk, I have problems with the installed system. After rebooting, entering my password, and going through the boot menu, I am dropped at an initramfs busybox prompt. Can you send the sha256sum of your ISO file? I guess that you might have a slightly too old version. The current checksum is 210d94a36c8b3ec5b980afb34b6f8267f864d1cab43eec0a9e6df4137af16635 for the mate image. The patch needed some time to migrate from sid to testing, so it is present only in the images from 20240701T081140Z, which got published yesterday on https://get.debian.org/images/weekly-live-builds/amd64/iso-hybrid/ See the openQA tests which now passes: https://openqa.debian.net/tests/278394 With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How to create a custom Debian ISO
Hello Aditya, On 19/05/2024 13:45, Aditya Garg wrote: I also happed to come across this guide https://www.willhaley.com/blog/custom-debian-live-environment/ <https://www.willhaley.com/blog/custom-debian-live-environment/>. Is it worth trying? It's quite similar to Ubuntu ISOs. Well, I'm biased here, being one of the maintainers of live-build... So I would suggest not to follow those steps, because you would re-implement a lot that is already performed by live-build, with the risk of falling into all the traps that have already been solved. Those instructions strip down all the steps that live-build does down to the barest minimum. When using live-build, I suggest you use the git version (not the packaged version) as detailed on [1]. You will get: * An installer in the boot menu (if you require that) * Have a reproducible image (bit-for-bit identical if re-built at a later moment) * The benefit of using a package that is used by several distros instead of being the only distro using your own scripts, which means that there will be less bugs With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How to create a custom Debian ISO
Hello Aditya, On 19/05/2024 13:08, Aditya Garg wrote: Just to get a clarification, would the user be able to install Debian in a live build as well? Yes, the current Debian live images contain both a Debian-Installer and Calamares which will install the live images to your hard disk. Additionally (not well tested yet) it can run the Debian-Installer similar to the Debian-Installer from the netinst image, i.e. it will perform a full customised installation. You can find weekly builds at [1], with the test results at [2]. With kind regards, Roland Clobus [1] https://get.debian.org/images/weekly-live-builds/amd64/iso-hybrid/ [2] https://openqa.debian.net/group_overview/14?only_tagged=1 PS: No need to CC me, I'm subscribed to the lists OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How to create a custom Debian ISO
Hello Thomas, On 18/05/2024 14:23, Thomas Schmitt wrote: since Aditya Garg gets a reply here at debian-live, i add a link to the thread on debian-user, beginning with Marvin Renich's proposal to continue the thread there: https://lists.debian.org/debian-user/2024/05/msg00149.html (I proposed for Debian Live https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html and for Debian installation ISOs https://wiki.debian.org/RepackBootableISO ) Thanks for pointing to live-build :-) I saw the discussion originally on debian-devel, and it switched several times (Also I switched it away from debian-devel) Roland Clobus wrote: I had a quick peek at the scripts you use [1]. [1] https://github.com/t2linux/T2-Ubuntu/tree/LTS It appears to me that you want to create a custom Debian Live ISO (not a netinst image). Just out of pure curiosity: From what script in particular do you get this impression ? The scripts with the sequence numbers 01-04 mirror the steps that are done in live-build, with the difference that live-build is more complex/configurable, due to it multi-purpose-tool character. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How to create a custom Debian ISO
+debian-live Hello Aditya, On 11/05/2024 10:21, Aditya Garg wrote: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. Let me chime in on this thread as well. I had a quick peek at the scripts you use [1]. It appears to me that you want to create a custom Debian Live ISO (not a netinst image). If so, you can take a look at live-build, which is used for the Debian live images. Steps describing how to build a live ISO image are at [2] and a generic manual for live-build is at [3]. You can then build an ISO image from their packages, without the need for repacking (and automagically all checksums will match) With kind regards, Roland Clobus Co-maintainer of live-build [1] https://github.com/t2linux/T2-Ubuntu/tree/LTS [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages [3] https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069349: live-build: Regression in d14306a7 leading to build failures
On 02/05/2024 12:14, Daniel Reichelt wrote: Hi Roland, > On 20/04/2024 13:32, Daniel Reichelt wrote: > What are you doing that makes the directory 'config/includes.binary' > disappear? > If I use 'lb config --distribution sid', the directory is created (but > empty) and there will be no error message. I'm keeping my (final, i.e. `lb config`ured) config-trees in git which has been working for over a decade so far. Ah, that's a known feature of git: it does not store empty directories (therefore often a hidden file .gitkeep or .gitignore is used [1]) > the directory is created (but empty) and there will be no error > message. It is not a good practise to depend on the existence of empty directories, IMHO. Your commit message says nothing abaout the patch in scripts/build/binary_includes. Why did you move those lines in the first place? I placed a hidden directory in it (.disk), and that could not be found by 'Find_files', so I shifted things around. All my test scenarios are a combination of 'lb config' and 'lb build', so I couldn't see an issue with the missing directory in my local tests. I'll prepare a proper fix that detects whether the directory is present. With kind regards, Roland [1] https://stackoverflow.com/questions/7229885/what-are-the-differences-between-gitignore-and-gitkeep OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package "usr-is-merged" is reported as missing in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) during installation with live-installer/enable=false
Hello, On 01/05/2024 23:43, Cyril Brulebois wrote: Thanks Cyril for passing along the mail to the debian-live mailing list. Computer Enthusiastic (2024-05-01): The "Normal" [0] Debian Installer included in Debian Live ISO 12.5 (debian-live-12.5.0-amd64-lxqt.iso) fails the installation of the base system when started with the following preseed parameters: live-installer/enable=false firmware=never The Debian installer stops deboostrap with the following error Could not find these debs: usr-is-merged The installation of the base system is not completed even if the base-install step is repeated. You have provided 2 kernel options, both of which are not regularly tested. Effectively, you are running a live image with the netinst installer settings. The debootstrap phase only uses the packages from the image, even though the network has already been detected. I'll mark this on the todo page. For the short term, you can use the netinst image instead. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069349: live-build: Regression in d14306a7 leading to build failures
Hello Daniel, On 20/04/2024 13:32, Daniel Reichelt wrote: Package: live-build Version: git-master Severity: normal Hi all, I recently built a .deb of the current master and noticed build failures like this: ---8<-- P: Begin copying binary includes... /usr/lib/live/build/binary_includes: 36: cd: can't cd to config/includes.binary E: An unexpected failure occurred, exiting... ---8<-- ...since I don't have any files stored in config/includes.binary and since commit d14306a7, the check for the exixtence of such files is no longer happening. What are you doing that makes the directory 'config/includes.binary' disappear? If I use 'lb config --distribution sid', the directory is created (but empty) and there will be no error message. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian Installer bug/issue in all live image DVDs
Hello Reid, list, On 01/05/2024 15:30, Reid wrote: ...snip... The following is what I found, which I believe are important Installer bugs that need fixing: 1) Bug #1 / Debian installer / all live image DVDs: > When using the Debian Installer on live images, it installs 29 non-free components without opt-in/out or warning. ...snip... This is a longer standing issue, which I've seen causes a lot of confusion. You are not the first to stumble upon it, there are several bug reports and mailing list questions about it. The installer that is provided on the live image is not the regular installer as on the netinst image, but instead it copies the whole live image onto your hard disk and removes some language packs and the live-specific packages afterwards. It should be possible to run the installer from the live image in a similar way as the netinst image, but I haven't tested whether that works as expected. The official live images are generated already in 8 flavours, and duplicating them requires a lot of additional testing effort. Do you volunteer to test them? As you wrote, the firmware packages are available per default on the live images, for the reason that modern hardware will probably need some firmware to be working properly, as noted on the non-free-firmware page [1]. Since you wrote that you have 29 non-free-firmware components (BTW there is no non-free on the live images) after installation, you probably needed them for the hardware support. I'm curious, does your computer still work properly after you have removed them? If you don't want/need the firmware, I'll refer you to use the netinst installer, which suits your level of expertise and offers the option 'firmware=never'. ...snip... Recommendation: While I think the suggestion for #1 above would be an acceptable solution to this issue as well, there should at least be an error message or warning to inform users that the "firmware=never" instructions don't work when installing via live image DVDs. Some time ago I've already added the feature request to the TODO list [2] to rename the 'install' option to reflect its current behaviour. That would be a step forward, and supporting another kernel option will be implemented later, unless someone provides a suitable patch. Debian is in flux, as can be seen on openQA [3]. Keeping the basics working is my first priority. Patches are always welcome. With kind regards, Roland Clobus --- [1] https://wiki.debian.org/Firmware [2] https://wiki.debian.org/DebianLive/TODO [3] https://openqa.debian.net/group_overview/14 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068753: live-build: Should not install raspi-firmware on x86_64
Control: severity -1 normal Control: tags -1 +pending Control: tags 1065640 +pending Control: merge -1 1065640 Hello Vasudev Kamath, Built the live image for bookworm using live build (on bookworm as well as from unstable). Note that the version which is on bookworm will not be updated. The built image incldes raspi-firmware which is not meant for x86_64. I was installing some dkms module which will regenerate initrd etc and that failed with below error ... The only way to fix this situation was to remove raspi-firmware in the live image. For now I'm working around the situation using following hook file which I use during live image build ... Can we avoid installing it on x86 architecture by default. If some one needs it they can pull it. The issue has already been fixed, it is just not yet released. You can use the version from the git repository as details here: https://wiki.debian.org/ReproducibleInstalls/LiveImages It was claimed to be fixed by 12.2 in this [1] but it probably only fixed official live images but not the live build? There is also another ticket [2] but does not give proper details so created a new one Instead of creating a new bug, you could have sent a mail to the old one with your additional information. I've merged both bug reports. The official Debian live images got fixed for 12.2, because the official images use the git repository for live-build instead of the .deb-package. Let me know if any other information is needed from my side. Please wait a while, a few other changes are pending and then a new release can be made. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 24th update of the status for reproducible live-build ISO images [1]. Single line summary: 79.5% reproducible live images (yup, lower than last time; see below for the calculation) Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * All major desktops built reproducibly for the official Debian live images for bookworm (12.5.0) at any later moment ... ** ... except for KDE, which has only 1 issue left in 12.5.0 (fix is prepared for 12.6.0 [2]) * For sid the images cannot be generated, ... ** ... occasionally debootstrap breaks (due to the 64-bit time_t transition) ** ... currently the installer FTBFS (due to the 64-bit time_t transition) ** ... currently the installer FTBFS (due to a version mismatch of grub-efi-amd64-signed and grub-common) ** ... but the smallest image can be generated, however only with shim-support for secure UEFI boot Functionality status: * On sid the smallest image only has the shim boot, so you'll need to enroll the hash for the grubx64.efi file yourself (see openQA for the steps [3]) * Calamares got (temporarily) removed from trixie during the 64-bit time_t transition [4] My activities in March: * Visit to the MiniDebCamp in Hamburg [5] ** Worked with ema on arm64 native and cross-builds (MR pending) ** Worked with elbrus on stabilising a flaky test [6] ** Worked with fil on openQA tests * Prepared a small documentation update for the live-manual [7] * Bug report on diffoscope [8] * Added support for shim without signed grub [9] Work to be done: * Currently in progress: disable apt updates when persistence is not used (saves bandwidth and stabilises tests) * Currently in progress: finalise arm64 support (native and cross-build) * Currently in progress: firmware support in live-build (it looks like /usr-merge affects the location of the firmware files) * See the TODO page [10] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/339 [3] https://openqa.debian.net/tests/246742#step/bootwalk_0/2 Breadcrumb: Debian Live | *_sid_smallest_build | walk-boot-options@uefi-secure | bootwalk_0 [4] https://bugs.debian.org/1061330 [5] https://wiki.debian.org/DebianEvents/de/2024/MiniDebCampHamburg [6] https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/e9cae80b3792ff97bf79d01c506a06ab7497eab3 [7] https://salsa.debian.org/live-team/live-manual/-/merge_requests/36 [8] https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/367 and https://bugs.debian.org/1065498 [9] https://salsa.debian.org/live-team/live-build/-/merge_requests/344 [10] https://wiki.debian.org/DebianLive/TODO 79.5%: based on 4 versions x 9 variants + 8 variants; 8 FTBFS, 1 non-reproducible OpenPGP_signature.asc Description: OpenPGP digital signature
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 23th update of the status for reproducible live-build ISO images [1]. Single line summary: 97.7% reproducible live images Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * All major desktops built reproducibly for the official Debian live images for bookworm (12.5.0) at any later moment ... ** ... except for KDE, which has only 1 issue left in 12.5.0 * Last month a question was raised, whether the distributed sources are sufficient to rebuild the images. The answer is: probably yes, but I haven't tried. The chain is: source code --compiler--> executable files --debian packaging--> .deb archives --live-build--> live images I've focused on the last section of this chain; the installation of the .deb archives into the live images. My activities in February: * Rebuilding all images for 12.5.0 * The KDE image in 12.4.0 had 2 sources of non-reproducibility ** Issue 1: order in the filesystem for vlc, has been worked-around for 12.5.0 [3]. An upstream fix would need sorting of the output of `readdir`, which would be some copy of the code from disorderfs ** Issue 2: unstable sort in install-info, was fixed upstream [4] for trixie and worked-around [5] for the (future) 12.6.0 bookworm release, which is planned for April * The MR for better udeb handling [2] is now merged, the installer for the trixie images uses DHCP again. * Some bug triaging, closing old bug reports * The official weekly live images are now regularly fed to openQA for functionality tests (in addition to the images generated by Jenkins) * Unfinished: support for cross-builds to arm64 in the helper script (including documentation) * Unfinished: pre-release work-around for #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) Work to be done: * Visit to the MiniDebCamp in Hamburg [6] * See the TODO page [7] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/337 [3] https://salsa.debian.org/live-team/live-build/-/merge_requests/338 [4] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=01b5a4b9c33bef08feae041c221f820a1c76749f [5] https://salsa.debian.org/live-team/live-build/-/merge_requests/339 [6] https://wiki.debian.org/DebianEvents/de/2024/MiniDebCampHamburg [7] https://wiki.debian.org/DebianLive/TODO 97.7%: based on 4 versions x 9 variants + 8 variants OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Copy filesystem.squashfs (only) to ram
Hello Vladimir, On 18/02/2024 14:44, Vladimir Smelhaus wrote: Dne 18. 02. 24 v 13:38 Roland Clobus napsal(a): If I understand you correctly, you perform a live boot from the disk that you want to erase. And then (without 'toram') you can't format it, because you need access to the filesystem.squashfs file (which is then being removed) Yes. With toram you don't need access to a boot device anymore after successful boot. You can even format or wipe it. And this is what was asked at the beginning of this thread. I get it. But it eludes me how you do so. I guess that I don't understand why you need 'toram'. A regular live iso image is typically transferred to some other medium (USB pen, DVD/CDROM). In such case, there is no need to wipe the boot medium while being booted from the live environment, because you can wipe the USB pen instead of filling it with the live system. How do you prepare the computer that needs to erased? With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Copy filesystem.squashfs (only) to ram
Hello Vladimir, On 18/02/2024 11:49, Vladimir Smelhaus wrote: Dne 18. 02. 24 v 11:04 Roland Clobus napsal(a): Why do you need to have filesystem.squashfs in RAM? If you boot from a USB or DVD/CD-ROM medium, the filesystem.squashfs resides there, and there is no need to have a copy in RAM. After the live system has been booted, you can wipe all disks as you want. Sorry, but that's not true. When debian live boots, filesystem.squashfs (and possibly other .squashfs images) are mounted into loop devices and then an overlay filesystem is created from them. But the squashfs images still have to be accessible somewhere. So if they are loaded into RAM beforehand, the whole system can work even if the boot device is disconnected. If debian live boots from a particular disk, you can't format that disk without toram, for example, because you would lose the filesystem.squashfs (and possibly others) from which the underlying loop devices are created. I'm trying to understand your use case. If I understand you correctly, you perform a live boot from the disk that you want to erase. And then (without 'toram') you can't format it, because you need access to the filesystem.squashfs file (which is then being removed) I was assuming that you boot from a USB pen and that you keep the USB pen attached while wiping the local other disk(s) of the computer. In this scenario I see no need for 'toram' (apart from some file access). With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Copy filesystem.squashfs (only) to ram
Hello Vladimir, On 18/02/2024 09:31, Vladimír Šmelhaus wrote: Dne 18. 02. 24 v 9:16 Narcis Garcia napsal(a): [here the referred patch] Yes, this is it. Your patch is not forgotten. The live system has so many options, it is hard to keep up with all of them. Testing/Verifying the proposed changes takes a lot of time. With the possibility to boot from USB-pens, I would assume that the need for 'toram' had decreased, since these are much faster than CD-ROMs. Therefore your patch has not reached the top of the todo list (yet). With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Copy filesystem.squashfs (only) to ram
Hello Alex, On 17/02/2024 04:33, Alex King wrote: I'm wanting to use a debian-live image to wipe the disks on some systems being decommissioned. To do that, I believe I need to copy filesystem.squashfs into ram so it isn't sitting on a disk to be wiped. Why do you need to have filesystem.squashfs in RAM? If you boot from a USB or DVD/CD-ROM medium, the filesystem.squashfs resides there, and there is no need to have a copy in RAM. After the live system has been booted, you can wipe all disks as you want. I tried live-boot(7)"toram" paramater. This actually worked on my test machine, but to my surprise it copied the whole 4G root filesystem to ram instead of just filesystem.squashfs. While it worked on this system (albeit wasting a lot of time and RAM from the 16G on this machine), it would not work in other cases where the root filesystem may be 500G and RAM only 4G. On the live images nearly all of the size is used by filesystem.squashfs, so you wouldn't win a lot if you copy only that file to RAM. If you need something with a smaller footprint, you can use the 'standard' image, which does not contain a graphical environment. If you want to have your own set of packages in the live image, I would recommend to build you own. See [1] and [2]. With kind regards, Roland Clobus [1] https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062641: live-build Removes User Packages Installed via Hooks
Hello Arszilla, On 02/02/2024 08:58, Arszilla wrote: When users install `.deb` packages that are not available in Debian via a `.chroot` hook (such as `1password`), the `./live/filesystem.packages-remove` file in the generated ISO uninstalls the packages installed via `.chroot` after the system is installed. This was not the case until this action (which was added 12 years ago) became active a year ago: - https://salsa.debian.org/installer-team/live-installer/-/commit/ad0ebaad - https://salsa.debian.org/installer-team/live-installer/-/commit/ca1e1706757ecc9a4cf1fa5c637d5a9b513acee6 I still think that removing all live-related packages in the installer is a good idea. The processing of 'live/filesystem.packages-remove' shows where the package management system has been circumvented. Because certain packages cannot be installed without `.chroot` hooks, I recommend reverting this change. It was discussed that users should drop their `.deb` packages to the `packages.chroot` directory instead, as that is the intended way. However, certain programs such as `1Password`, `docker` (from Docker's repositories), ProtonVPN, etc. only use the `.deb` packages to add their repos to the system and not install packages, which require users to `sudo apt update && sudo apt install -y `. I've tried to reproduce the case with 1Password (on Debian sid). When the .deb file is provided in either config/packages.chroot or config/packages, it will not be installed per default, because the name '1password' is not a package name that is known. I then ran live-build with '--interactive=true' (which has a similar effect as writing a hook for config/hooks/normal) and installed the package with 'dpkg -i 1password-latest.deb' and 'apt --fix-broken install' This indeed resulted in the file 'binary/live/filesystem.packages-remove', which will remove 1password after installation. But a proper registration of the foreign repository will result in 1password to be installed in the chroot, and not to be removed by the installer. The commands below were taken from the 1password website: https://support.1password.com/install-linux/ --- lb config --keyring-packages ca-certificates mkdir -p config/includes.chroot_before_packages/etc/apt/sources.list.d mkdir -p config/includes.chroot_before_packages/etc/debsig/policies/AC2D62742012EA22 mkdir -p config/includes.chroot_before_packages/usr/share/keyrings echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/amd64 stable main' > config/includes.chroot_before_packages/etc/apt/sources.list.d/1password.list curl -sS https://downloads.1password.com/linux/debian/debsig/1password.pol > config/includes.chroot_before_packages/etc/debsig/policies/AC2D62742012EA22/1password.pol curl -sS https://downloads.1password.com/linux/keys/1password.asc | gpg --dearmor --output config/includes.chroot_before_packages/usr/share/keyrings/1password-archive-keyring.gpg echo "1password" > config/package-lists/1password.list.chroot --- While preparing this mail, I had to make a local hack to ensure that live-build would continue (adding 'apt-get update' in chroot_install-packages, but this seems to be a proper way to handle the foreign .deb file Since the 1password.deb file properly registers within the package management system, this ticket becomes a 'works for me'. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062641: live-build Removes User Packages Installed via Hooks
Hmm. My first reply didn't make it, resending... Forwarded Message Subject: Re: Bug#1062641: live-build Removes User Packages Installed via Hooks Date: Sun, 4 Feb 2024 17:41:42 +0100 From: Roland Clobus To: Arszilla , 1062...@bugs.debian.org Hello Arszilla, On 02/02/2024 08:58, Arszilla wrote: When users install `.deb` packages that are not available in Debian via a `.chroot` hook (such as `1password`), the `./live/filesystem.packages-remove` file in the generated ISO uninstalls the packages installed via `.chroot` after the system is installed. This was not the case until this action (which was added 12 years ago) became active a year ago: - https://salsa.debian.org/installer-team/live-installer/-/commit/ad0ebaad - https://salsa.debian.org/installer-team/live-installer/-/commit/ca1e1706757ecc9a4cf1fa5c637d5a9b513acee6 I still think that removing all live-related packages in the installer is a good idea. The processing of 'live/filesystem.packages-remove' shows where the package management system has been circumvented. Because certain packages cannot be installed without `.chroot` hooks, I recommend reverting this change. It was discussed that users should drop their `.deb` packages to the `packages.chroot` directory instead, as that is the intended way. However, certain programs such as `1Password`, `docker` (from Docker's repositories), ProtonVPN, etc. only use the `.deb` packages to add their repos to the system and not install packages, which require users to `sudo apt update && sudo apt install -y `. I've tried to reproduce the case with 1Password (on Debian sid). When the .deb file is provided in either config/packages.chroot or config/packages, it will not be installed per default, because the name '1password' is not a package name that is known. I then ran live-build with '--interactive=true' (which has a similar effect as writing a hook for config/hooks/normal) and installed the package with 'dpkg -i 1password-latest.deb' and 'apt --fix-broken install' This indeed resulted in the file 'binary/live/filesystem.packages-remove', which will remove 1password after installation. But a proper registration of the foreign repository will result in 1password to be installed in the chroot, and not to be removed by the installer. The commands below were taken from the 1password website: https://support.1password.com/install-linux/ --- lb config --keyring-packages ca-certificates mkdir -p config/includes.chroot_before_packages/etc/apt/sources.list.d mkdir -p config/includes.chroot_before_packages/etc/debsig/policies/AC2D62742012EA22 mkdir -p config/includes.chroot_before_packages/usr/share/keyrings echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/amd64 stable main' > config/includes.chroot_before_packages/etc/apt/sources.list.d/1password.list curl -sS https://downloads.1password.com/linux/debian/debsig/1password.pol > config/includes.chroot_before_packages/etc/debsig/policies/AC2D62742012EA22/1password.pol curl -sS https://downloads.1password.com/linux/keys/1password.asc | gpg --dearmor --output config/includes.chroot_before_packages/usr/share/keyrings/1password-archive-keyring.gpg echo "1password" > config/package-lists/1password.list.chroot --- While preparing this mail, I had to make a local hack to ensure that live-build would continue (adding 'apt-get update' in chroot_install-packages, but this seems to be a proper way to handle the foreign .deb file Since the 1password.deb file properly registers within the package management system, this ticket becomes a 'works for me'. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062641: live-build Removes User Packages Installed via Hooks
On 04/02/2024 17:41, Roland Clobus wrote: ... echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/amd64 stable main' > config/includes.chroot_before_packages/etc/apt/sources.list.d/1password.list And I'm certain that there is a more secure way, that ensures that only the package called '1password' will come from this repository. The bug report was based on a kali version of live-build, so I assume you know better than me how to do so. Please add such command to the bug report, so I can update the live-manual to address such use case. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian Live Query - user-fullname
Hello Robert, On 04/02/2024 15:18, Robert Spiteri wrote: Thanks Roland. And can I also set the hostname and username in this file please? Since for now I am using the --bootappend-live option and I do not want that since they can be changed on boot. Can you please send me a link to some documentation about it? I never heard about the file config.conf There is some documentation (besides the source code) [1]: https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-run-time-behaviours.en.html#530 You can do the following instead: lb config mkdir -p config/includes.chroot/etc/live/config.conf.d echo "LIVE_USER_FULLNAME=\"This is my custom user fullname\"" > config/includes.chroot/etc/live/config.conf.d/10-user-setup.conf lb build It's a matter of taste where you provide the user fullname: 1) Inside the compressed squashfs -> smallest 2) In the binary image -> configurable when written on USB sticks 3) In the kernel command line -> configurable at every boot Note that whatever you have set in a configuration file, the user can still override it with the kernel command line at boot. A peek at the source file [1] shows you all options that you can configure there. With kind regards, Roland Clobus [1] https://sources.debian.org/src/live-config/11.0.4/frontend/init-config.sh/?hl=6#L6 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian Live Query - user-fullname
Hello Robert, >> On Sun, 4 Feb, 2024, 7:08 pm Robert Spiteri, > <mailto:rspiter...@gmail.com>> wrote: >> How can I set the user's fullname as a boot parameter? On 04/02/2024 14:41, Harshad Joshi wrote: Do not use space in between. Refer hostname rules from live installer help The user-fullname gets it default value in the package 'live-config', in the file /lib/live/init-config.sh If you embed a file in the live image in live/config.conf (or live/config.conf.d/*.conf) it will work as intended. Since you provided the name during 'lb config', I assume that you are not really intending the name to be configurable during boot. Therefore the following snippet will provide your custom user fullname: lb config mkdir -p config/includes.binary/live echo "LIVE_USER_FULLNAME=\"This is my custom user fullname\"" > config/includes.binary/live/config.conf lb build With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Questions about report 22
Reply to the lists (after confirmation that it's OK to do so) On 29/01/2024 23:02, John Gilmore wrote: Hello Roland, Congratulations on the amazing progress that you have made with the reproducibility of the Debian Live images. Thanks! It has been a long road already :-) Two things for me are missing from your update. One may just be improving a simple explanation. Plus I have a question. Roland Clobus wrote: Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * All major desktops built reproducibly for the official Debian live images for bookworm (12.4.0) at any later moment ... ** ... except for KDE When you say, "all major desktops build reproducibly", do you mean that the results are identical to the Debian Live builds that ordinary people are downloading to install Debian? E.g. from: https://www.debian.org/CD/live/ Or do you mean that some unique Debian Live builds that you personally make, but that nobody else downloads, are reproducible when compared with themselves? You can download the images from the official location https://get.debian.org/images/release/current-live/amd64/iso-hybrid/ And then 7 out of 8 are reproducible. (Which leaves KDE at the moment) Steps how to do so are documented in the Wiki page (link 1 on my original mail) https://wiki.debian.org/ReproducibleInstalls/LiveImages If the actual end-user Debian Live builds have become (97.7%) reproducible, then this is much bigger and better news. But you did not make this clear in your update. Statistics are a lie :-) 97.7% of all images that I monitor are reproducible (when certain conditions are met) 87.5% (7 out of 8) of the officially released live images are reproducible when building from a Bookworm VM Second thing: Can these Debian Live images be readily reproduced from their own bootable image plus their matching Source DVD images? Or, does reproducing them require access to some remote server(s) elsewhere on the Internet, which means they won't reproduce if that server is ever down, compromised, or its owners fail? You'll need access to the Debian repository online. The sources for each Debian package are available, but as a source tarball, not as .deb files. As an idea, it would be nice to have a tarball containing all .deb files (and related files), which could function as an offline local repository. The configuration files for running the live-build script (which are generated on the fly by a shell script) are not published, but the shell script is. The gold standard for reproducible builds is that they are reproducible FROM THEIR OWN SOURCE RELEASE. If your scripts test this, then anybody who downloads the full source release plus the matching Debian Live CD image can disconnect their machine from the Internet, install the Live CD image on bare hardware, and then do a full rebuild and re-verify, not depending on anything else in the universe except a bit of electricity. At this moment, you'll need Internet access, pointing to static (at least until the next point release) files. However, I've taken care to do time-travelling in the git repositories containing the scripts, to ensure that you'll be using the same versions of the scripts at the time of the release of the images. If your scripts don't test for this, then the release is not fully reproducible, since it depends on external inputs that are not part of the source release. (For example -- if your rebuild scripts and verification scripts are not actually in the source release and thus have to be downloaded from somewhere!) Then I'll have a third metric: 0% of all live images are reproducible given these conditions Here's the bonus question: Functionality status: * The sid images are affected by #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) * The sid images occasionally report missing installation media, when booting from USB in UEFI non-secure boot systems (#1054325) * The testing images have an issue in the installer, it attempts to use a static IP-address instead of using DHCP. MR is prepared [2] Are you saying that the images that you are building are identical with the public, downloadable Debian Live images -- but the public, downloadable Debian Live images have these three problems? If true, why do you bother noting it? Every release has bugs, if you reproduce the release, the reproduced release will have bugs. I'm cross-posting the reproducible builds mailing list and the live mailing list, since there is a huge overlap. By mentioning my progress for both types of work, I'm saving myself writing 2 mails which would be largely identical. If the problems you report are unique to your reproducible images, then I don't understand ho
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 22th update of the status for reproducible live-build ISO images [1]. Single line summary: 97.7% reproducible live images Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * All major desktops built reproducibly for the official Debian live images for bookworm (12.4.0) at any later moment ... ** ... except for KDE Functionality status: * The sid images are affected by #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) * The sid images occasionally report missing installation media, when booting from USB in UEFI non-secure boot systems (#1054325) * The testing images have an issue in the installer, it attempts to use a static IP-address instead of using DHCP. MR is prepared [2] My activities in January: * Rebuilding all images for 12.4.0. Thanks to apt-cacher-ng, I saved 75GB downloaded files * Only the KDE image for 12.4.0 has a different sha256sum * Updates to openQA tests * Fixes for udeb handling [2], preparing clipboard support when running under a VM [3] * A local script will feed the official weekly live images to openQA * Updated the documentation how the official Debian live images are built [1] Work to be done: * Adjust the content of the live-build image ** Fix the remaining reproducible issue in time before 12.5.0 (planned for February 2024) * Many other things. See the TODO page [4] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/337 [3] https://salsa.debian.org/live-team/live-build/-/merge_requests/334 [4] https://wiki.debian.org/DebianLive/TODO 97.7%: based on 4 versions x 9 variants + 8 variants OpenPGP_signature.asc Description: OpenPGP digital signature
Re: How do I build a official Debian live image?
Hello Arnaud, list, On 25/01/2024 09:28, Arnaud Rebillout wrote: how do I build a official Debian live image? I've updated the instructions on the Wiki page: https://wiki.debian.org/ReproducibleInstalls/LiveImages It now contains all the details for rebuilding the official Bookworm images. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Weekly builds of installer/live images failing
Hello Daniel, On 16/01/2024 09:52, Daniel Lewart wrote: However, on Jan 8 and 15, the weekly builds of installer/live images have been failing. I'll guess that these are part of the fallout from "the big linux changes": https://lists.debian.org/debian-kernel/2023/12/msg00421.html https://salsa.debian.org/kernel-team/linux/-/merge_requests/851 Indeed. The kernel changes and usrmerge issue in the installer have caused build failures for the weekly builds. They appear to have been resolved now, and Jenkins shows that the daily builds for the live images on sid are building (reproducibly) again. The tests in OpenQA also look good. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Irregular status update about reproducible live-build ISO images
On 04/01/2024 14:58, Roland Clobus wrote: Single line summary: Very near the finishing line Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * Rebuilding the official bookworm images (standard and gnome) for 12.4.0 at any later moment ** Only one (new) difference is left: in the official images a directory /run/mount is present, which is not in my local build * The other official bookworm images for 12.4.0 have not been evaluated yet I've rebuilt the standard image with a bookworm host (the 12.4.0 gnome live image): the sha256sum matches for the .iso and the source.tar files. So the officially distributed Debian live standard ISO image is reproducible! I'll check the other ISO images later. The extra directory /run/mount is not present when building from sid. That directory is created on bookworm by debootstrap (which differs between bookworm and sid, and is one of the few external dependencies). With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 21th update of the status for reproducible live-build ISO images [1]. Single line summary: Very near the finishing line The best wishes for 2024, may this year be the year of the reproducible live images for Debian :-) Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * Rebuilding the official bookworm images (standard and gnome) for 12.4.0 at any later moment ** Only one (new) difference is left: in the official images a directory /run/mount is present, which is not in my local build * The other official bookworm images for 12.4.0 have not been evaluated yet Functionality status: * The sid images are affected by #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) * The sid images occasionally report missing installation media, when booting from USB in UEFI non-secure boot systems (#1054325) My activities in November, December: * A workaround in live-build [2] until the fix for the installer [3] is implemented (due to kernel 6.6.8) [4] * An initial step for FST (File System Transposition) [5] * Fix for an undesired authentication prompt for calamares [6] * Proposed fixes for the calamares installer [7] * Minor updates to the openQA tests of the live images Work to be done: * Test the official images and regular snapshot images in openQA as well as the images generated by Jenkins (possibly replacing the images generated by Jenkins) * Review the results of the generated ISO images in my local openQA instance * Adjust the content of the live-build image ** Fix the remaining reproducible issue in time before 12.5.0 (planned for February 2024) * Many other things. See the TODO page [8] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/331 https://salsa.debian.org/live-team/live-build/-/merge_requests/332 https://salsa.debian.org/live-team/live-build/-/merge_requests/333 [3] https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/43 [4] https://lists.debian.org/debian-boot/2023/12/msg00095.html [5] https://salsa.debian.org/live-team/live-build/-/merge_requests/327 [6] https://salsa.debian.org/live-team/live-build/-/merge_requests/328 [7] https://salsa.debian.org/live-team/calamares-settings-debian/-/merge_requests/3 [8] https://wiki.debian.org/DebianLive/TODO OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059037: debian-live: Unable to boot 12.4.0 gnome
severity 1059037 normal tags 1059037 +needinfo thanks Hello Janusz Bień, On 19/12/2023 17:15, Janusz Bień wrote: Trying to boot Debian Live 12.4.0 amd 64 Gnome I get the black screen with a large cursor. With the little information I have, I only can point you in a general direction. You have several options available: 1. Have you tried the second boot option (Live System (amd64 fail-safe mode))? Are you then able to boot into the desktop? 2. You can start the installer (Start installer) and go to a prompt by cancelling on the first screen of the installer 3. You can enter rescue mode (Advanced install options ... | Graphical installer ... | Rescue mode) Please report back if any option works (or fails to work) 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#1053457: live-build: Building live image fails when unmounting /sys: 'target is busy'
Hello Witold Baryluk, On 05/12/2023 16:35, Witold Baryluk wrote: Also had this issue for some time (maybe 2-3 months) on my amd64 machine. But I am not so sure it is due to efivars, at least not only. > ... so I made another workaround - try to unmount efivars, then try to unmount sys in > a loop with a bit of sleep, until it finally succeeds. I'm running live-build for some time now on a UEFI-booted machine (previously I used BIOS boot) without issues. I think that the fix is applied to the git version, see https://salsa.debian.org/live-team/live-build/-/merge_requests/326 The fix does a proper unmount of efivars before unmounting sys. Can you try to run live-build from the git version to see whether that fixes the issue for you? I've written some instructions on https://wiki.debian.org/ReproducibleInstalls/LiveImages The key to running the git version is in the definition of the environment variable LIVE_BUILD which should point to the root of the git clone. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Does reporting bugs from inside the live CD work? -> not without additional configuration
Hello Attilla, On 26/11/2023 07:54, dub...@grey-panther.net wrote: I was directed to this list after my post on debian-users [1]. I would like to report two issues with the Debian LiveCD (specifically the debian-live-12.2.0-amd64-gnome.iso one): [ snip question 1, answered in another thread ] 2) reporting a bug from inside the live environment using the reportbugscript with the cdimage.debian.org <http://cdimage.debian.org> meta-package, as described at https://www.debian.org/Bugs/Reporting <https://www.debian.org/Bugs/Reporting> doesn't seem to work. The script said something about the email being sent from "localhost" (since this is a LiveCD, email accounts are not properly set up). I suspect that the email never went anywhere (even though there were no reported errors), because now it has been over a week and the bug still doesn't show up in the bugtracker. I tried to reproduce you case. I'm using debian-live-12.2.0-amd64-gnome.iso and in that image there is no reportbug installed. Where did the reportbug package come from? I've installed reportbug (apt-get install reportbug) and tried to send a bug (see transcript.txt). There were some red flags at the beginning, which indicate that the bug might not be sent properly (silly e-mail address of the user) At the end, reportbug did not show errors from sendmail, but in /var/mail/user it can be seen that the issue is not sent. Reportbug specifically requested a configuration and additional sendmail does not per default send mails outside its (on live CDs) unconfigured domain. So the short answer is: no, you cannot report a bug from inside the live CD without additional configuration work. With kind regards, Roland Clobus [1] https://lists.debian.org/debian-user/2023/11/msg00733.html <https://lists.debian.org/debian-user/2023/11/msg00733.html> From user@localhost.localdomain Sun Nov 26 11:56:12 2023 Return-path: Envelope-to: user@localhost.localdomain Delivery-date: Sun, 26 Nov 2023 11:56:12 + Received: from user by debian with local (Exim 4.96) (envelope-from ) id 1r7DkC-000181-0b; Sun, 26 Nov 2023 11:56:12 + Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Debian Live user To: Debian Bug Tracking System Subject: live-build: Roland Clobus is testing whether the default configuration of reportbug sends mails properly Message-ID: <170099977190.4258.6655128460165924245.reportbug@localhost> X-Mailer: reportbug 12.0.0 Date: Sun, 26 Nov 2023 11:56:11 + Package: live-build Version: Testing reportbug not sending anything Severity: wishlist Roland Clobus is testing reportbug from within a GNOME live image From MAILER-DAEMON Sun Nov 26 11:56:12 2023 Return-path: <> Envelope-to: user@localhost.localdomain Delivery-date: Sun, 26 Nov 2023 11:56:12 + Received: from Debian-exim by debian with local (Exim 4.96) id 1r7DkC-000185-0x for user@localhost.localdomain; Sun, 26 Nov 2023 11:56:12 + X-Failed-Recipients: sub...@bugs.debian.org Auto-Submitted: auto-replied From: Mail Delivery System To: user@localhost.localdomain References: <170099977190.4258.6655128460165924245.reportbug@localhost> Content-Type: multipart/report; report-type=delivery-status; boundary=1700999772-eximdsn-1952859697 MIME-Version: 1.0 Subject: Mail delivery failed: returning message to sender Message-Id: Date: Sun, 26 Nov 2023 11:56:12 + --1700999772-eximdsn-1952859697 Content-type: text/plain; charset=us-ascii This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: sub...@bugs.debian.org Mailing to remote domains not supported --1700999772-eximdsn-1952859697 Content-type: message/delivery-status Reporting-MTA: dns; debian Action: failed Final-Recipient: rfc822;sub...@bugs.debian.org Status: 5.0.0 --1700999772-eximdsn-1952859697 Content-type: message/rfc822 Return-path: Received: from user by debian with local (Exim 4.96) (envelope-from ) id 1r7DkC-000181-0b; Sun, 26 Nov 2023 11:56:12 + Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Debian Live user To: Debian Bug Tracking System Subject: live-build: Roland Clobus is testing whether the default configuration of reportbug sends mails properly Message-ID: <170099977190.4258.6655128460165924245.reportbug@localhost> X-Mailer: reportbug 12.0.0 Date: Sun, 26 Nov 2023 11:56:11 +0000 Package: live-build Version: Testing reportbug not sending anything Severity: wishlist Roland Clobus is testing reportbug from within a GNOME live image --1700999772-eximdsn-1952859697-- user@debian:~$ reportbug live-build Warning: no reportbug configuration found. P
Re: Password required for Calamares installer -> request for backport (Was: Does reporting bugs from inside the live CD work?)
Hello Attilla, live-config maintainers,
On 26/11/2023 07:54, dub...@grey-panther.net wrote:
I was directed to this list after my post on debian-users [1]. I would
like to report two issues with the Debian LiveCD (specifically the
debian-live-12.2.0-amd64-gnome.iso one):
1) if one starts the installer from the live environment, one is asked
for a password, that is (as far as I can tell) not documented anywhere
inside the CD:
https://kdrive.infomaniak.com/app/share/545250/a4c87792-3ed2-4a70-bc1c-ae629842f9cb/preview/image/876245 <https://kdrive.infomaniak.com/app/share/545250/a4c87792-3ed2-4a70-bc1c-ae629842f9cb/preview/image/876245>
This issue has been fixed in live-config 11.0.4. The version in stable
is 11.0.3-nmu1, which does not have this fix yet. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037295
I've extracted the difference between 11.0.3+nmu1 and 11.0.4 with the
.dsc files and dget, attached is the diff file. It contains this
specific fix in components/1080-policykit and some administrative
changes in debian/control.
@live-config maintainers: Could live-config 11.0.4 be backported to
stable (Bookworm) or should I prepare a patch for the live-build
configuration? If we can manage before the 9th December, the fix can be
present in the next liveCD for 12.3.
[snip issue 2, to be answered in a separate mail]
With kind regards,
Roland Clobus
[1] https://lists.debian.org/debian-user/2023/11/msg00733.html
<https://lists.debian.org/debian-user/2023/11/msg00733.html>
diff -r -u live-config-11.0.3+nmu1/components/1080-policykit live-config-11.0.4/components/1080-policykit
--- live-config-11.0.3+nmu1/components/1080-policykit 2021-06-28 11:40:26.0 +0200
+++ live-config-11.0.4/components/1080-policykit 2023-07-10 20:40:01.0 +0200
@@ -3,7 +3,7 @@
. /lib/live/config.sh
## live-config(7) - System Configuration Components
-## Copyright (C) 2016-2020 The Debian Live team
+## Copyright (C) 2016-2023 The Debian Live team
## Copyright (C) 2006-2015 Daniel Baumann
##
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
@@ -40,7 +40,8 @@
esac
# Checking if package is installed
- if ! pkg_is_installed "policykit-1" || \
+ if (! pkg_is_installed "polkitd" &&
+ ! pkg_is_installed "policykit-1") || \
component_was_executed "policykit"
then
exit 0
@@ -51,53 +52,34 @@
Config ()
{
- # Grant administrative PolicyKit pivilieges to default user
-
# Configure PolicyKit in live session
- mkdir -p /etc/PolicyKit
-
-cat > /etc/PolicyKit/PolicyKit.conf << EOF
-
-
-http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd";>
-
-
-
-
-
-
-
-EOF
+ mkdir -p /usr/share/polkit-1/rules.d
if [ -n "${LIVE_USERNAME}" ]
then
-
-cat >> /etc/PolicyKit/PolicyKit.conf << EOF
-
-
-
-
+ cat > /usr/share/polkit-1/rules.d/sudo_on_live.rules << EOF
+// Grant the live user access without a prompt
+polkit.addRule(function(action, subject) {
+ if (subject.local &&
+ subject.active &&
+ subject.user === "${LIVE_USERNAME}" &&
+ subject.isInGroup("sudo")) {
+ return polkit.Result.YES;
+ }
+});
EOF
-
- fi
-
-cat >> /etc/PolicyKit/PolicyKit.conf << EOF
-
-
-EOF
-
- mkdir -p /var/lib/polkit-1/localauthority/10-vendor.d
-
-cat > /var/lib/polkit-1/localauthority/10-vendor.d/10-live-cd.pkla << EOF
-# Policy to allow the livecd user to bypass policykit
-[Live CD user permissions]
-Identity=unix-user:${LIVE_USERNAME}
-Action=*
-ResultAny=no
-ResultInactive=no
-ResultActive=yes
+ else
+ cat > /usr/share/polkit-1/rules.d/sudo_on_live.rules << EOF
+// Grant the sudo users access without a prompt
+polkit.addRule(function(action, subject) {
+ if (subject.local &&
+ subject.active &&
+ subject.isInGroup("sudo")) {
+ return polkit.Result.YES;
+ }
+});
EOF
+ fi
# Creating state file
touch /var/lib/live/config/policykit
diff -r -u live-config-11.0.3+nmu1/debian/changelog live-config-11.0.4/debian/changelog
--- live-config-11.0.3+nmu1/debian/changelog 2022-10-15 12:16:02.0 +0200
+++ live-config-11.0.4/debian/changelog 2023-07-10 20:43:26.0 +0200
@@ -1,9 +1,13 @@
-live-config (11.0.3+nmu1) unstable; urgency=medium
+live-config (11.0.4) unstable; urgency=medium
- * Non-maintainer upload.
- * No source change upload to rebuild with debhelper 13.10.
+ [ Jonathan Carter ]
+ * Add changelog entries for Roland's recent changes
- -- Michael Biebl Sat, 15 Oct 2022 12:16:02 +0200
+ [ Roland Clobus]
+ * Update the polkit configuration to polkitd (Closes: #1037295)
+ * Add lintian overrides
+
+ -- Jonathan Carter Mon, 10 Jul 2023 20:43:26 +0200
live-config (11.0.3) unstable; urgency=medium
diff -r -u live-config-11.0.3+nmu1/debian/control live-config-11.0.4/debian/control
--- live-config-11.0.
Bug#1053457: Looks like BIOS vs UEFI boot
Hello Emanuele, On 08/11/2023 22:00, Emanuele Rocca wrote: Yeah 20230502 is the version I'm using too. I can reproduce on all systems I have available, including my amd64 workstation and my arm64 Macbook M1. However, the issue is *not* reproducible on a VM created with debvm-create. One of the differences seem to be efivars support. Are you by any chance running the commands in a VM or more in general on a system without efivars? What's the output of the following? sudo dmesg | grep efivars: You may have found the crucial difference. I'm running on a sid system which is booted via BIOS, not via UEFI. So I don't have efivars mounted on the host system, and therefore there are no attempts inside the chroot to mount or unmount efivarsfs. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053457: More info needed, cannot reproduce
tags +unreproducible thanks Hello Emanuele, I've seen your (now aborted) merge request, and your additional info in this bug ticket. Sorry for not replying sooner. I've run the commands that you have provided, and am unable to reproduce your case. lb config --distribution sid --updates false --archive-areas 'main non-free-firmware' --bootloaders grub-efi echo live-task-lxde > config/package-lists/desktop.list.chroot lb build --debug My last line in the output is: P: Build completed successfully I'm running (lb --version) 20230502 on sid, all commands have run as root. 1) Can you provide more information about the system that you are using to build the image on? 2) Could you also try to run the latest git version (see [1]) With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages OpenPGP_signature.asc Description: OpenPGP digital signature
Re: FixMeStick failed
Hello list, I've sent the following from https://support.fixmestick.com/hc/en-us/requests/new --- Hello FixMeStick support, I am one of the maintainers of the package 'live-boot'. Today we received on our mailing list a request for support, because the user was redirected to 'live-boot' or the Debian Live Mailing list. I am happy to see that you can provide a commercial product with these Open Source components that we develop and maintain, however we cannot provide any tech support, because we do not know exactly what is on the FixMeStick. I'm open for collaboration, please send your reply to the mailing list: debian-live@lists.debian.org With kind regards, Roland Clobus User request: https://lists.debian.org/debian-live/2023/11/msg4.html --- Hello Ruben, Please log your support request on the link above. With kind regards, Roland Clobus On 08/11/2023 13:28, Ruben wrote: My laptop was acting up so I ran the FixMe stick [snip] Please advise me how to proceed. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054325: occasional bootfailures seen on openQA: bootwalk 4:1:2, 4:2:3 and 4:3:2 on UEFI secure boot
Package: live-build Version: 1:20230502 Severity: normal Tags: d-i X-Debbugs-Cc: p...@hands.com Reporting to live-build, but it probably needs to be handled somewhere else. Occasionally (but rather quite often) the bootwalk test on openQA fails when booting with UEFI secure boot. Especially 4:1:2 and 4:3:2 fail with the message from d-i: 'Your installation medium couldn't be mounted.' A screenshot often shows an empty black rectangle in grub, indicating that some messages should have been displayed, but openQA wasn't able to capture them. Perhaps a frame-by-frame analysis will show the messages. Samples for GNOME: https://openqa.debian.net/tests/197956#step/bootwalk_4:1:2/5 https://openqa.debian.net/tests/197167#step/bootwalk_4:1:2/5 https://openqa.debian.net/tests/196208#step/bootwalk_4:1:2/5 Samples for XFCE: https://openqa.debian.net/tests/198287#step/bootwalk_4:1:2/5 https://openqa.debian.net/tests/197821#step/bootwalk_4:1:2/5 https://openqa.debian.net/tests/194285#step/bootwalk_4:1:2/5 https://openqa.debian.net/tests/193637#step/bootwalk_4:3:2/5 A case for 4:2:3: The video from https://openqa.debian.net/tests/198206#step/bootwalk_4:2:3/6 shows a efi_printk message: EFI stub: ERROR: Failed to load initrd: 0x8001 EFI stub: ERROR: efi_main() failed! The number corresponds to EFI_LOAD_ERROR https://sources.debian.org/src/linux/6.5.6-1/include/linux/efi.h/?hl=32#L32 Enhancing UEFI logging (with kernel option `efi=debug` might help, but the current openQA test isn't written with optional kernel options in might. With kind regards, Roland Clobus PS: The other system information is from my regular PC, and not applicable to this bug report. -- Package-specific info: -- 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-2-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 Versions of packages live-build depends on: ii debootstrap 1.0.132 Versions of packages live-build recommends: ii apt-utils 2.7.6 ii bzip2 1.0.8-5+b1 ii cpio2.13+dfsg-7.1 ii cryptsetup 2:2.6.1-5 ii file1:5.45-2 ii live-boot-doc 1:20230131 ii live-config-doc 11.0.4 ii live-manual-html [live-manual] 2:20151217.2 ii live-manual-pdf [live-manual] 2:20151217.2 ii rsync 3.2.7-1 ii systemd-container 254.5-1 ii wget1.21.4-1+b1 ii xz-utils5.4.4-0.1 Versions of packages live-build suggests: ii e2fsprogs 1.47.0-2+b1 ii mtd-utils 1:2.1.6-1 ii parted 3.6-3 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/live/build/functions/firmwarelists.sh (from live-build package)
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 20th update of the status for reproducible live-build ISO images [1]. Single line summary: I'm nearly there [2] Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * Rebuilding the official bookworm images (standard and gnome) for 12.2.0 at any later moment ** Only 1 timestamp causes differences in the ISO images ** The source tarball has a random order, but identical content ** A downgrade of debootstrap to 1.0.128+nmu2 on the host is required * The other official bookworm images for 12.2.0 have not been evaluated yet Functionality status: * The sid images are affected by #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) * The sid images occasionally report missing installation media, when booting from USB in UEFI non-secure boot systems * The LXQT sid image needs some adjustments in openQA Transient building issue: * sid is waiting for the nmu of libalien-wxwidgets-perl ** Currently the dependency-chain cannot be resolved in sid ** But sid isn't called unstable for no reason... My activities in September, October: * libarchive outputs the same order as isoinfo [3] * The manual for jenkins.d.n was updated for openQA [4] * live-build: Removed cached files from appstream [5] * Minor updates to the openQA tests of the live images * Preliminary (local) tests to make the live images support FST (File System Transposition), prompted by [6] ** This will make any USB stick bootable on UEFI systems when the files of the live image are copied, eliminating the need for dd * Some (local) experiments to make the available languages in the live images more visible [7] Work to be done: * Test the official images and regular snapshot images in openQA as well as the images generated by Jenkins (possibly replacing the images generated by Jenkins) * Review the results of the generated ISO images in my local openQA instance * Adjust the content of the live-build image ** Fix the few remaining reproducible issues in time before 12.3.0 (planned for early December 2023) * Many other things. Moved to the TODO page [10] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] I once wrote that the images are reproducible, but then I tried the long-term reproducibility... [3] https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/350 [4] https://salsa.debian.org/rclobus-guest/jenkins.debian.net/-/commit/8aea639adbeee94c5099c602569109284203f985 [5] https://salsa.debian.org/live-team/live-build/-/commit/d70a84f2e9f6808ca24a52cee1ec62898de98db0 [6] https://salsa.debian.org/live-team/live-build/-/merge_requests/323 [7] https://lists.debian.org/debian-live/2023/09/msg00014.html [8] https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=live-build [9] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=debian-live [10] https://wiki.debian.org/DebianLive/TODO OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Volunteers requested (Was: When will the Debian 12 32-bit Live ISO arrive?)
On 27/09/2023 11:26, Alessandro Magnaterra wrote: ok but then why just today did the Linux Mint team publish the 32-bit LMDE 6 ISO images using Debian 12? ... and I don't think they are the only ones who have released 32-bit ISOs based on Debian 12 I looked at https://linuxmint.com/download_all.php and found for the 21.2 version 3 editions, all 64-bit only (and based on Ubuntu, not directly on Debian) For the Debian LMDE version (https://linuxmint.com/edition.php?id=297) they only support the Cinnamon desktop for 64-bit and 32-bit. From the Mint perspective, I guess that the QA effort is manageable, given that they only have 2 versions for the LMDE variant. In Debian we would have 2x8=16 ISO images that need to monitored by QA. As I mentioned before: I have nothing against the the 32-bit editions of the live image, and they can (as far as I am concerned) be reinstated, provided we have a suitable QA in place. That QA will/can not be done by me, as I don't have sufficient time and suitable hardware, so volunteers are welcome. And unfortunately, just using qemu for QA (e.g. as done in openQA) isn't sufficient, as the release team will be able to confirm. The release team is doing a great job on release day, but verifying all images takes a lot of time. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Enabling arm64 live image builds
Hello Emanuele, On 25/09/2023 16:19, Emanuele Rocca wrote: On 2023-09-25 12:58, Steve McIntyre wrote: However, do we expect the image to be usable on any real machines as-is? Ah yes, reality. :-) I've tested a live image on my RPi 3 B+ with Tianocore firmware and it works well (lxde, gnome takes too long to start and I suspect 1G of total memory is really not enough for it these days!) Currently I'm trying to get the right combo of modules in the initrd to get it booting on the X13s as well. Please also take a look at the work by Thore Sommer in [1]. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/294 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: When will the Debian 12 32-bit Live ISO arrive?
Hello Alessandro, On 25/09/2023 17:04, Alessandro Magnaterra wrote: In https://cdimage.debian.org/debian-cd/current-live/ only amd64 and source but not i386? Is there a release date for i386 ISO image live? See https://lists.debian.org/debian-live/2023/08/msg00037.html i386 support is not explicitly removed from the code, but it is not tested. Keeping up with 9 images for amd64 alone is a big enough maintenance task, unless you volunteer to monitor all i386 images 🙂 Then you will be able to determine the release date. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Live-build manual pages on the wiki are down.
Hello Paul, On 24/09/2023 05:28, Paul Wise wrote: On Sat, 2023-09-23 at 11:08 -0500, James Bielefeldt wrote: I wrote, but I am not sure its on the wiki. Here is the address. https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html That isn't on the wiki, please contact the Salsa admins: https://wiki.debian.org/Salsa The basis for that link is on the Wiki page https://wiki.debian.org/DebianLive Development Documentation points to the page where a language selection can be made. I see no need for modifications at this moment. I don't know what was down, both links work properly for me. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Language and keyboard selection
Hello Narcis, I've done a few experiments now, based on the Bookworm GNOME image. * In the bookworm images, the boot menu options are not present, because the live images are generated with a different tool, which generates the boot menu differently * Such boot menu could be added again, but (as mentioned in other mails) the keyboard selection should be added as well, which is not trivial (that's why it wasn't prevent in the buster live images) * I've done an experiment with 'locales-all'. This shows many languages in the GNOME welcome screen, however the language after the welcome screen closes is still English (I've tried French with azerty keyboard) and the French keyboard is the second keyboard in the list * If I manually add two options in the boot menu, as listed in [1] (locales=fr_FR.UTF-8 keyboard-layouts=fr), I get a correct configuration with language and keyboard setting * If additionally 'locales-all' is available, and in the welcome screen I select English + US keyboard, the language stays French, and the US keyboard layout is added as a second keyboard layout * In GNOME settings, a logout+relogin is required for the updated language to become activated (which isn't triggered by the welcome screen) * Note: the welcome screen is only shown in the GNOME live image So in summary the current state is: * Language and keyboard selection can still be made, but require manual changes in the boot menu. The GNOME welcome screen will ask 2 superfluous questions -> not very user-friendly * The language selection can be added again in the boot menu, but without keyboard selection -> better, but still not good enough * The language selection in the GNOME welcome screen consists of one entry, even though many languages are available -> looks silly * If 'locales-all' is added, the language and keyboard selection can be made in the GNOME welcome screen, but it requires a logout + login before it is active. I have not measured the required increase in size -> not very intuitive I would prefer to have some mirroring of the questions in the debian-installer (in the boot menu), but that requires some non-trivial work. With kind regards, Roland Clobus [1] https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-run-time-behaviours.en.html#539 On 22/06/2023 10:36, Narcis Garcia wrote: Thank you Roland; I report now a comparison: I've tested: debian-live-11.7.0-amd64-gnome 1. At boot menu y choose: Localisation support -> Spanish 2. This causes "welcome screen" to be fully in spanish and be able to select Español. 3. [Next] at Welcome screen: I can select spanish keyboard (and I can select in a large list anyway) <- bookworm too 4. Help pages (automatically launched) appear in spanish. 5. Gnome GUI appears in spanish 6. LibreOffice & M.Firefox localize documents language to spanish 7. At Gnome's Settings I can go to Region&Language to change (again) keyboard layout to any other, and REMOVE english-US. <- bookworm too * Can't switch language (neither english too) from Gnome's Settings. What if I test Bullseye in a minor language? Tried in Catalan: - Welcome screen: Translated to catalan - English keyboard: Removable at Gnome's settings too. - Shell and Applications: Localized Bullseye's Live build (gnome-amd64) results in a 3,552 MiB ISO image Bookworm's Live build (gnome-amd64) results in a 3,401 MiB ISO image I think there is room to restore localisation support, either to boot menu and/or to Gnome's welcome wizard. El 21/6/23 a les 22:46, Roland Clobus ha escrit: Hello Narcis, On 15/06/2023 10:15, Narcis Garcia wrote: Hello, Gnome variant of Debian 12 Live does not allow to change localization/language through GUI tools. It seems to be English (US) as the only language in the world. The Debian live images are prepared for many languages, but there is no automated test that tests for them, therefore this scenario was not evaluated. > Even boot begins GUI with a wizard, which first page is to select which > language is preferred by user: English (US) is the only option of this > nonsense dialog. > "So huge" is the list, that it offers a search box. If you want, you could report a bug against the gnome package for the welcome screen (I haven't looked up the name). Adding more languages more visibly, is on the to-do list. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051527: live-config: Disable unattended-upgrades when running without persistence
Package: live-config Version: 11.0.4 Severity: wishlist Note to self: When running an older live image without persistence (e.g. sid), the unattended upgrades package will: 1) consume network bandwidth by downloading updated packages 2) consume memory due to the overlay filesystem 3) disrupt openQA tests due to a longer startup time and a popup about packages that can be updated The downloaded packages will be discarded when the machine is shut down, so overall this is a waste of resources that can be avoided. Example: a GNOME image for Sid from 2023-09-06T08:10:14Z needs 632MB in /run/live/overlay after booting and downloading updated packages. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-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 Versions of packages live-config depends on: pn live-config-systemd | live-config-backend Versions of packages live-config recommends: ii iproute26.4.0-1 ii keyboard-configuration 1.222 ii live-config-doc 11.0.4 pn live-tools ii locales 2.37-7 ii locales-all 2.37-7 ii sudo1.9.14p2-1 pn user-setup Versions of packages live-config suggests: ii pciutils 1:3.10.0-2 ii wget 1.21.3-1+b2
Re: Debian Live Build - kernel panic ([ .1.544318]initramfs unpacking failed) If Ram Is Less Than 1GB
Hello Sakkra Billa, On 21/08/2023 16:59, Sakkra Billa wrote: I have made a custom debian iso for old hardware (including both 32 Bit and 64-bit versions). Due to the latest Debian release I decided to port it to Debian 12 Bookworm rather than Bullseye. I have been using live_build for compiling the iso, it worked perfectly for bullseye but for debian 12 it causes kernel panic if i assign ram less than 1gb. The distro on its own does not take more than 200mb of ram, I even tried making a netinst iso using live_build but still the same issue. After installation(using more than 1gb of ram) i can reduce ram allocation upto 512mb with no issues but the installer doesn't work with less than 1gb of ram. The following are my lb config settings: lb config -d bookworm --debian-installer live --debian-installer-distribution bookworm --debian-installer-gui false --archive-areas "main contrib non-free non-free-firmware" --debootstrap-options "--variant=minbase" Please guide me if I am doing something wrong. I've tried your 'lb config' line, and am able to create an ISO that can be booted in BIOS and UEFI secure boot mode with 768MB memory allocated. I'm booting into the live environment without issues. I also tried the installer in BIOS mode, and (after reporting that it enters low-memory mode) it was able to run until the partition step, then I aborted the installer. I'm therefore not able to reproduce your case. With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Secure Boot with UEFI live-build
+List On 30/08/2023 09:44, Jeremy DREZET wrote: Okay thanks a lot for your answer So in addition to my question about option parameters it was more about when you basically use "lb config" command line, what are the option(s) to add here in order to set our live image in UEFI mode and consequently make Secure Boot activable ? The default options to 'lb config' are sufficient. Some options, which are already enabling UEFI and secure boot by default: * --bootloaders grub-efi * --uefi-secure-boot auto With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Secure Boot with UEFI live-build
Hello Jérémy, On 29/08/2023 10:36, Jeremy DREZET wrote: I have a question about what is in the title, how can we add secure boot to our live system build with live-build ? And activate it by default (without using commands on the system after creating and launching it) ? The Debian live images all work without additional parameters when booting with secure boot, as shown in openQA [1]. However, you cannot enforce from the boot medium that secure boot is to be used, that is configured on the computer itself. With kind regards, Roland Clobus [1] https://openqa.debian.net/group_overview/14 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Will live-build be able to build Trixie i386 images?
On 28/08/2023 07:22, John Crawley wrote: I have read that i386 Debian installer images will cease to be available from Debian 13 (Trixie): ... Does this mean that it will still be possible to build Trixie i386 images with live-build? i386 support is not explicitly removed from the code, but it is not tested. Keeping up with 9 images for amd64 alone is a big enough maintenance task, unless you volunteer to monitor all i386 images :-) With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 19th update of the status for reproducible live-build ISO images [1]. Single line summary: Live images are looking good Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ** When built for a second time within the same DAK run * Rebuilding bookworm images, see [2] ** When rebuilding at any later timestamp Functionality status: * The trixie and sid images are affected by #1031183 My activities in July, August: * The .disk/info file is now more similar to the 11.x series [5] * The amount of firmware files is reduced [7] * Rebuilding the bookworm standard image [2] ** The following changes were made in live-build: *** The sorting order for the checksum files is consistent *** The file .disk/archive_trace is removed *** The timestamp of boot/grub/live-theme/theme.txt is consistent *** The timestamps in the source tar are the 'now' of the generation of the image ** For the Debian 12.2 point release, full long-term reproducibility should be possible * Rebuilding the bookworm gnome image [2] ** More investigation is required * While rebuilding the bookworm images, the following was seen: ** In the ISO-image hard-linked files (same i-node) may swap their order (seen in diffoscope file list) ** /lib32 and /libx32 symlinks have disappeared ** It appears that updated tools from the host influence the content of the images ** More investigation is required * Bug triaging, resulting in many closed bug reports against live-build [3] * Updated the TODO page [6] * Updated the live-build instructions [1] Work to be done: * More investigation is required to provide long-term reproducibility, because the live image will be generated without using a snapshot server * Test the official images and regular snapshot images in openQA as well as the images generated by Jenkins (possibly replacing the images generated by Jenkins) * Review the results of the generated ISO images in my local openQA instance * Adjust the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en ** All locales are present in the live image, but they are not activated, which results in a silly GNOME welcome screen [4] * Bug triaging for issues reported against live-build [3] and debian-live [8] * Many other things. See the TODO page [6] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://lists.debian.org/debian-live/2023/08/msg8.html [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=live-build [4] https://lists.debian.org/debian-live/2023/06/msg00017.html [5] https://lists.debian.org/debian-live/2023/06/msg00023.html [6] https://wiki.debian.org/DebianLive/TODO [7] https://salsa.debian.org/live-team/live-build/-/commit/8eaf20daf1cf79669975b1acfe4d6fa453eb6307 [8] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=debian-live OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#979151: Need more info, I cannot reproduce
Control: tags 979151 +moreinfo
Hello Sergio,
Even though it is a long time ago, I took another look at this bug report.
In the code of installer_debian-installer, I found 2 URLs that are used
for the installer:
URL="${LB_PARENT_MIRROR_DEBIAN_INSTALLER}/dists/${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION}/main/installer-${LB_ARCHITECTURE}/current/images"
Download_file Packages.gz
"${LB_PARENT_MIRROR_CHROOT}"/dists/"${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION}"/main/debian-installer/binary-"${LB_ARCHITECTURE}"/Packages.gz
I've seen that bookworm-backports also only provides Packages.xz,
similar to buster-backports from the original bug report, so I guess the
issue is still relevant.
However in bookworm-backports, there is not main/installer-amd64, which
will fail the installer script before the .xz-compressed file is
attempted to be downloaded.
I tried with:
lb config --distribution bookworm --debian-installer-distribution
bookworm-backports --debian-installer live
Do you have a full configuration available? I'm currently unable to
reproduce the issue.
With kind regards,
Roland Clobus
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#992916: Works for me
Control: tags 992916 +wontfix More than a year ago (2022-02-10) I wrote in the MR that is associated with this bug report [1]: In this case, the issue might be resolved by using --variant=minbase as well: With lb config --debootstrap-options "--variant=minbase --include sysvinit-core" --initsystem sysvinit followed by echo "user-setup sudo ifupdown isc-dhcp-client" > config/package-lists/recommends.list.chroot one can obtain an image without packages that have systemd in their name (except for libsystemd0, which is pulled in by apt) So there might be no need to change the live-build code. So I consider this bug report handled. Even though not trivial, it is possible to create a live image without systemd code. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/257 OpenPGP_signature.asc Description: OpenPGP digital signature
Rebuilding the official Debian live images -> nearly reproducible
Hello all, I've previously reported that the official Debian live images are reproducible, with the remark that such statement is only valid within the same DAK run (i.e. within the same 6 hour time slot). Now I've started to investigate whether long-term reproducible images are possible too. Because the bookworm section is frozen until the next point release, I can avoid using snapshot.debian.org and work directly on deb.debian.org. So far I've looked at the standard image and recently started looking at the gnome image. I've using the same command line as in live-setup [1] and encounter a few differences in the generated files... Symptoms: 1) The sorting order inside the checksum files (md5sum.txt and sha256sum.txt) is different 2) The file .disk/archive_trace contains a different timestamp 3) The timestamp of boot/grub/live-theme/theme.txt is different, but the content is the same 4) The timestamps in the source tar are the 'now' of the generation of the image 5) In the GNOME image, the live/filesystem.squashfs contains a difference in /var/cache/swcatalog/cache/C-local-metainfo.xb Diagnosis: 1) On my test computer I have a locale set, adding LC_ALL=C before the invocation of the rebuild script fixes the leak from the host to the build environment 2) The archive trace is the timestamp of the last DAK run, for the whole Debian repository and will always be newer than the moment the live images were generated 3) When using the rebuild script, this file is copied from the git checkout. live-setup uses caching of the previous checkout and if there are no changes to this file, the timestamp of this file stays identical to the cached timestamp, which is older than SOURCE_DATE_EPOCH and will be used unchanged in the image 4) For the source image, up till now, there has been no focus on reproducibility 5) fonts-nanum and net.thunderbird.Thunderbird have swapped their order. The file C-local-metainfo.xb is probably generated by 'appstream refresh-cache --force'. I'll look into this later Remedy: 1) Ensure LC_ALL=C for all sort commands on the host, fixed by [2] 2) Proposal: stop copying archive_trace into the image. The information that is required for rebuilding the image is already found in .disk/generator, .disk/info and .disk/mkisofs 3) Proposal: treat theme.txt as a configuration file (all other configuration files in the bootloader directory are touched) 4) This is now fixed by [3], which clamps to SOURCE_DATE_EPOCH for new files and directories I've confirmed that the remedies 1 and 4 work as intended by setting LIVE_BUILD before invoking rebuild.sh, which results in two expected differences: the isoinfo 'Data preparer id' field and the .disk/mkisofs file refer to the current live-build version. With kind regards, Roland Clobus -- [1] /home/roland/git.nobackup/live-build/test/rebuild.sh --configuration standard --debian-version bookworm --debian-version-number 12.1.0 --timestamp archive --installer-origin archive --disk-info "Official Debian GNU/Linux Live 12.1.0 standard" --generate-source [2] https://salsa.debian.org/live-team/live-build/-/commit/f38a906715d68d88d14aa670231163f7923a33f1 [3] https://salsa.debian.org/live-team/live-build/-/commit/d6e7b80ea0f260a21434269ae63519467e4cff6b OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1043133: Patch which fixes the bug for me -> real fix already exists in git
Hello Chris, On 06/08/2023 17:19, Chris Ward wrote: The following fixes the bug for me. It may need adjusting so that it can work both for debian 12.0 and previous, and for debian 12.11 where 'firmware-linux' is no longer a separate item. The patch to binary_rootfs fixes a bug that I reported previously. My previous reply was blocked by Google, but this one should pass. See my reply [1] for a patch which was already applied in git. Actually 'firmware-linux' still is available [2], but it moved to 'non-free-firmware', which you might want to include in your own images. I'll take a look at the 'ext4' issue (#1032408) soon, let's keep the topic for each bug report separate. In general, building a bookworm image, typically requires either a bookworm+1 basic image, or a fresh git repo. With kind regards, Roland Clobus [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043133#15 [2] https://packages.debian.org/search?keywords=firmware-linux OpenPGP_signature Description: OpenPGP digital signature
Bug#1043133: Candidate fix -> real fix already exists
Hello Chris, On 06/08/2023 15:17, Chris Ward wrote: I revised 2 files along the lines of ... and now I can run the live builds that I want to run I've seen the issue as well and have prepared a fix in git at [1]. This fix has not been released yet. As you wrote in the first mail, you are using Debian 12.1 to build an image. Unfortunately such fixes cannot flow back into Debian stable, so for building Debian 12.1 images you'll have to use the git version of live-build for now. See the instructions at [2]. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/commit/ba34bfbfd0efdd6c036496f960bf4df1f42ba332 [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages Section "Use case: while preparing new hooks, using the local git checkout of `live-build`" -> The environment variable LIVE_BUILD must be correctly set OpenPGP_signature Description: OpenPGP digital signature
Re: .disk/info should contain flavour/version of live image -> done
Hello Andi, On 25/06/2023 21:33, Andreas B. Mundt wrote: On Wed, Jun 21, 2023 at 10:16:44PM +0200, Roland Clobus wrote: On 21/06/2023 20:57, Andreas B. Mundt wrote: with the bookworm live images, the format of the .disk/info file on the iso images has been modified ... Now that my extensions to the image building script [1][2] have been merged, the 12.1 point release will benefit from that after [3] is merged. I've made .disk/info more similar to Debian 10 and 11, which the minor modification that the timestamp also contains the seconds and time zone (UTC). Additionally, there is a file .disk/generator which contains the full command line of the generator script. You can also use the ISO volume label again to determine the flavour. I've taken lxde and lxqt into consideration too and there 'ld' and 'lq' will be used instead of the usual first two letters. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/merge_requests/313 [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/315 [3] https://salsa.debian.org/images-team/live-setup/-/merge_requests/4 OpenPGP_signature Description: OpenPGP digital signature
Re: about debian 12
On 09/07/2023 15:10, Илья Пащук wrote: is released version of live-build ready for building debian 12 images? (I mean version in debian 12 repository) I haven't tried recently, but it should work. Are build trees for official images published somewhere? All official Debian images are here: https://get.debian.org/cdimage/ The live images for Debian 12 are here: https://get.debian.org/cdimage/release/current-live/amd64/iso-hybrid/ With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: about debian 12
On 07/07/2023 19:20, Илья Пащук wrote: I want to ask the following questions: 1) is live-build now ready for building debian 12 images? Yes, it has been building (unofficial) images for Bullseye (11) and Bookworm (12) for a while. However, those builds use the git version of live-build from salsa [1] and not the released version of live-build 2) what about official debian live images? do they use live-build or still live-wrapper? Starting with Bookworm, they use live-build again 3) are non-free-firmware packages are included in the official debian live images? live-build images by default? Yes, the non-free-firmware packages are included per default With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build OpenPGP_signature Description: OpenPGP digital signature
Bug#1027739: More information needed
Control: severity -1 wishlist Control: tags -1 +moreinfo Hello Paola Cala, Your bugreport did not contain much information. What do you need systemd-timesyncd for? Can you elaborate a bit more on the use case? How you tried building your own image with this package included, and does that work for you? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Irregular status update about reproducible live-build ISO images
On 04/07/2023 22:32, Vagrant Cascadian wrote: On 2023-07-04, David A. Wheeler wrote: On Jul 2, 2023, at 11:37 AM, Roland Clobus wrote: Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid How close are things to having the *released* versions of the Debian live images & (main) packages reproducible? I can't tell if this means "it's possible to create reproducible builds" or "the packages people are using are the reproducible builds". Sorry if this is obvious to everyone else. My understanding is the live images themselves are bit-for-bit reproducible, with the inputs being the actual .deb packages from the debian archive. The individual .deb packages might not neccesarily be independently reproducible when built from source. Indeed. The live ISO images are constructed two times within the same DAK run (which synchronises the Debian archive every six hours). The resulting ISO images are verified by Jenkins [1] to be bit-for-bit identical. Even though the individual package might not be reproducible from source, the live images (which use the prebuilt packages) are. Because the images are generated from the current state of the Debian archive, and not from a snapshotted state [2], I have a pending task to see how this can be mapped. With kind regards, Roland Clobus [1] https://jenkins.debian.net/view/live/ [2] https://snapshot.debian.org OpenPGP_signature Description: OpenPGP digital signature
Irregular status update about reproducible live-build ISO images
Hello lists, here is the 18th update of the status for reproducible live-build ISO images [1]. Single line summary: Live images are looking good, and the number of (passed) automated tests is growing Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid My activities in March, April, May, June: * Non-free-firmware is added, the images are reproducible * The live images are generated officially by Debian * Better support for UEFI secure boot in live-build [10] * Stabilising the tests in openQA [6][7][9] * New test in openQA: the Calamares installer [8] * The live images have less authentication prompts (pending) [2] * A little bug triaging Work to be done: * More investigation is required to provide long-term reproducibility, because the live image will be generated without using a snapshot server * Test the official images and regular snapshot images in openQA as well as the images generated by Jenkins (possibly replacing the images generated by Jenkins) * Review the results of the generated ISO images in my local openQA instance * Adjust the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en ** The additional firmware has made the live images much larger ** All locales are present in the live image, but they are not activated, which results in a silly GNOME welcome screen [3] ** The .disk/info file must be made similar to the 11.x series [4] * Bug triaging for issues reported against live-build * Many other things. I'll update the current TODO page [5] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037295 [3] https://lists.debian.org/debian-live/2023/06/msg00017.html [4] https://lists.debian.org/debian-live/2023/06/msg00023.html [5] https://wiki.debian.org/DebianLive/TODO [6] https://salsa.debian.org/live-team/live-build/-/merge_requests/308 [7] https://salsa.debian.org/live-team/live-build/-/merge_requests/309 [8] https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/27 [9] https://salsa.debian.org/live-team/live-build/-/merge_requests/306, https://salsa.debian.org/live-team/live-build/-/merge_requests/305, #1023472 [10] https://salsa.debian.org/live-team/live-build/-/merge_requests/304 OpenPGP_signature Description: OpenPGP digital signature
Bug#1037295: live-config: starting Calamares installer requires a password (which is 'live')
Hello Simon, Jonathan, On 30/06/2023 21:05, Simon McVittie wrote: ... I think it would be better to solve this in live-config rather than in Calamares ... Ah, I see now. I agree, that the fix should not be in the Calamares package, because it would allow users of the sudo group access to Calamares without a prmompt in scenarios that a not live images. I have been considering to add a fix to live-build, but the proper location would indeed be live-config, which ensures that all live-specific tweaks will disappear after installation of the live image. Digging deeper: policykit-1 is a transitional packages for Bookworm, so I guess it will be removed in Trixie. I've found the virtual package 'polkit-1-auth-agent' which shows several packages that would probably need to migrate first (e.g. lxpolkit, ukui-polkit and possibly phosh, gnome-flashback, gnome-shell and lxqt-policykit) Also the script '1080-policykit' in 'live-config' generates a folder '/etc/PolicyKit', which is old-style. Which leaves: * calamares should depend on 'pkexec' (which is explicitly called in the .desktop entry, and pulls in 'polkitd') * No specific tweaking for polkit rules in calamares is required * The script '1080-policykit' in 'live-config' needs to be updated and live-config be re-released -> MR at [1] * For the live images in Bookworm, the 'live-config' packages needs to be updated there as well. * A test shows whether the update is working: - Go to https://openqa.debian.net/group_overview/14 - Select the latest Build_sid_kde image - If 'gnome_live-build-apps_startstop' shows 'kparted' as a failed test, the fix is not working/active With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-config/-/merge_requests/13 OpenPGP_signature Description: OpenPGP digital signature
Bug#1037295: live-config: starting Calamares installer requires a password (which is 'live')
Hello Simon, On 10/06/2023 19:14, Simon McVittie wrote: On Sat, 10 Jun 2023 at 15:10:35 +0100, Simon McVittie wrote: * Boot debian-live-12.0.0-amd64-gnome.iso (the version used for release-day testing) - KDE has a similar issue with slightly different steps to start the installer, probably all desktops' variants are affected GNOME, KDE and LXQT are affected. I've proposed a fix for Calamares in #1025552, which is based on your proposal in this ticket. If it is accepted there, this ticket can be regarded as a duplicate. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Non-sense language selection
Hello Narcis, On 15/06/2023 10:15, Narcis Garcia wrote: Hello, Gnome variant of Debian 12 Live does not allow to change localization/language through GUI tools. It seems to be English (US) as the only language in the world. The Debian live images are prepared for many languages, but there is no automated test that tests for them, therefore this scenario was not evaluated. > Even boot begins GUI with a wizard, which first page is to select which > language is preferred by user: English (US) is the only option of this > nonsense dialog. > "So huge" is the list, that it offers a search box. If you want, you could report a bug against the gnome package for the welcome screen (I haven't looked up the name). Adding more languages more visibly, is on the to-do list. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Debloating Debian Live Images
Hello Naeem, On 18/06/2023 20:07, Naeem Alatassi wrote: I do not know why Debian Live KDE is bloated compared to KDE Neon. The Debian live images are intentionally a very generic-purpose image, and therefore larger than specialised images. Debian KDE: 3.39 GB, KDE Neon: 2.44 GB) You should remove some packages to have more lightweight system: akonadi-server, akregator, fcitx, fcitx5, gimp, imagemagick, imagemagick-6.q16 ibus, libreoffice, uim, xterm, xiterm, mlterm The Debian live images install 'task-kde-desktop', which brings in at least gimp and libreoffice. If you think that KDE ships suitable alternatives, I recommend to create a bug report against 'task-kde-desktop'. Additionally the images are prepared to be very multi-lingual, so there are many language packs installed as well (bringing at least uim, xterm, xiterm, mlterm). (From package 'live-task-kde') And include packages like: vlc, ffmpeg, pipewire-audio There are some vlc-related packages installed, but vlc is indeed missing. Thanks for reporting that, I'll take a look to see why it is missing and/or whether KDE offers a suitable alternative. ffmpeg in indeed not installed, but ffmpegthumbs is. I'm currently unsure whether this would fit the purpose of live images, without needing additional tools like kdenlive, handbrake and similar. pipewire-audio is normally coming via gnome-core or gnome-settings-daemon, so I wonder whether that belongs on a KDE live image. It is pain to remove unneeded packages from system and install what most of people need. When you install the Debian live image to your hard disk, you'll get a copy of everything on that image. If you want to have more control over the installed packages, I guess that the netinst image is more suited for your purpose. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: For persistent encryption bookworm
Hello Paul, On 18/06/2023 23:12, p...@gilbertson.biz wrote: Great job on Debian Bookworm. Just an FYI for people reading the manual. You must add the “cryptsetup-initramfs” package along with “cryptsetup” in your “package-list” or your live distro will not see any encrypted drives. In Bullseye, “cryptsetup-initramfs” was recommended and therefore automatically installed and in Bookworm it isn’t. Thanks for noticing. At the moment the automated test (on openQA [1]) do not contain such scenarios, therefore this use case was missed. Can you provide some more details? Which steps did you follow, when you noticed that 'cryptsetup-initramfs' is missing? With kind regards, Roland Clobus [1] https://openqa.debian.net/group_overview/14 OpenPGP_signature Description: OpenPGP digital signature
Re: .disk/info should contain flavour/version of live image
Hello Andi, list, On 21/06/2023 20:57, Andreas B. Mundt wrote: with the bookworm live images, the format of the .disk/info file on the iso images has been modified, for example: bullseye: # mount -o loop debian-live-11.2.0.amd64-kde+nonfree.iso /mnt $ cat /mnt/.disk/info Official Debian GNU/Linux Live 11.2.0 kde 2021-12-18T13:54 bookworm: # mount -o loop debian-live-12.0.0.amd64-gnome.iso /mnt $ cat /mnt/.disk/info Debian GNU/Linux 12 "Bookworm" - Official Snapshot amd64 LIVE/INSTALL Binary 20230610-08:51 The problem: There is no way to find the image flavour (gnome/kde/standard) of the image from .disk/info, it's identical for all images. That kind of information is available during the build, and is available after building at another location: in `live/filesystem.packages` there is a line with `live-task-kde` for KDE. With bookworm the tool to build the live images was changed from live-wrapper to live-build, hence the change. Do you know whether there is some standard for the .disk folder? I see a few options: 1. It would be very easy to add a new file `.disk/variant` which contains 'gnome', 'kde', 'standard' (for text-only). 2. Changing the content of `.disk/info` globally would affect all Debian-derivatives that are currently using live-build already, and unless they speak up, I would rather not change that. 3. Setting the content only for the official Debian builds would be an option, which needs a new commandline option to lb_build. My personal preference is 3, 1, 2. Perhaps the debian-cd team can chime in as well, especially for option 3, which will change the content for the live images for 12.1 compared to 12.0. Now, di-netboot-assistant uses the information provided in .disk/info to generate live netboot (ipxe/grub) boot menu entries for live images. Are you interpreting the lower case text into something nicer (e.g. Cinnamon, KDE, text-only)? This question is more-or-less a question to see how easy changes can be made on the other side :-) In total, there are 8 images generated for amd64 [1]. With kind regards, Roland Clobus [1] https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/ OpenPGP_signature Description: OpenPGP digital signature
Re: Live ISO Problem with filesystem
Hello, On 27/05/2023 16:13, abraham.wick wrote: I'm using live-build on Debian bullseye and was wondering if I can copy or even include larger files in the live system's overlay fs before it boots, so that they are writable? I don't think I understand what you want to achieve. When you have booted the ISO image, all files that are modified will automatically be put in the overlay layer due to copy-on-write. So all files are potentially writable (when you have the right file permission) My solution: * add the files to includes.chroot That's the correct way to add additional files into the ISO image. Are the file permissions set properly? (write-access for the live-user, i.e. group or other?) * create boot-time hook in /etc/lib/live that copies the files into userspace upon boot This works but takes time. Is there a way I can instantly have files already placed in the overlay fs at boot and thus be writable? (Without persistence) If you copy the file upon boot, for every boot you will have a delay that corresponds to the time the copy command needs. If you didn't copy the file, that time will be needed only when the file is modified. Note that this copy will consume both time and memory. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: 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
Re: Announcement for the weekly live images for Bookworm
Hello Yashraj Moghe, On 06/04/2023 13:30, Yashraj Moghe wrote: > On 4/6/23 16:59, Yashraj Moghe wrote: >> I have been working on a draft for an announcement regarding the live >> images being up and building again... > https://salsa.debian.org/Disaster2life/bits/-/blob/master/content/2023/debian-bookworm-live-images.md Thank you for preparing the announcement. I would suggest a few changes, could you grant me access rights, or should I clone your clone of Publicity/Bits? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#807954: debian-live: setup automated builds of live-manual
Hello Holger, On 17/03/2023 21:17, Holger Wansing wrote: Is there still interest to get the live-manual built on official Debian machines / included on the Debian website? Yes. In this case, I would vote for using the same mechanism as currently used for all the other documents under www.debian.org/doc. Good idea. To get a manual updated on the Debian website, one just needs to upload a new version to unstable, and the rest is done auto-magic-ally :-) Currently the latest and greatest version is automatically generated by Salsa on every git commit. https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html The last release of the package was in 2015... so a new package upload is due. I have prepared (and tested) patches for both; attached. I'll fill in the missing spots soon. With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Re: Growth due to firmware + Boot menu image
Hello Jonathan, On 20/03/2023 18:51, Jonathan Carter wrote: ... For now this /does/ work. But we do end up with 740M of uncompressed firmware on the image, so at the very least I think we should circle back to this for Debian 13. Luckily, the firmware files *are* compressed, in the .deb format and in the .squashfs. The GNOME ISO file grew about 14% (420MB). There are provisions in live-build to exclude some firmware files, if they are already embedded in the d-i images. However, when I tested that before the firmware change, it reduced the size by about 50MB-100MB, which is only a tiny fraction of the 3GB file. BTW, are you planning to change the syslinux config? I notice it still shows the construction cap. The boot menus both for syslinux and grub show the default image (the construction cap). Now that the major hurdles (non-free-firmware and regular builds) have been taken, I can focus on this. With kind regards, Roland OpenPGP_signature Description: OpenPGP digital signature
Re: Source of firmware packages (Was: Starting the weekly live images for Bookworm building again)
Hello Jonathan, On 20/03/2023 12:59, Jonathan Carter wrote: On 2023/03/20 09:11, Roland Clobus wrote: 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. How do you currently install the non-free firmware packages? Depending on the availability of the section 'non-free-firmware', the package 'firmware-linux' pulls in the firmware-related packages. Also the script [2] looks for packages that contain files in the folder '/lib/firmware' and pulls in all those packages as well. FWIW, I've uploaded live-tasks-non-free-firmware that could be used to provide firmware packages for either desktops or servers. Control file here with more details: https://salsa.debian.org/live-team/live-tasks-non-free-firmware/-/blob/main/debian/control I'm filing an unblock for it too, so that it can migrate to testing. Should the live images use those 2 meta-packages instead of the heuristic? With kind regards, Roland [1] https://salsa.debian.org/live-team/live-build/-/commit/50c7e1a8b7b5a966cce0bd432f0c5f02793330a9 [2] https://sources.debian.org/src/live-build/1%3A20230131/functions/firmwarelists.sh/ 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
Monthly status update about reproducible live-build ISO images
Hello lists, here is the 17th update of the status for reproducible live-build ISO images [1]. Single line summary: Work is needed when non-free-firmware is activated. Reproducible status: * All major desktops build reproducibly with bullseye, bookworm and sid for images without firmware support * When non-free-firmware is activated, some non-reproducible files are generated My activities in February: * Not much progress, I've been busy IRL * No new modifications to live-setup, waiting for review * Many of the open MRs from last month have been uploaded * I've started working on non-free-firmware Work to be done: * Live images are not generated officially by Debian yet ** Might need additional changes in 'live-setup' ** Needs communication to coordination the next steps ** This will be the next main target * Update the support for non-free firmware * More investigation is required to provide long-term reproducibility, because the live image will be generated without using a snapshot server * Review the results of the generated ISO images in my local openQA instance * Add a test for the Calamares installer in openQA * Adjust the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en * Bug triaging for issues reported against live-build Unchanged, but low priority due to [5], patch available but not released yet: * texlive-base: Reported differences in the generated ls-R [2] * texlive-binaries: Randomness in .fmt files due to Lua hash seeds [3] * texlive-binaries: updmap creates a logfile with the timestamps of files that it just has generated [4] * Priority is now very low, since the package is not used in live images any more ** This section will be removed from my next report With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003449 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009196 [4] https://salsa.debian.org/live-team/live-build/-/commit/f1a98e4da62c3551f523553c6e23774aaf5e41b4 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006472 OpenPGP_signature Description: OpenPGP digital signature
Bug#1030526: live-build: Fails to build bookworm, due to firmware-linux
Hello Witold Baryluk,
I'll be adapting live-build to the firmware locations soon.
Can you try with:
ARCHIVE_AREAS="main non-free non-free-firmware contrib"
I didn't try your command yet, but I think that I need to know which
packages are mentioned in 'config/packages-lists', to determine which
package is pulling in the firmware packages.
With kind regards,
Roland Clobus
PS: the 'lb config' command does not need to be run as root.
On 04/02/2023 15:13, Witold Baryluk wrote:
Package: live-build
Version: 1:20230131
Severity: important
X-Debbugs-Cc: witold.bary...@gmail.com
This started at least few days ago. Was working find about month ago.
ARCHIVE_AREAS="main non-free contrib"
sudo
--preserve-env=DEBIAN_FRONTEND,APT_LISTCHANGES,NEEDRESTART_MODE,NEEDRESTART_SUSPEND,DEBIAN_FRONT
\
nice lb config \
--color \
--apt-indices false \
--apt-recommends true \
--archive-areas "${ARCHIVE_AREAS}" \
--binary-images iso-hybrid \
--backports false \
--bootloaders syslinux,grub-efi \
--debootstrap-options "--include=ca-certificates" \
--debconf-priority critical \
--debian-installer live \
--debian-installer-gui true \
--distribution "${CODENAME}" \
--security true \
--zsync false \
--bootappend-live "${BOOTAPPEND}" \
--mirror-bootstrap "${MIRROR_URL}" \
--mirror-chroot "${MIRROR_URL}" \
--mirror-chroot-security "${MIRROR_SECURITY_URL}" \
--mirror-binary "${FINAL_MIRROR_URL}" \
--mirror-binary-security "${MIRROR_SECURITY_URL}" \
--mirror-debian-installer "${MIRROR_URL}" \
--memtest "memtest86+" \
--checksums sha256 \
"${COMPRESS_OPTS[@]}" \
--image-name "${LB_IMAGE_NAME}"
In my package list I do not have any firmware packages. It is live-build
that decides to install it. Which is good.
But it fails now:
Package firmware-linux is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'firmware-linux' has no installation candidate
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
I think the reason is that previously firmware-linux was in non-free,
but now it is split into firmware-linux-free and firmware-linux-nonfree?
I tried modifing /usr/lib/live/build/chroot_firmware and
/usr/lib/live/build/installer_debian-installer to use that packages
instead, but build still fails with siomilar message.
0204 13:54:29.677550 Package firmware-linux-nonfree is not available, but is
referred to by another package.
0204 13:54:29.677629 This may mean that the package is missing, has been
obsoleted, or
0204 13:54:29.677661 is only available from another source
0204 13:54:29.677692
0204 13:54:29.680763 E: Package 'firmware-linux-nonfree' has no installation
candidate
0204 13:54:29.684112 E: An unexpected failure occurred, exiting...
0204 13:54:29.684308 P: Begin unmounting filesystems...
Looking at archive, it looks firmware-linux-nonfree and
firmware-misc-nonfree is not present in bookworm/non-free. But looking at
official cd-unofficial-with-firmware, (build using lwr, not live-build),
I do see these packages used during the build and fetch. But last upload
there was about month ago, so maybe it is also failing now.
I looked a bit at changelogs in PTS, and wiki about firmware, but could
not find any solution.
-- Package-specific info:
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.2.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-build depends on:
ii debootstrap 1.0.128+nmu2
Versions of packages live-build recommends:
ii apt-utils 2.5.5
ii bzip2 1.0.8-5+b1
ii cpio2.13+dfsg-7.1
ii cryptsetup 2:2.6.0-2
ii file1:5.44-3
ii live-boot-doc 1:20220505
ii live-config-doc 11.0.3+nmu1
ii live-manual-html [live-manual] 2:20151217.2
ii rsync 3.2.7-1
ii systemd-container 252.5-2
ii wget1.21.3-1+b2
ii xz-utils5.4.1-0.0
Versions of packages live-build suggests:
ii e2fsprogs 1.46.6~rc1-1.1
ii mtd-utils 1:2.1.5-1
ii parted 3.5-3
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/live/build/chroot_firmware
Monthly status update about reproducible live-build ISO images
Hello lists, here is the 16th update of the status for reproducible live-build ISO images [1]. Single line summary: The live images stayed reproducible. Reproducible status: * All major desktops build reproducibly with bullseye, bookworm and sid * Number of patches performed by the live-build script that are not yet in sid: zero! (0) * Due to transitions, the LXQt desktop live image is occasionally not building due to conflicting packages My activities in December and January: * Modifications to live-setup ** Open MR: Images can be generated automatically [11] ** Since no snapshot server will be used, the live images are reproducible only for at most a 6 hour window ** More investigation is required to verify whether 2 timestamps (1 for the files in the image and 1 for the timestamp for accessing the matching snapshot) will be sufficient to provide long-term reproducibility * Bug reports for bugs found with openQA are collected at [12] * Preparation of improvements for the live images ** Open MR: live-installer: A better user experience after the installer is finished [13] ** Open MR: live-build: Various installer improvements, including off-line installation [15] ** Open MR: live-build: Rebuild script improvement for running with live-setup and Jenkins [16] * Preparation of improvements for the Debian installer ** Open MR: localechooser: A minor fix [14] (A country was placed in the 'other' category) * Bug triaging: ** Open MR: Reassigned #1023472 to task-lxqt-desktop: pulls in both kwin & xfwm4 and wrote a patch [18] ** #1017435 got fixed in git and is pending for release [19] ** #1029393 about missing glyps in the installer [20] * I've posted a heavily cross-posted mail, which did not elicit any response [17] ** As you can see above, I currently have a several open MRs pending ** The first stage of the freeze for Bookworm is active, the next one is coming soon Work to be done: * Live images are not generated officially by Debian yet ** Might need additional changes in 'live-setup' ** Needs communication to coordination the next steps ** This will be the next main target * Update the support for non-free firmware * More investigation is required to provide long-term reproducibility, because the live image will be generated without using a snapshot server * Review the results of the generated ISO images in my local openQA instance * Add a test for the Calamares installer in openQA * Adjust the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en * Bug triaging for issues reported against live-build Unchanged, but low priority due to [5], patch available but not released yet: * texlive-base: Reported differences in the generated ls-R [2] * texlive-binaries: Randomness in .fmt files due to Lua hash seeds [3] * texlive-binaries: updmap creates a logfile with the timestamps of files that it just has generated [4] * Priority is now very low, since the package is not used in live images any more ** This section will be removed from my next report With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003449 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009196 [4] https://salsa.debian.org/live-team/live-build/-/commit/f1a98e4da62c3551f523553c6e23774aaf5e41b4 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006472 [11] https://salsa.debian.org/images-team/live-setup/-/merge_requests/2 [12] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-qa%40lists.debian.org&tag=openqa&format=html#results [13] https://salsa.debian.org/installer-team/live-installer/-/merge_requests/3 [14] https://salsa.debian.org/installer-team/localechooser/-/merge_requests/7 [15] https://salsa.debian.org/live-team/live-build/-/merge_requests/297 [16] https://salsa.debian.org/live-team/live-build/-/merge_requests/298 [17] https://lists.debian.org/debian-devel/2023/01/msg00128.html [18] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/23 [19] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017435 [20] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029393 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
Re: About applying non-free firmware on Debian Live images
Hello adrian15, On 08/12/2022 01:26, adrian15sgd wrote: I'm quite interested in Debian Live images having GPU firmware and so on... so that I can use them later as a basis for Rescatux (Debian Live based cd). Also about that boot option that enables or not that extra firmware. As I am a bit disconnected about current Debian Live work I have two questions: 1) Has the Debian-live team/people had a discussion on the mailing list about what this change might imply on the live images? Some people might argue that if a GPU starts in 640x480 only with free firmware then there is no need to include the non-free firmware. But that discussion is wider, and also encompasses Wifi-cards etc. In the end, there will be only the version with non-free firmware. 2) Any work already done on git commits / Salsa? No, not yet, but it will be one of my next tasks. At the moment I'm preparing the automated weekly builds for live images again, which was turned off about a year ago. Then I'll focus on the content of the live image. The inclusion of firmware is very high on my list to implement. If you are willing to implement this (because you'll have the immediate benefit), please state so, and I'll focus on other topics :-) With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: live-setup | Reintroduce regular building of live-build images (!2)
On 28/11/2022 00:49, Steve McIntyre wrote: On Sun, Nov 27, 2022 at 06:15:08PM +, Steve McIntyre wrote: ... Now I can see what you're do in your script, I'm working on merging to something more current. I've just remembered one thing that used to cause major issues with live-build: multiple image builds in parallel would sometimes trip over each other. For us on release weekends, this is a critical feature: we have a large build machine to make things go fast. I hope this is now fixed in live-build, I guess we'll see! If I did it right, every single build will run in its own directory, so they will not collide. (See the line with 'export BUILDDIR') For utmost speed, I assume that the environment variable 'http_proxy' is set. See also https://wiki.debian.org/ReproducibleInstalls/LiveImages. Thanks for your work so far! I'm hoping to get something working in the weekly image builds soon. You've done a lot, I didn't intend to bring you so much additional work. I've made quite a bit of progress - see my recent commits in the live-setup repo. One thing that I'm not convinced about in your script is building d-i as part of a build, I'd be happier to have the option for grabbing builds from d-i.debian.org like we use elsewhere (for the weekly builds), and then of course we'll pull from the archive directly for release builds. I'll try to find some time to comment on your additional changes soon. A few thoughts, primarily focussed on reproducibility: * I've used the git rebuild for d-i, because the d-i.debian.org images are fleeting, and cannot be used for long-term reproducibility tests. The git rebuild also contains a kernel detection part, so it would also produce a runnable d-i, even if the kernel version was not updated yet in git. * I've used the snapshot service instead of deb.debian.org also for long-term reproducibility reasons. deb.debian.org-based live images can only be reproduced within the same DAK-sync (every 6 hours) With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Monthly status update about reproducible live-build ISO images
Hello lists, here is the 15th update of the status for reproducible live-build ISO images [1]. Single line summary: The live images stayed reproducible. Reproducible status: * All major desktops build reproducibly with bullseye, bookworm and sid * Number of patches performed by the live-build script that are not yet in sid: zero! (0) My activities in November: * I've announced that live images can be generated again for Bookworm [10] ** I've received private replies, to be answered soon * First modifications in live-setup [11] ** Some changes have already been cherry-picked, more work is needed * Rebuild script has been adjusted to fix the red Jenkins tests for Bullseye [14][15] * Minor Jenkins update [16] * Some more tests in openQA have been adjusted [12][13] Functionality: Findings found by openQA (for sid): * Several desktops (cinnamon, lxde, xfce, mate) now have the 'lpr' as a default printer, which adds many numbered 'Print to Test Printer NN' entries * KDE: The default background image type changed from svg to png (and therefore the background is black) (#1021816) * LXQT: Should choosing LXQt as DE really install both Kwin & Xfwm4? (#1023472) * LXQT: Irrespective of which WM is chosen, the desktop crashes Work to be done: * Live images are not generated officially by Debian yet ** Needs additional changes in 'live-setup' ** This will be the next main target * Review the results of the generated ISO images in my local openQA instance * Add a test for the Calamares installer in openQA * Use a no-network scenario in openQA to test for 100% offline installation * Adjusting the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en Unchanged, but low priority due to [7], patch available but not released yet: * texlive-base: Reported differences in the generated ls-R [2] * texlive-binaries: Randomness in .fmt files due to Lua hash seeds [3] * texlive-binaries: updmap creates a logfile with the timestamps of files that it just has generated [4] Future plans/ideas: * Reprotest might be used instead of just 2 builds without a short time frame, to capture more variations * Use disorderfs * Transfer the special features of the (now disabled) live-wrapper live images to live-build With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003449 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009196 [4] https://salsa.debian.org/live-team/live-build/-/commit/f1a98e4da62c3551f523553c6e23774aaf5e41b4 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006472 [9] https://lists.debian.org/debian-devel/2022/09/msg00199.html [10] https://lists.debian.org/debian-devel/2022/11/msg00221.html [11] https://salsa.debian.org/images-team/live-setup/-/merge_requests/2 [12] https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/16 [13] https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/17 [14] https://salsa.debian.org/live-team/live-build/-/merge_requests/293 [15] https://salsa.debian.org/qa/jenkins.debian.net/-/commit/e237cab3ed87826b1c25b068b88fabcecf020d21 [16] https://salsa.debian.org/qa/jenkins.debian.net/-/commit/a9a967576104a38e45464d0f73544fd66df98aa8 OpenPGP_signature Description: OpenPGP digital signature
Re: [DEVEL] Enable support for Renesas platform (section: live images)
On 19/11/2022 09:56, Paul Wise wrote: On Fri, 2022-11-18 at 15:20 +0700, Huỳnh Thành Hưng wrote: I’m from Renesas Electronics Corporation, My group is developing to support running Debian OS on our devices, also for getting ARM System Ready IR certificate. ... Can you help me to enable those configs, also support the official release version of Debian Live Installer ISO which support Renesas platform? Debian does not yet support the ARM architecture at all with our live images, please contact the Debian Live Team about that. Currently the live images for the future Debian bookworm release are not being built, but that may change before the final release. https://wiki.debian.org/Teams/Live I posted a summary about the current status of the live images a few minutes ago: https://lists.debian.org/debian-devel/2022/11/msg00221.html Given that Debian Stable (hence its name) is stable and will receive bug fixes, but not typically additional features, I would recommend you to target Bookworm (the next release). If you want to create live images, I recommend you to take a look at the online manual at https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html The scripts can be highly customised, e.g. to contain custom kernels (see 8.2.10) With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Monthly status update about reproducible live-build ISO images
Hello lists, here is the 14th update of the status for reproducible live-build ISO images [1]. Single line summary: The live images stayed reproducible. Reproducible status: * All major desktops build reproducibly with bullseye, bookworm and sid * Number of patches performed by the live-build script that are not yet in sid: zero! (0) My activities in October: * Further testing of the live images in openQA, many tests are now green * The live images are also tested for UEFI secure boot (in addition to BIOS and non-secure UEFI) * The live images are also tests as USB-drive (in addition to CD-ROM boot) * Some comments in tickets for the snapshot.notset.fr service [10][11] * I've sent a private mail regarding the live image generation by official Debian hardware, more to follow next month Work to be done: * Review the results of the generated ISO images in my local openQA instance * Add a test for the Calamares installer in openQA * Use a no-network scenario in openQA to test for 100% offline installation * Live images are not generated officially by Debian yet ** Needs some changes in 'live-setup' ** This will be the next main target * Adjusting the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en Unchanged, but low priority due to [7], patch available but not released yet: * texlive-base: Reported differences in the generated ls-R [2] * texlive-binaries: Randomness in .fmt files due to Lua hash seeds [3] * texlive-binaries: updmap creates a logfile with the timestamps of files that it just has generated [4] Future plans/ideas: * Reprotest might be used instead of just 2 builds without a short time frame, to capture more variations * Use disorderfs * Transfer the special features of the (now disabled) live-wrapper live images to live-build * Start building official live-images again [6][8] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003449 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009196 [4] https://salsa.debian.org/live-team/live-build/-/commit/f1a98e4da62c3551f523553c6e23774aaf5e41b4 [6] https://lists.debian.org/debian-live/2022/03/msg00012.html [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006472 [8] infinote://gobby.debian.org/debconf22/bof/debian-installer [9] https://lists.debian.org/debian-devel/2022/09/msg00199.html [10] https://github.com/fepitre/debian-snapshot/issues/14 [11] https://github.com/fepitre/debian-snapshot/issues/15 OpenPGP_signature Description: OpenPGP digital signature
Re: about live-boot with uuid
Hello tongqing liu, On 20/10/2022 01:09, tongqing liu wrote: I hope this email finds you well, I am using live-boot in my project but I am try to setup live-media with uuid to fix issue live boot mount wrong filesystem squash file if I have 2 bootable disk available and both use live-boot and same file structure on it. Let me try to understand the scenario you describe. Are you booting a computer that has 2 live-boot USB-stick plugged in at the same time? Can you describe for me the steps that you take and the expected output? Then I'll be able to reproduce your case and try to find a fix. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Live Boot issue with Graphics Driver
Hello Rajaneesh, On 22/10/2022 12:13, finlinux na wrote: Looks like Debian Live Distro needs the following option for kernel in GRUB config file if GPU driver is installed.. nomodeset amd_iommu=off iommu=pt Else it will hang with series of DRM bit flip timeout error messages... Has anyone experienced this before? with "nomodeset amd_iommu=off iommu=pt" I was able to circumvent the problem..But there should be a better way without disabling the GPU driver.. On 2022-06-01 I've removed 'nomodeset' from the code, because that was causing hangups during the boot of the 'failsafe' option. Which version of live-build are you using? > I am using Ryzen 3 machine... Do you need all these 3 options for a normal live boot? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Select boot method (Was: Debian Live Boot issue with Graphics Driver)
Hello Rajaneesh, On 22/10/2022 12:18, finlinux na wrote: And a quick observation.. My virt-manager loads isoconfig at boot time and while booting a laptop from CDROM, grubcfg is loaded...Is there any way to control which config can be loaded at boot time? Because virt-manager does not have issue with GPU drivers while hard booting Live from CDROM has issue with GPU drivers.. You can configure the virtual machine in virt-manager (only before the first boot) to use BIOS or UEFI. When you create a new virtual machine, select 'Customise configuration before install' before pressing 'Finish'. Look at 'Overview', 'Hypervisor Details', 'Firmware': Select either 'BIOS' for legacy boot using isolinux, 'UEFI' for non-secure boot or 'UEFI..OVMF_CODE_4M.ms.fd' for UEFI secure boot. Both UEFI modes use grub. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Creating live build using package downloaded locally
Hello Rajaneesh, On 20/10/2022 06:32, finlinux na wrote: I am a newbie in live build..When using live-build, the packages get downloaded from debian mirror site.. depending on the time of the day, there are network latency.. To avoid latency and facilitate faster build I thought I had following options a) I could download the required package locally and put it in package folder (as 3rd party packages) in the config directory b) create a debian mirror locally of size 150 GB.. c) Alternatively, I could split the "lb build" as sequences of lb bootstrap lb chroot lb binary lb source and execute then one by one...If any stage fails, then start from that stage.. > Kindly advice which is the best way to go forward.. and pointers for > each method.. Option D: Use a proxy, see my Wiki page where I described my setup: https://wiki.debian.org/ReproducibleInstalls/LiveImages When I'm adjusting the configuration for my live images, I reduce the amount of downloads by taking a fixed timestamp (by setting the environment variable SOURCE_DATE_EPOCH and using a snapshot server) and use that until I'm satisfied with the content of the image. Then I'll change back to use deb.debian.org instead of the snapshot server. Also take a look at the script 'rebuild.sh' in the test folder of the git repository (https://salsa.debian.org/live-team/live-build/-/blob/master/test/rebuild.sh) With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1020940: debian-live: A large number of locales are created by default
Hello Green, On 29/09/2022 03:10, Green wrote: Installing from Debian Live installs a large number of non-Japanese locales by default, which takes extra time and disk space when updating. The live image contains many locales, which allows Debian to create only a single image for all those locales. When you install from the live image, you'll get a copy of the live image on your hard disc, minus the things that are specific to booting live images. This means that all locales will be available for you as well. If you only want to have some specific locales, you'll need to customise the installed image, as you have done. You can remove them all at once by the following procedure. After removal, reinstall firefox-esr-l10n-en. (The same problem occurs with libreoffice-help-*.) This is a situation not intended by the user, so it is considered a bug. I consider this to be a feature :-) However, given that you are not the first to wonder about the amount of localisation packages, this bug report could be considered to become a feature request: have the installer(s) ask which locales you would like to keep. With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Monthly status update about reproducible live-build ISO images
Hello lists, here is the 13th update of the status for reproducible live-build ISO images [1]. Reproducible status (New: no patches required any more): * All major desktops build reproducibly with bullseye, bookworm and sid * Number of patches performed by the live-build script that are not yet in sid: zero! (0) My activities in September: * I noticed that [7] (the last patch for Cinnamon) got included on 2022-08-14 in sid, and 2022-08-20 in bookworm * The live images are now automatically fed to openQA after they have been proven to be reproducible * I've asked a question on debian-devel about 'the' timestamp of a snapshot of deb.debian.org [9] ** Answer: Different timestamps are present in the URLs of snapshot.d.o and the content of InRelease ** My conclusion: Patches would be needed to sync those values ** My goal: generate an image from deb.debian.org and verify it after snapshot.d.o (or snapshot.notset.fr or snapshot.reproducible-build.org) contains that timestamp/content ** josch suggested to use metasnap to find the suitable timestamps instead Work to be done: * Review the results of the generated ISO images in my local openQA instance * Add a test for the Calamares installer in openQA * Booting with UEFI secure boot (waiting for #1015759) in openQA -> the ticket is closed, so the work can continue * Use a no-network scenario in openQA to test for 100% offline installation * Live images are not generated officially by Debian yet ** Needs some changes in 'live-setup' ** Once the chain of tests (reproducible by Jenkins, functional by openQA) is set up, this will be the next main target * Adjusting the content of the live-build image ** Make the boot menu more similar to the live-wrapper menu ** Add a 'persistent' option (as seen in Kali) ** Keep the accessibility improvements made in the live-wrapper boot menu ** Verify the package lists *** e.g. the Debian Reference is installed for es and it, but not en Unchanged, but low priority due to [7], patch available but not released yet: * texlive-base: Reported differences in the generated ls-R [2] * texlive-binaries: Randomness in .fmt files due to Lua hash seeds [3] * texlive-binaries: updmap creates a logfile with the timestamps of files that it just has generated [4] Future plans/ideas: * Reprotest might be used instead of just 2 builds without a short time frame, to capture more variations * Use disorderfs * Transfer the special features of the (now disabled) live-wrapper live images to live-build * Start building official live-images again [6][8] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003449 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009196 [4] https://salsa.debian.org/live-team/live-build/-/commit/f1a98e4da62c3551f523553c6e23774aaf5e41b4 [6] https://lists.debian.org/debian-live/2022/03/msg00012.html [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006472 [8] infinote://gobby.debian.org/debconf22/bof/debian-installer [9] https://lists.debian.org/debian-devel/2022/09/msg00199.html OpenPGP_signature Description: OpenPGP digital signature
