Bug#982835: installation-report: doesn't set needed rootflags for flash-kernel when btrfs is used as rootfs
On 2021-10-02, Vagrant Cascadian wrote:
> On 2021-02-15, Vieno Hakkerinen wrote:
>> I created a ext2 for /boot and luks+lvm+btrfs for /. As d-i defaults
>> to use a @rootfs subvolume for btrfs the linux bootargs need to have
>> set "rootflags=subvol=@rootfs". This was not set during configuration
>> of flash-kernel. Without this argument debian failed to boot with an
>> error that no init was found.
>
>>* What outcome did you expect instead?
>>
>> debian-installer should set "rootflags=subvol=@rootfs" in
>> /etc/default/flash-kernel when btrfs is used for /
>
>>* What did you do to solve the problem?
>>
>> 1. I ran "setenv bootargs rootflags=subvol=@rootfs" in u-boot
>> 2. I ran "boot" in u-boot
>> 3. debian found init successfully
>> 4. I added "rootflags=subvol=@rootfs" to LINUX_KERNEL_CMDLINE_DEFAULTS in
>> /etc/default/flash-kernel
>> 5. I ran flash-kernel
>> 6. I rebooted
>> 7. debian booted successfully
>
> So, flash-kernel-installer has a debconf question that might be useable
> for this purpose:
>
> flash-kernel-installer.postinst.in:echo flash-kernel
> flash-kernel/linux_cmdline string $kopt_params | \
> flash-kernel-installer.postinst.in- chroot /target debconf-set-selections
>
> I'm curious how other systems handle btrfs (e.g. grub on amd64); are
> there any configuration options passed via debian-installer to set
> "rootflags=subvol=@rootfs", or does grub have any configuration that are
> set from update-grub or whatever ... or autodetected when rootfs is on
> btrfs?
To answer my own question, looks like it's autodetected in
/etc/grub.d/10_linux:
case x"$GRUB_FS" in
xbtrfs)
rootsubvol="`make_system_path_relative_to_its_root /`"
rootsubvol="${rootsubvol#/}"
if [ "x${rootsubvol}" != x ]; then
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol}
${GRUB_CMDLINE_LINUX}"
fi;;
I suspect the way to handle this would be to have flash-kernel-installer
do something similar and pass it into the debconf option ... unless
someone can find a sane place to put that into flash-kernel at
run-time...
It might be easier to adapt other code, such as u-boot-menu and install
u-boot-menu instead of, or in addition to, flash-kernel... or at least,
that would be another case where this could be supported.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#982835: installation-report: doesn't set needed rootflags for flash-kernel when btrfs is used as rootfs
On 2021-02-15, Vieno Hakkerinen wrote: > I created a ext2 for /boot and luks+lvm+btrfs for /. As d-i defaults > to use a @rootfs subvolume for btrfs the linux bootargs need to have > set "rootflags=subvol=@rootfs". This was not set during configuration > of flash-kernel. Without this argument debian failed to boot with an > error that no init was found. >* What outcome did you expect instead? > > debian-installer should set "rootflags=subvol=@rootfs" in > /etc/default/flash-kernel when btrfs is used for / >* What did you do to solve the problem? > > 1. I ran "setenv bootargs rootflags=subvol=@rootfs" in u-boot > 2. I ran "boot" in u-boot > 3. debian found init successfully > 4. I added "rootflags=subvol=@rootfs" to LINUX_KERNEL_CMDLINE_DEFAULTS in > /etc/default/flash-kernel > 5. I ran flash-kernel > 6. I rebooted > 7. debian booted successfully So, flash-kernel-installer has a debconf question that might be useable for this purpose: flash-kernel-installer.postinst.in:echo flash-kernel flash-kernel/linux_cmdline string $kopt_params | \ flash-kernel-installer.postinst.in- chroot /target debconf-set-selections I'm curious how other systems handle btrfs (e.g. grub on amd64); are there any configuration options passed via debian-installer to set "rootflags=subvol=@rootfs", or does grub have any configuration that are set from update-grub or whatever ... or autodetected when rootfs is on btrfs? live well, vagrant signature.asc Description: PGP signature
Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"
Hi, I'm thinking about (long overdue) updating chapter https://d-i.debian.org/doc/installation-guide/en.amd64/ch04s03.html "Preparing Files for USB Memory Stick Booting". Additionally to the issues mentioned in related bugreports https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604839 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988472 I had some understanding issues, mostly in chapter "Manually copying files to the USB stick — the flexible way" Therefore, I would welcome some help/review, to make sure I got everything right. I have prepared a patch (attached). I have already tested everything documented in this chapter so far, and it works (at least for me) as documented in my patched version, so it doesn't look that bad IMO, but double-checking might be good. Notes: - I would not call files like vmlinuz or initrd.gz an "image" (to not be confused with the installation ISO images); so I changed such occurrences into "files". - I have fixed missing content/commands on several places. - #988472 proposes to no longer use "install-mbr" to install an MBR on the stick, but use 'cat /usr/lib/syslinux/mbr.bin >/dev/sdX' instead. Any objections or comments on this? (Works fine for me so far.) - Because a long time has passed by since the last overhaul of this chapter, maybe there is some more, that could be changed, for example because of changed/new technology or experience? If someone wants to read a complete html page, instead of the patch, I have uploaded my version to https://people.debian.org/~holgerw/ (Reading the html might be easier; I have swapped some sentences around, to get a better understandable and intuitive order. That makes the diff a lot more complex.) See https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html or https://people.debian.org/~holgerw/installation-guide_2021-10-02/arm64/ch04s03.html Thanks a lot Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/en/install-methods/boot-usb-files.xml b/en/install-methods/boot-usb-files.xml index 64aeb0aff..f1d61392b 100644 --- a/en/install-methods/boot-usb-files.xml +++ b/en/install-methods/boot-usb-files.xml @@ -23,23 +23,25 @@ The procedures described in this section will destroy anything already on the device! Make very sure that you use the correct device name for your USB stick. If you use the wrong device the result could be that all information on for example a hard disk could be lost. Preparing a USB stick using a hybrid CD/DVD image -Debian installation images can now be written directly to a USB stick, -which is a very easy way to make a bootable USB stick. Simply choose -an image (such as the netinst, CD, DVD-1, or netboot) that will fit +Debian installation images for this architecture are created using the +isohybrid technology; +that means they can be written directly to a USB stick, +which is a very easy way to make an installation media. Simply choose +an image (such as the netinst, CD or DVD-1) that will fit on your USB stick. See to get an installation image. Alternatively, for very small USB sticks, only a few megabytes in size, you can download the image from the netboot directory (at the location mentioned in ). @@ -75,73 +77,79 @@ people with specialised needs. The hybrid image on the stick does not occupy all the storage space, so it may be worth considering using the free space to hold firmware files or packages or any other files of your choice. This could be useful if you have only one stick or just want to keep everything you need on one device. -Create a second, FAT partition on the stick, mount the partition -and copy or unpack the firmware onto it. For example: +To do so, use cfdisk or any other partitioning tool to create an additional +partition on the stick. Then create a (FAT) filesystem on the partition, +mount it and copy or unpack the firmware onto it, for example with: -# mount /dev/sdX2 /mnt +# mkdosfs -n FIRMWARE /dev/sdX3 +# mount /dev/sdX3 /mnt # cd /mnt # tar zxvf /path/to/firmware.tar.gz # cd / # umount /mnt - +Take care that you use the correct device name for your USB stick. The +mkdosfs command is contained in the +dosfstools package. -You might have written the mini.iso to the USB -stick. In this case the second partition doesn't have to be created as, -very nicely, it will already be present. Unplugging and replugging the + + +If you have chosen the mini.iso to be written the USB +stick, the second partition doesn't have to be created, as - +very nice - it will already be present. Unplugging and replugging the USB stick should make the two partitions visible. - + Manually copying files to the USB stick An alternative way to set up your USB stick is to manually copy the installer files, and also an installation image to it. Note that the USB stick should be at least 1 GB in size (smaller
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 2021-09-30 22:16, Adam D. Barratt wrote: > On Mon, 2021-09-27 at 12:38 +0100, Adam D. Barratt wrote: > > Control: tags -1 + confirmed d-i > > > > To confirm some IRC conversations - given the closeness of the freeze > for 11.1, please feel free to upload and kibi can review the package > from stable-new. > Unfortunately Cyril has found an issue while testing, the query to debconf doesn't work when the libc6.preinst script is re-executed by the debconf frontend: | ... | Preparing to unpack .../libc6_2.31-13+deb11u1_amd64.deb ... | debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable | Unpacking libc6:amd64 (2.31-13+deb11u1) over (2.31-13+deb11u1) . | ... This message is harmless in most cases, but can cause a switch to text mode while debconf is able to fallback to another frontend. It is also very worrying for users. As discussed on IRC, I have uploaded glibc 2.31-13+deb11u2 that fixes that issue by not trying to detect if debconf is available when the debconf frontend has already been loaded. You will find the corresponding debdiff attached. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net diff --git a/debian/changelog b/debian/changelog index dd5370af..7c23c790 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +glibc (2.31-13+deb11u2) bullseye; urgency=medium + + [ Aurelien Jarno ] + * debian/debhelper.in/libc.preinst: do not try to detect if debconf is +available when the debconf frontend has already been loaded. + + -- Aurelien Jarno Sat, 02 Oct 2021 14:47:40 +0200 + glibc (2.31-13+deb11u1) bullseye; urgency=medium [ Aurelien Jarno ] diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst index f0285832..ff59ad9a 100644 --- a/debian/debhelper.in/libc.preinst +++ b/debian/debhelper.in/libc.preinst @@ -23,7 +23,11 @@ if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ] then # Check if the debconf module is available and usable USE_DEBCONF= -if [ -f /usr/share/debconf/confmodule ]; then +if [ "$DEBIAN_HAS_FRONTEND" ]; then +# Debconf is already loaded, so we already checked if the frontend +# is usable or not +USE_DEBCONF=1 +elif [ -f /usr/share/debconf/confmodule ]; then # cdebconf has a working fallback mechanism in case dialog # is not usable, so do not try to do anything smart here if [ "$DEBCONF_USE_CDEBCONF" ] ; then signature.asc Description: PGP signature
