Bug#1034389: installation-reports: bookworm cannot install base system

2023-04-15 Thread Pascal Hambourg

On 15/04/2023 at 02:49, Steve Witt wrote:

On 04/15, Pascal Hambourg wrote:


It seems that the USB drive capacity is slightly smaller than the ISO image
size.

USB drive capacity: 7700480 sectors / 3.94 GB / 3.67 GiB
DVD-1 image size:   7758432 sectors / 3.97 GB / 3.70 GiB

The DVD image size is slightly lower than 4 GB to fit into most 4-GB USB
drives but unfortunately there are USB drives whose actual capacity is
significantly lower than the rated capacity.

Didn't it trigger an error when writing the image to the USB drive ?


In recreating writing the image to the USB drive (with dd), it did
show an error, but previously I didn't notice that. So of course it
didn't work properly. I'm very sorry for the spurious bug report and
the waste of your time.


OK, thanks for confirming. debian-cd maintainers may consider reducing 
the DVD-1 image size a bit more to fit in smaller USB drives.




Bug#1034208: Partman may reset user's choice for ESP partitions use

2023-04-15 Thread Pascal Hambourg

Control: tags -1 patch

On 11/04/2023 at 08:53, I wrote:


as discussed in #debian-boot (you asked for it), I observed that partman 
resets the method set by the user on ESP partitions after setting LVM or 
RAID (and possibly encryption, I forgot to test).

(...)
This is caused by /lib/partman/init.d/50efi rewriting "efi" to $id/ 
method when being re-run after leaving LVM/RAID setup.


Suggested fix: do not rewrite $id/method if 
/var/lib/partman/uefi_check_done exists, either by moving the check 
before the device loop (my preferred) or by adding a check before 
writing the method.


Here are patches implementing the two versions of the above fix.

Note: in order to deal with a similar issue with swap devices, 
partman-basicfilesystems init.d/autouse_swap sets a per-device flag to 
only run the first time each device is encountered. I guess per-device 
flags were used instead of a single global flag because new swap devices 
may be discovered later in virtual devices (e.g. logical volumes), but 
per-device flags are not needed for ESPs because AFAIK ESPs can only be 
plain partitions on local disks and it is unlikely that new local disks 
are discovered later (unless the user attaches a removable drive).From 4bb7694a6750a0fd56bd4399c2412bb5304b1bd6 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Tue, 11 Apr 2023 14:35:44 +0200
Subject: [PATCH] init.d/efi: Only run checks and set method "efi" for ESPs
 once

Only set method "efi" for ESP partitions once, else user's
choice (e.g. "do not use") may be reset to "ESP" after
setting up LVM, RAID or encrypted volumes.
Also run the whole checks once, pointless otherwise.

Fixes: #1034208
---
 init.d/efi | 49 +
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/init.d/efi b/init.d/efi
index fa44a97..4f408c2 100755
--- a/init.d/efi
+++ b/init.d/efi
@@ -34,6 +34,11 @@ fi
 
 . /lib/partman/lib/base.sh
 
+if [ -f /var/lib/partman/uefi_check_done ]; then
+	log "Found flag file /var/lib/partman/uefi_check_done, not checking further"
+	exit 0
+fi
+
 gpt_efi_type=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
 gpt_bios_boot_type=21686148-6449-6e6f-744e-656564454649
 msdos_efi_type=0xef
@@ -133,28 +138,24 @@ done
 
 log "Found $NUM_ESP ESP(s), $NUM_NOT_ESP BIOS-bootable disk(s) total"
 
-if [ -f /var/lib/partman/uefi_check_done ]; then
-	log "Found flag file /var/lib/partman/uefi_check_done, not checking further"
-else
-	if in_efi_mode && [ $NUM_ESP = 0 ] && [ $NUM_NOT_ESP -gt 0 ]; then
-		case $ARCH in
-			i386/*|amd64/*)
-db_input critical partman-efi/non_efi_system || true
-db_go || exit 1
-db_fset partman-efi/non_efi_system seen true
-db_get partman-efi/non_efi_system
-if [ "$RET" = false ]; then
-	log "User chose to ignore UEFI"
-	touch /var/lib/partman/ignore_uefi
-else
-	log "User chose to continue in UEFI mode"
-fi
-;;
-		esac
-	fi
-	# We've got this far at least once without triggering the
-	# check. Flag that so that any further changes we make in this
-	# d-i session can't trigger a false-positive here.
-	touch /var/lib/partman/uefi_check_done
-	log "UEFI check done, wrote flag file /var/lib/partman/uefi_check_done"
+if in_efi_mode && [ $NUM_ESP = 0 ] && [ $NUM_NOT_ESP -gt 0 ]; then
+	case $ARCH in
+		i386/*|amd64/*)
+			db_input critical partman-efi/non_efi_system || true
+			db_go || exit 1
+			db_fset partman-efi/non_efi_system seen true
+			db_get partman-efi/non_efi_system
+			if [ "$RET" = false ]; then
+log "User chose to ignore UEFI"
+touch /var/lib/partman/ignore_uefi
+			else
+log "User chose to continue in UEFI mode"
+			fi
+			;;
+	esac
 fi
+# We've got this far at least once without triggering the
+# check. Flag that so that any further changes we make in this
+# d-i session can't trigger a false-positive here.
+touch /var/lib/partman/uefi_check_done
+log "UEFI check done, wrote flag file /var/lib/partman/uefi_check_done"
-- 
2.30.2

From 6109240a6b599a5f198fd1b1a3747e81ec306118 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Tue, 11 Apr 2023 14:16:29 +0200
Subject: [PATCH] init.d/efi: Only set method "efi" on ESP partitions once

Else user's choice (e.g. "do not use") may be reset to "ESP"
after setting up LVM, RAID or encrypted volumes.

Fixes: #1034208
---
 init.d/efi | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/init.d/efi b/init.d/efi
index fa44a97..af3e7e8 100755
--- a/init.d/efi
+++ b/init.d/efi
@@ -110,8 +110,11 @@ for dev in /var/lib/partman/devices/*; do
 		if [ "$efi" = yes ]; then
 			# An ESP is clearly not for BIOS use!
 			log "$dev $id is an ESP"
-			mkdir -p $id
-			echo efi >$id/method
+			# set method only once, see #1034208
+			if [ -f /var/lib/partman/uefi_check_done ]; then
+mkdir -p $id
+echo efi >$id/method
+			fi
 			NUM_ESP=$(($NUM_ESP + 1))
 		else
 			# BIOS may well work with anything else
-- 
2.30.2



Processed: Re: Bug#1034208: Partman may reset user's choice for ESP partitions use

2023-04-15 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 patch
Bug #1034208 [partman-efi] Partman may reset user's choice for ESP partitions 
use
Added tag(s) patch.

-- 
1034208: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034208
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-15 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 + patch
Bug #1033737 [flash-kernel] flash-kernel: Unable to run flash-kernel on 
EFI-based systems
Added tag(s) patch.

-- 
1033737: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033737
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-15 Thread Johannes Schauer Marin Rodrigues
Control: tag -1 + patch

Hi,

On Fri, 31 Mar 2023 13:52:45 + Isaac True  wrote:
> As part of our CI/CD system, we are building images for target devices.  The
> images are set up in virtual machines which boot using EFI, but flash-kernel
> installation always fails as it detects that the system is running in EFI by
> checking for the existence of /sys/firmware/efi.

we have the same problem when building bootable images for the MNT Reform
laptop:

https://source.mnt.re/reform/reform-system-image/

The CI system is a machine that boots with EFI but the final system uses uboot
to boot and not EFI.

> Being able to setup the image on these VMs is an important part of our
> testing and validation workflow, so it would be very helpful to have an
> option to skip this check and proceed regardless of whether the system is
> currently running in EFI mode or not.

This used to work in the past but was broken by this commit:

https://salsa.debian.org/installer-team/flash-kernel/-/commit/8a81a537995a2b98386aea883729ce9960a825bf

> I've added a debdiff for a proposal for a new parameter --force-efi which can
> be set to skip this check.

The problem with implementing this using a command line flag or an environment
variable is, that then you will have to run flash-kernel again manually after
initially installing it.

What do you think about instead using an option in /etc/default/flash-kernel
which allows ignoring /sys/firmware/efi if inside a chroot as I implemented
here:

https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/33

Thanks!

cheers, josch

signature.asc
Description: signature