Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 31/05/2024 at 10:26, Roland Clobus wrote:


* Moment 1: the first d-i screen is shown. The USB device is seen by the 
kernel, but the module is not yet loaded

ls -d /sys/bus/usb/drivers/r8712u/1-3*
No such file or directory


As expected, the module is not loaded so /sys/bus/usb/drivers/r8712u 
does not exist.



ls -d /sys/bus/usb/drivers/usb/1-3*
/sys/bus/usb/drivers/usb/1-3
ls -d /sys/bus/usb/devices/1-3/1-3*
/sys/bus/usb/devices/1-3/1-3:1:0


The device is present.


* Moment 2: the d-i screen 'No Ethernet card was detected' is shown
(The firmware has been placed where it can be found, module r8712u has 
been removed and added)

ls -d /sys/bus/usb/drivers/r8712u/1-3*
No such file or directory
The module is loaded so /sys/bus/usb/drivers/r8712u should exist but is 
not associated with the device.



ls -d /sys/bus/usb/drivers/usb/1-3*
No such file or directory
ls -d /sys/bus/usb/devices/1-3/1-3*
No such file or directory


It looks like the device is not present any more. But there was no 
disconnect message in the kernel log. All I can see it the reset 
message, but AFAICS a reset should not remove the device. Maybe it was 
disabled or powered down.


I do not know enough about the kernel and USB subsystem to have any clue 
about what is wrong. Maybe running "udevadm trigger" during specific 
moments and recording its output may provide useful information:

- when the adapter is connected
- when the module is loaded without the firmware
- when the adapter is disconnected
- when the module is reloaded with the firmware

You do not have to run check-missing-firmware for this, you can run 
modprobe commands in a shell.


* Moment 3: I disconnect and reconnect the USB device in virt-manager 
and select 'Detect network hardware' from the d-i menu. d-i shows a list 
of SSIDs

ls -d /sys/bus/usb/drivers/r8712u/1-3*
/sys/bus/usb/drivers/r8712u/1-3:1.0


As expected, the device is associated with the driver.

Bug#1072215: USB wireless Netgear WNA1100 fails to load

[Pascal Hambourg]

Hello Tom,

On 30/05/2024 at 13:33, Tom Overlund wrote:


/var/log/syslog indicates it tried to load firmware for the USB WiFi
device, failed, but loaded the kernel module anyways. Then the
installer detected this, installed the package with the firmware, and
then got some errors about realoding USB modules.
It seems that check-missing-firmware failed to identify the correct 
kernel module. At this point, can you post the output of


ls -d /sys/bus/usb/drivers/ath9k_htc/3-3*
ls -d /sys/bus/usb/devices/3-3/3-3*

assuming the wireless adapter is identified as 3-3 ?

Then can you try the patches for hw-detect attached to 
 ?

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 26/05/2024 at 22:29, Roland Clobus wrote:


Your patch series works fine, the firmware is correctly identified and 
loaded. Unfortunately for me, it still needs a reconnect cycle.

See the attached syslog for their effect. (I've used sid)


Thank you for testing my patches but I did not expect them to solve the 
reattachment issue, only to identify the right module.


After the r8712u module is first loaded without the firmware then 
unloaded and reloaded, what is the output of


ls -d /sys/bus/usb/drivers/r8712u/1-3*
ls -d /sys/bus/usb/devices/1-3/1-3*

assuming the wireless adapter is identified as 1-3 ?

Bug#1071927: discover: Discover displaying packages wrong.

[Pascal Hambourg]

On 26/05/2024 at 05:58, user wrote:

Package: discover
Version: 2.1.2-10
Severity: normal
X-Debbugs-Cc: heterocycle_papill...@simplelogin.com

Dear Maintainer,

When I open Discover and type "antivirus" into the search bar, packages from
the KDE Store appear, but when I click on settings and then search for
"antivirus" I get packages from Debian only.


Package "discover" provides a hardware identification system. Aren't you 
confusing with plasma-discover ? If so, you can reassign this bug by 
replying with the following pseudo-header:


Control: reassign -1 plasma-discover 5.27.5-2

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 25/05/2024 at 22:10, Roland Clobus wrote:


When I run the Debian installer, the missing firmware file is correctly 
identified and installed by 'check-missing-firmware.sh'. However, the 
kernel module is mis-identified as 'usb'.


This is a more generic issue already reported in #1033679


Can you give a try to the attached patches ? They came to late for 
bookworm, maybe it is time to reconsider them.



Attached is a patch that allows the module to be identified correctly.
If desired, I can send the patch instead as a merge request on Salsa.


IMO $address should be included in the search pattern. Else if there is 
another device reported as "usb" then your patch will wrongly resolve it 
as r8712u too.


However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not 
sufficient to enable the adapter, it still needs a physical reconnect.
In the attached screenshot from the installer (sid) the result of the 
patch is shown. Also in the QEMU environment, I need to disconnect and 
reconnect the USB device from the host.


Looks like a driver/device issue.

Bug#1070753: Can't see PPPoE concentrators via d-i but pppoe-discovery can

[Pascal Hambourg]

Control: tags -1 patch

Proposed patch:

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 17/05/2024 at 13:22, Jmkr wrote:

Pascal Hambourg wrote:


You can set an alternative name and location by running grub-install
with --bootloader-id= or with GRUB_DISTRIBUTOR= in
/etc/default/grub. It also affects the directory name in the ESP. But
depending on the grub package version, monolithic GRUB images (signed
for secure boot) do not support being installed in another location than
/EFI/debian (I have been advocating to fix this but no luck so far).


Thanks for this as well as the other info you provided - it is nice to know even if I may 
end up not using it (as I probably want to use "/EFI/debian" directory for GRUB 
with just custom EFI boot entry names).


You can run grub-install with --no-nvram to install GRUB without writing 
EFI boot variables. The Debian installer also has an option for this in 
expert mode. Then you can create a custom boot entry with efibootmgr.

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 10/05/2024 at 00:52, Jmkr wrote:

Pascal Hambourg wrote:


You could just run grub-install to reinstall GRUB into the new ESP and
register it in EFI boot variables.


I wanted to try the manual way to learn + to create my EFI boot entry with a customized 
name. I think GRUB installation can only create EFI boot entry with the name 
"debian", or is it possible to change that?


You can set an alternative name and location by running grub-install 
with --bootloader-id= or with GRUB_DISTRIBUTOR= in 
/etc/default/grub. It also affects the directory name in the ESP. But 
depending on the grub package version, monolithic GRUB images (signed 
for secure boot) do not support being installed in another location than 
/EFI/debian (I have been advocating to fix this but no luck so far).



No, because in manual partitioning it is up to the user to decide which
ESP(s) is/are suitable for the installation, and set the others as "do
not use".


But is there a reason why DI partitioning does not set all (or previously existing) ESPs 
by default to "do not use" and let the user change that manually


I don't know why it was designed this way.


(perhaps with a reminder message if the user forgets to set the ESP in UEFI 
mode)?


The installer already warns if the partitioning does set an ESP.


Maybe it would be more intuitive + it could avoid/minimize user errors? Or is a 
shared ESP so common that DI partitioning needs its current defaults?


Yes, the ESP is designed to be shared by all boot loaders.

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 09/05/2024 at 12:42, Jmkr wrote:


- I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/
Archive.tar".

- Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to
"/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again.

- Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/
sdb1".

- Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and
created a new entry for ESP on "/dev/sdb1".


You could just run grub-install to reinstall GRUB into the new ESP and 
register it in EFI boot variables.



Do the fixes mentioned above also address the manual partitioning case?


No, because in manual partitioning it is up to the user to decide which 
ESP(s) is/are suitable for the installation, and set the others as "do 
not use".

Bug#1055583: base-files: EFI System Partition should mount on /efi not /boot/efi

[Pascal Hambourg]

On 15/04/2024 at 13:51, Santiago Vila wrote:


In this bug report, I'm asked to provide /efi as a mount point for the 
EFI partition.


Given that base-files does not even contain /boot/efi (the supposedly 
"old" location),

I believe this is a decision for you to make, hence the reassign.


partman-efi sets /boot/efi as the mount point for the ESP because this 
is where grub-install expects the ESP to be mounted by default. Changing 
the ESP mount point first implies to either:
- change all relevant package and installer scripts to call grub-install 
with --efi-directory=/efi
- change grub-install --efi-directory default to /efi instead of or in 
addition to /boot/efi
- replace GRUB with a boot loader such as systemd-boot which expects the 
ESP to be mounted on /efi by default

Bug#1068833: discover: A game installed via Discover doesn't start

[Pascal Hambourg]

Control: reassign -1 plasma-discover 5.27.5-2

On Thu, 11 Apr 2024 21:49:48 + Ilkka Kallioniemi 
 wrote:

On Thu, 11 Apr 2024 21:45:53 +0200 Pascal Hambourg  
wrote:
> Discover is a hardware identification system. Aren't your confusing with
> plasma-discover ?

Yes, I am. Sorry for confusing those. How to fix the mixup I caused?


This mail should reassign the bug to the right package.

Bug#1068833: discover: A game installed via Discover doesn't start

[Pascal Hambourg]

On 11/04/2024 at 20:22, Ilkka Kallioniemi wrote:

Package: discover

(...)

When installing game MegaGlest using Discover, the installed game is not fully
installed.


Discover is a hardware identification system. Aren't your confusing with 
plasma-discover ?

Bug#996202: EFI Secure Boot for systemd-boot

[Pascal Hambourg]

On 05/03/2024 at 00:58, Luca Boccassi wrote:

On Mon, 4 Mar 2024 at 23:28, Steve McIntyre  wrote:


What's your plan for installing as the secondary boot loader for shim
to call?


'bootctl update' already recognises and prefers foo.efi.signed if
present, so installing to the ESP is easy (PR still doesn't add the
call, will probably add a trigger).

But as you know Shim right now compiles in the filename of the second
stage, so for now interested testers will have to manually rename the
file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of
course not ideal - let's call it a technological preview.


What about the installation of shim files into the ESP along with 
systemd-boot ? Does bootctl take care of it ? If no, are there any plans 
to integrate it ?


Also, are there any plans to support multiple ESPs for boot redundancy 
(e.g. in software RAID setups) ?

Bug#769738: marked as done (debian-installer: Please automatically mount /usr in rescue mode)

[Pascal Hambourg]

On 02/03/2024 at 15:45, Debian Bug Tracking System wrote:

Your message dated Sat, 2 Mar 2024 15:42:38 +0100
with message-id 
and subject line Re: #769738: split usr is unsupported


Seriously ?


has caused the Debian Bug report #769738,
regarding debian-installer: Please automatically mount /usr in rescue mode
to be marked as done.


This bug is a duplicate of #1000239 which was fixed in rescue 1.86.

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Pascal Hambourg]

On 29/02/2024 at 08:51, Frank Weißer wrote:


Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(


eth* names are no persistent and may change at any boot.
But ethernet interface should get predictable names like enpXsY or enoX.
In /proc/interrupts we can see enp1s0.


randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'


By "randomized" do you mean "plain dm-crypt with random key" ?


The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab


These two remind me of Bug#995108 ("d-i: partman-crypto: plain dm-crypt 
device management issues").



I had submitted a patch but received no feedback so far.

Bug#1064906: Connman manages vnet virtual ethernet interfaces and assigns direct default route when DHCP fails

[Pascal Hambourg]

Package: connman
Version: 1.41-3

* My use case:
I run a virtual machine with virt-manager (KVM/QEMU). Each time the 
virtual machine is switched on, virt-manager creates a virtual ethernet 
interface vnetN with a different number and MAC address on the host and 
attaches it to the bridge virbr0. As a bridge member, vnetN is not 
supposed to receive any IP configuration.
Connman was installed on the host with LXDE and manages the physical 
ethernet and wireless interfaces with IPv4 and IPv6 automatic configuration.


* Problem description:
By default, connman manages vnetN with automatic methods and, after 
failing to use DHCP, assigns it a link-local IPv4 address (APIPA 
169.254.0.0/16) and a direct default IPv4 route with default metric (the 
highest priority). This default route conflicts with the existing IPv4 
default route associated with the physical network interface and breaks 
the host IPv4 connectivity outside the LAN.


syslog:

2024-02-27T14:40:24.211054+01:00 chantecler connmand[14215]: vnet0 {add} 
address 169.254.248.201/16 label vnet0 family 2
2024-02-27T14:40:24.211505+01:00 chantecler connmand[14215]: vnet0 {add} route 
169.254.0.0 gw 0.0.0.0 scope 253 
2024-02-27T14:40:24.211727+01:00 chantecler connmand[14215]: vnet0 {add} route 
0.0.0.0 gw 0.0.0.0 scope 253 
2024-02-27T14:40:24.211943+01:00 chantecler connmand[14215]: vnet0 {add} route 
0.0.0.0 gw 0.0.0.0 scope 253 


ip addr:

2: enp0s25:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000
inet 192.168.0.252/24 brd 192.168.0.255 scope global enp0s25
4: virbr0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
8: vnet0:  mtu 1500 qdisc noqueue 
master virbr0 state UNKNOWN group default qlen 1000
inet 169.254.248.201/16 brd 169.254.255.255 scope global vnet0


ip route:
0.0.0.0 dev vnet0 scope link 
default dev vnet0 scope link 
default via 192.168.0.1 dev enp0s25 
169.254.0.0/16 dev vnet0 proto kernel scope link src 169.254.248.201 
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.252 
192.168.0.1 dev enp0s25 scope link 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 


* Workaround:
Add "vnet" to NetworkInterfaceBlacklist in /etc/connman/main.conf.

* Comments/questions:
1) Isn't it desirable to ignore "vnet" interfaces in the default 
configuration ? Or is there a use case where connman should manage vnet 
interfaces ?


2) What is the use case for creating a direct default IPv4 route when 
DHCP failed and an APIPA address was assigned, specially when another 
default route already exists ? Communicating with other hosts in the 
APIPA subnet on the same LAN does not require it. It may allow to send 
packets to other hosts in non-APIPA subnets on the same LAN, but usually 
they do not have a direct route to the APIPA subnet and are unable to reply.


3) If such use case exists, shouldn't this default route have a low 
priority (high metric) so that other default routes take precedence ?

Bug#1029788: Acknowledgement (connman breaks systemd/udev network interface name policy)

[Pascal Hambourg]

Control: found -1 1.41-3

After migrating to bookworm, I confirm the issue is still present.

Workaround: append ",eth,wlan" to NetworkInterfaceBlacklist in 
/etc/connman/main.conf so that connman ignores ethernet and wireless 
interfaces until they are renamed, assuming new names do not start with 
"eth" or "wlan" (default ones do not).

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 27/02/2024 at 08:42, Philip Hands wrote:

Matthew Wilcox  writes:


I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Can one achieve this by telling LVM to allocate less than the full size
of the device to the PV one puts on it?


AFAIK partman does not support it. But guided partitioning allows to 
reserve some free space in the VG, which achieves the same goal.



If one does that, I would guess that one could later extend the PV to
use more/all of the disk using pvresize, so that those that prefer space
over endurance could make that decission when they are running out of
space.


IMO reserving free space in the VG allows this more easily, as you do 
not need to resize the PV when you need to use the free space.


But both ways have the same issue with Matthew's use case: when/if 
partman-auto-crypto erases (=writes with random data) the whole 
underlying LUKS partition, all its blocks are marked "in use" by the SSD.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 26/02/2024 at 01:14, Matthew Wilcox wrote:



- create a logical volume in the free VG space
- blkdiscard the logical volume


Last time I checked, dm-crypt did not pass DISCARD requests through to
the underlying device because it's a security hazard.


AFAICS dm-crypt and cryptsetup have supported discard since Linux 3.1.

crypttab(5) states that "starting with Debian 10 (Buster), this option 
is added per default to new dm-crypt devices by the Debian Installer".


Discard can still be disabled at the filesystem or swap level, or you 
can disable dm-crypt discard after running blkdiscard.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 23:55, Matthew Wilcox wrote:


I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the encrypted
volume group.


That does not accomplish my goal of extending the life of my SSD.  The
SSD will see those blocks as "in use" because they have encrypted data
written to them


Not if you do not write anything to them, or if you TRIM them.

You may either
- tell the installer not to erase (=write) the encrypted partition (if 
guided partitioning prompts it, not sure)

or
- enable "discard" in /etc/crypttab (should be the default)
- create a logical volume in the free VG space
- blkdiscard the logical volume


(it cannot tell that they are encrypted blocks of zeroes
because, well, they're encrypted).


Irrelevant. Once written, even with plaintext zeroes, a block is 
considered used until it is TRIMmed.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 05:40, Matthew Wilcox wrote:


The partitioner "guided partitioning" offers me:

  - use the largest continuous free space
  - use entire disk
  - use entire disk and set up LVM
  - use entire disk and set up encrypted LVM

I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the 
encrypted volume group.



Also once I start partitioning, eg, "and set up LVM", I can't delete the
partitions again.


The installer allows to delete logical volumes, volume groups and 
unencrypted partitions formerly used as physical volumes, but not 
encrypted volumes nor their underlying partitions.

Bug#1064617: Passwords should not be changed frequently

[Pascal Hambourg]

On 25/02/2024 at 01:17, Matthew Wilcox wrote:


I just did an installation with the 2024-02-24
debian-testing-amd64-netinst.iso image.  I forget the exact wording
used, but when setting up a user, d-i printed advice that user passwords
should be changed frequently.  This is no longer current good advice
(since 2017):


This topic has some history, see

Bug#1064010: Kernel not compiling missing file drm_irq.h

[Pascal Hambourg]

On 15/02/2024 at 18:08, Joshua Brickel wrote:


Whe running apt-get upgrade I get erors about the kernel installing/building
and it tells me to look in the file  /var/lib/dkms/evdi/1.7.0/build/make.log


Are you doing an installation or an upgrade ? From/to which version(s) ?


make[2]: *** [/usr/src/linux-
headers-6.1.0-18-common/scripts/Makefile.build:255:
/var/lib/dkms/evdi/1.7.0/build/evdi_ioc32.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /var/lib/dkms/evdi/1.7.0/build/evdi_main.c:20:
/var/lib/dkms/evdi/1.7.0/build/evdi_drv.h:24:10: fatal error:
drm/drm_irq.h: No such file or directory
   24 | #include 


This looks like bug#1017058 
 which was 
fixed in evdi 1.12.0 available in bookworm. Your evdi version 1.7.0 
seems to be outdated, even bullseye has evdi 1.9.0.

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Pascal Hambourg]

On 11/01/2024 at 12:56, Luca Boccassi wrote:


Yes it is a firmware feature, so it depends on the hardware, and in all
drives I know of that will be the case, yes. From that point of view,
to me it doesn't seem that far away from dm-crypt using the CPU's AES-
NI to actually encrypt/decrypt data, or anything else implemented in
hardware/firmware that the installer now supports out of the box with
non-free-firmware being enabled by default. If I am trusting Intel to
handle my data in their wifi firmware, and in their CPU microcode, and
memory controllers, and whatever else is on my hardware, it seems
strange to start worrying once the line is crossed into the NVME
firmware...


Correct me if I'm wrong, but aren't CPUs and wifi controllers 
pass-through devices which do not persistently store encryption keys or 
data and whose encrypted output can be inspected to check if they are 
doing the right thing so that you do not have to blindly trust them ?


Self-encrypted drives persistently store encryption keys and data. Can 
their encrypted output reliably be inspected ? Can they be trusted if 
the manufacturer implemented some hidden mechanism allowing to recover 
the data when customers lost their password (like BIOS manufacturers do) 
which will be leaked sooner or later ?

Bug#1060368: partman-auto: add basic support for loongarch64

[Pascal Hambourg]

Hello,

On 10/01/2024 at 04:15, zhangdandan wrote:


Support automatic partition adaptation partman-auto for debian-installer.
Please consider the patch (my local patch) I have attached.


I do not know anything about the loongarch64 architecture, but I can't 
help having questions about the proposed recipes. Do you have any 
pointers about the disk layout expected by this platform ? Or is it 
standard UEFI disk layout ?


- loong64 and loong64-efi recipes are identical, so why not use symlinks 
like other recipes do instead of duplicating files ?


- Why is a separate /boot partition created only if the partitioning 
scheme is GPT ?


- A regular FAT32 filesystem is explicitly mounted on /boot/efi. Is it 
intended to be used as an EFI system partition ?


- If yes, why doesn't it use the dedicated "efi" method ?

- Moreover, why does it have "lvmok" (meaning that it can be a LVM 
logical volume) ? Platform firmware usually cannot read LVM.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

I forgot to mention it, but please also reply to the bug report address, 
not only me.


On 27/12/2023 at 12:17, Christian Kirsch wrote:

Yes, thank you! I hadn't dared to execute these commands. But they
worked, very good.
So 'update-grub' and 'grub-install' fits the Problem.


I wonder which one was actually needed. I should have suggested to run 
one and reboot, then run the other one only if the issue persisted.


So maybe GRUB was not properly installed after all. But I am failing to 
figure out what could have gone wrong. Can you compress and attach the 
installation log (/var/log/installer/syslog) please ?



I also activated 'GRUB_DISABLE_OS_PROBER=false' so Ubuntu is also taken
along, for all cases (so said in germany...).
Then this process is finished for me and I thank you for your help,
Christian

Am Mittwoch, dem 27.12.2023 um 11:15 +0100 schrieb Pascal Hambourg:


Basically, the Debian installer just installs required grub packages and
runs grub-install and update-grub in the target system environment so if
GRUB loads and displays the menu, it is unlikely that the installer did
something wrong.

After booting into Debian through Ubuntu's GRUB menu, you can try to
re-run these commands and reboot with Debian GRUB. If it does not fix
the error, then the issue probably lies in GRUB itself and the bug
may be reassigned to grub2.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

Le 26/12/2023 à 20:35, Christian Kirsch wrote:

Thank you for your feedback.
I can probably support the assumption about Grub: I have installed
another partition with Ubuntu. Ubuntu recognizes the Debian partition
and updates the grub correctly. Debian can now be started from there.
This would mean that there is an error in the Debian iso file for the
grub management in the EFI-Partition.


Basically, the Debian installer just installs required grub packages and 
runs grub-install and update-grub in the target system environment so if 
GRUB loads and displays the menu, it is unlikely that the installer did 
something wrong.


After booting into Debian through Ubuntu's GRUB menu, you can try to 
re-run these commands and reboot with Debian GRUB. If it does not fix 
the error, then the issue probably lies in GRUB itself and the bug may 
be reassigned to grub2.



Am Sonntag, dem 24.12.2023 um 00:28 +0100 schrieb Pascal Hambourg:

On 23/12/2023 at 20:52, Christian Kirsch wrote:


When booting (first item), message on Debian screen:
"Arbeitsspeicher
erschöpft" ("Memory exhausted").


It matches the German translation for "out of memory" in GRUB.


Then start in a black terminal screen with Kernel panic: "Kernel
panic
- not syncing: VHS Unable to mount root fs on unknown-block(0,0)"


It looks like a consequence of GRUB failure to load the initramfs
properly.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

On 23/12/2023 at 20:52, Christian Kirsch wrote:


When booting (first item), message on Debian screen: "Arbeitsspeicher
erschöpft" ("Memory exhausted").


It matches the German translation for "out of memory" in GRUB.


Then start in a black terminal screen with Kernel panic: "Kernel panic
- not syncing: VHS Unable to mount root fs on unknown-block(0,0)"


It looks like a consequence of GRUB failure to load the initramfs properly.

Bug#1059167: installation-reports: installer hangs while recognizing network hardware

[Pascal Hambourg]

Hello Janusz,

On 20/12/2023 at 20:52, Janusz Bień wrote:


I understand the installer now includes non-free drivers,


No, only non-free firmware.


but I suspect  it missing one needed for my hardware, which is
Intel Ethernet Connection (7) I219-V
Intel Dual Band Wireless-AC 3168
(on the mainboard ASRock B360M-ITX/AC).


How does the installer hang ? Can you switch to the installer shell in 
tty2 with Ctrl+Alt+F2 ? If yes, can you post the output of


lspci -nnk

and attach (compressed) /var/log/syslog ?

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 17/12/2023 à 23:03, Paul van der Vlis wrote:

Op 17-12-2023 om 22:36 schreef Pascal Hambourg:


It may be an initialization issue: this error has been observed when 
booting after Windows hibernation or Fast Startup state. 


There is Windows on the NVMe disk of the laptop. Fastboot and secureboot 
where off.


UEFI/BIOS "fast boot" is not the same as Windows "fast startup".

I have also tested if I could boot the installer with fastboot on or 
secureboot on. But that dit not work.


Debian should work with secure boot on.

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 17/12/2023 at 14:31, Paul van der Vlis wrote:


Could it be the issue that was fixed in kernel 6.1.67-1 (available in 
proposed updates)?


The 12.4 installer kernel has the wireless bug but it is uncertain 
whether it affects the installer or not. What was wrong with the 
integrated Intel wireless controller ?


Do you still have the installer logs (/var/log/installer/syslog) ?


I will add the syslog. The error was "iwlwifi: probe of :00:14.3 
failed with error -110"


(Note for those who are reading this thread through the debian-boot 
mailing list: the mail with attachment was too big for the mailing list)


So it is not related with the recent wireless bug in 6.1.66.
It may be an initialization issue: this error has been observed when 
booting after Windows hibernation or Fast Startup state. See

https://bugzilla.kernel.org/show_bug.cgi?id=209641
https://bugzilla.kernel.org/show_bug.cgi?id=201319#c55
for possible workarounds if it happens again.


I see I did not use my Debian 12.4 stick, but a Debian 12.1 stick.


When you tried the installer again, which version was it ?


It's a bit strange install, I did install on an external USB SSD.


I do not think it is relevant.

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 16/12/2023 at 23:38, Paul van der Vlis wrote:

Op 16-12-2023 om 22:16 schreef Pascal Hambourg:

On 16/12/2023 at 20:15, Paul van der Vlis wrote:

Image version: Debian 12.4

(...)
I needed an USB dongle to get network. After installation I did use a 
backport-kernel to get the wifi working.

(...)

I have tried it again, and cannot reproduce this problem.

It works with the kernel of the installer. Sorry for the mistake.


What did you try exactly ? The installer or the kernel installed by the 
installer ?


A mistake is hard to believe. Something happened.

Could it be the issue that was fixed in kernel 6.1.67-1 (available in proposed 
updates)?


The 12.4 installer kernel has the wireless bug but it is uncertain 
whether it affects the installer or not. What was wrong with the 
integrated Intel wireless controller ?


Do you still have the installer logs (/var/log/installer/syslog) ?

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

Hello Paul,

On 16/12/2023 at 20:15, Paul van der Vlis wrote:

Image version: Debian 12.4
Machine: HP EliteBook 860 G9 (4C148AV)

(...)

Comments/Problems:
I needed an USB dongle to get network. After installation I did use a 
backport-kernel to get the wifi working.

(...)
00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi 
(rev 01)


According to /usr/share/misc/pci.ids, this device has PCI ID 8086:51f0 
which is listed in bookworm's iwlwifi module aliases.
Can you post the output of the following commands after booting with 
kernel 6.1 ?


lspci -nnkd ::280
dmesg | grep iwlwifi

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Pascal Hambourg]

On 15/12/2023 at 20:27, Carsten Schoenert wrote:


https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e


I think it would be better to add this stanza outside (before) the "for 
driver" loop. There are two cases, depending on the controller model:


1) iwlmvm is loaded

modprobe -r $module # fail because iwlwifi is used by iwlmvm
modprobe $module # no-op

for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # ok, unloads iwlwifi too
modprobe $module # reloads iwlwifi
fi
...

2) iwlmvm is not loaded

modprobe -r $module -> ok
modprobe $module -> ok

for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op
modprobe $module # no-op
fi
...

It appears there are fail and/or no-op in both cases. This would be simpler:

if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op if not loaded
fi
modprobe -r $module # no-op if unloaded with iwlmvm, but safe
modprobe $module

for driver in $(find /sys/bus/*/drivers -name "$module"); do
...

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

Control: forwarded 1035096 
https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/17

Hello,

On 27/05/2023 at 17:24, Cyril Brulebois wrote:


Thanks for testing Pascal's patches. Let's see if we can get that
included early in the Trixie release cycle, before possibly thinking
about some backports via a point release.


Is it the right time to reconsider this patch ?

Bug#1058638: grub-installer: boot fails: $bootdev empty [BIOS/MBR, Vista, 2 disks]: Installing grub on ''

[Pascal-liste]

Hello,

On 13/12/2023 at 20:45, Tj wrote:


After a lot of code-chasing it appears the problem is that
grub-installer script fails to set its $bootdev variable:

grub-installer: info: Installing grub on ''

(note the empty quotes)

The target system has two 'disks'. The first has Microsoft Windows Vista
with 2 NTFS partitions using msdos label/MBR. The second is empty and intended
for the Debian OS and boot-loader.

The system boots in BIOS/Legacy/CSM mode.


I suspect this is yet another avatar of bug #1035096, for which I 
submitted a patch, see 
.

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Pascal Hambourg]

Hello,

Le 13/12/2023 à 20:16, Cyril Brulebois a écrit :

Carsten Schoenert  (2023-12-13):

The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.


See the very bottom of check-missing-firmware.sh (hw-detect repository),
the loop over $modules. You could try intercepting $module = iwlwifi,
and adding a modprobe -r theotherone beforehand.


Wouldn't it be more generic to check /sys/module/${module}/holders like 
is done for mhi ?


Note: iwldvm is also loaded by iwlwifi (for older hardware I guess) and 
depends on it, but AFAICS it is not loaded when the requested firmware 
is missing, so there is no need to unload it. Is it expected that the 
behaviour is different with hardware using iwlmvm ?

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Pascal Hambourg]

On 25/11/2023 at 22:29, David Hillman wrote:

On 11/25/23 01:37, Cyril Brulebois wrote:

Extracting /var/log/syslog would be useful to understand what's going on
there. (...)

Thanks Cyril.  This system is running Debian 12, so there is no 
/var/log/syslog.


Cyril meant the installer syslog, which is saved in /var/log/installer 
on the installed system at the end of the installation.


(Gmail will probably reject this mail though)

Bug#1056655: Missing dependencies for grub-install lzo and xz compression

[Pascal Hambourg]

Package: grub2-common
Version: 2.06-13+deb12u1
Severity: minor

Dear maintainer,

grub-install --compress=lzo calls lzop provided by package lzop.

grub-install --compress=xz calls xz provided by package xz-utils.

However grub2-common does not have any dependency on these packages.

These packages have optional and standard priorities, which do not 
guarantee that they are present in a base installation. Maybe they 
should be added to Suggests (at least for user information) ?

Bug#1055806: installation-reports: Installer doesn't recognize laptop's SSD, but calamares does

[Pascal Hambourg]

On 11/11/2023 à 21:43, Jessie wrote:


However, when detecting disks, the only disk available for install was the usb 
drive I had the installer on - it did not detect the 256gb UFS SSD.


It looks like UFS (Universal Flash Storage, not Unix filesystem) kernel 
modules are not included in d-i initrd or udebs.

Bug#1054373: Regression in monolithic EFI normal disk boot image with --removable and --bootloader-id

[Pascal Hambourg]

MR: https://salsa.debian.org/grub-team/grub/-/merge_requests/44

Bug#1054373: Regression in monolithic EFI normal disk boot image with --removable and --bootloader-id

[Pascal Hambourg]

Package: src:grub2
Version: 2.06-14

Commit 5171e04d ("Bundle unicode.pf2 in a squashfs memdisk attached to 
the signed EFI binary") removed (memdisk)/grub.cfg from monolithic EFI 
normal disk boot images.


So now the normal disk boot image looks for grub.cfg in /EFI/debian only 
and not in $cmdpath any more. This breaks boot from the removable media 
path when installed with --removable, and normal boot when installed 
with --bootloader-id or $GRUB_DISTRIBUTOR != "debian".


Expected behaviour: GRUB loads $cmdpath/grub.cfg and displays the menu.
Observed behaviour: GRUB does not load $cmdpath/grub.cfg and enters 
command-line mode instead of displaying the menu.


Proposed fix: add a new grub.cfg into normal disk boot images instead of 
re-adding the previously used one which seems to be intended for CD boot 
images.


Option A: the new embedded grub.cfg looks for grub.cfg in $cmdpath first 
then in $prefix as fallback.


Option B: the new embedded grub.cfg looks for grub.cfg in $cmdpath only.
Caveats:
- For boot from the removable media path to keep working when installed 
with --force-extra-removable, this change requires to patch grub-install 
to install grub.cfg into the removable media path too.
- For boot from live and installation ISO-hybrid images to keep working, 
this change requires to patch the image builders to install grub.cfg 
into the removable media path.


Note: option A may also require grub-install --force-extra-removable to 
install grub.cfg in /EFI/Boot in order to boot properly from the 
removable media path when combined with --no-nvram and --bootloader-id 
or $GRUB_DISTRIBUTOR != "debian", which was already broken.

Bug#1054362: The PackageKit daemon has crashed

[Pascal Raton]

Subject: packagekit: The PackageKit daemon has crashed
Package: packagekit
Version: 1.2.7-1
Severity: normal

Dear Maintainer,

When I update the system with apper or discover, they stop with message 
"The PackageKit daemon has crashed
I reinstall all the system, same problem occur. Same thing in a VM fresh 
install

Here the log :


22/10/2023 16:40    packagekitd 
PackageKit:ERROR:../src/pk-transaction.c:5528:pk_transaction>
22/10/2023 16:40    packagekitd Bail out! 
PackageKit:ERROR:../src/pk-transaction.c:5528:pk_t>
22/10/2023 16:40    systemd Started 
systemd-coredump@17-462144-0.service - Process Core Dump (PI>
22/10/2023 16:40    systemd Started 
drkonqi-coredump-processor@17-462144-0.service - Pass system>
22/10/2023 16:40    systemd-coredump    Process 461772 
(packagekitd) of user 0 dumped core.


Module libudev.so.1 from deb systemd-254.5-1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-254.5-1.amd64
Stack trace of thread 461772:
#0  0x7f9a10fc n/a (libc.so.6 + 0x8a0fc)
#1  0x7f953472 raise (libc.so.6 + 0x3c472)
#2  0x7f93d4b2 abort (libc.so.6 + 0x264b2)
#3  0x7ffdaf08 n/a (libglib-2.0.so.0 + 0x1ef08)
#4  0x7fddde041e4e g_assertion_message_expr (libglib-2.0.so.0 + 0x85e4e)
#5  0x55bb171fdddc n/a (packagekitd + 0xfddc)
#6  0x7ff769c0 g_object_unref (libgobject-2.0.so.0 + 0x1b9c0)
#7  0x7ff98dc0 g_value_unset (libgobject-2.0.so.0 + 0x3ddc0)
#8  0x7ff85ebd n/a (libgobject-2.0.so.0 + 0x2aebd)
#9  0x7ff8c186 g_signal_emit_valist (libgobject-2.0.so.0 + 0x31186)
#10 0x7ff8c243 g_signal_emit (libgobject-2.0.so.0 + 0x31243)
#11 0x55bb17200992 pk_transaction_set_state (packagekitd + 0x12992)
#12 0x55bb1720728d n/a (packagekitd + 0x1928d)
#13 0x7fe7fc9c n/a (libgio-2.0.so.0 + 0x111c9c)
#14 0x7fddde013099 n/a (libglib-2.0.so.0 + 0x57099)
#15 0x7fddde0162d7 n/a (libglib-2.0.so.0 + 0x5a2d7)
#16 0x7fddde016bdf g_main_loop_run (libglib-2.0.so.0 + 0x5abdf)
#17 0x55bb171fbef1 main (packagekitd + 0xdef1)
#18 0x7f93e6ca n/a (libc.so.6 + 0x276ca)
#19 0x7f93e785 __libc_start_main (libc.so.6 + 0x27785)
#20 0x55bb171fc091 _start (packagekitd + 0xe091)

Stack trace of thread 462141:
#0  0x7fdddad165fd 
_ZN13debListParser12ParseDependsEPKcS1_RN3APT10StringViewES4_RjbbbNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 
(libapt-pkg.so.6.0 + 0x1165fd)

#1  0x7fdddad17ba4 n/a (libapt-pkg.so.6.0 + 0x117ba4)
#2  0x7fdddad19685 n/a (libapt-pkg.so.6.0 + 0x119685)
#3  0x7fdddad9f0c2 n/a (libapt-pkg.so.6.0 + 0x19f0c2)
#4  0x7fdddada1776 n/a (libapt-pkg.so.6.0 + 0x1a1776)
#5  0x7fdddad7f1d5 
_ZN18pkgDebianIndexFile5MergeER17pkgCacheGeneratorP10OpProgress 
(libapt-pkg.so.6.0 + 0x17f1d5)

#6  0x7fdddad9b091 n/a (libapt-pkg.so.6.0 + 0x19b091)
#7  0x7fdddad9cf87 n/a (libapt-pkg.so.6.0 + 0x19cf87)
#8  0x7fdddada46ba n/a (libapt-pkg.so.6.0 + 0x1a46ba)
#9  0x7fdddacb98f1 _ZN12pkgCacheFile11BuildCachesEP10OpProgressb 
(libapt-pkg.so.6.0 + 0xb98f1)
#10 0x7fdddacb9c48 _ZN12pkgCacheFile4OpenEP10OpProgressb 
(libapt-pkg.so.6.0 + 0xb9c48)
#11 0x7f3399e0 _ZN12AptCacheFile4OpenEb (libpk_backend_apt.so + 
0x219e0)

#12 0x7f33f244 _ZN6AptJob4initEPPc (libpk_backend_apt.so + 0x27244)
#13 0x7f3361e1 n/a (libpk_backend_apt.so + 0x1e1e1)
#14 0x55bb17211e4a n/a (packagekitd + 0x23e4a)
#15 0x7fddde0439e1 n/a (libglib-2.0.so.0 + 0x879e1)
#16 0x7f99f3ec n/a (libc.so.6 + 0x883ec)
#17 0x7fa1fa4c n/a (libc.so.6 + 0x108a4c)

Stack trace of thread 461778:
#0  0x7fa12a1f __poll (libc.so.6 + 0xfba1f)
#1  0x7fddde016237 n/a (libglib-2.0.so.0 + 0x5a237)
#2  0x7fddde016bdf g_main_loop_run (libglib-2.0.so.0 + 0x5abdf)
#3  0x7fe90dfa n/a (libgio-2.0.so.0 + 0x122dfa)
#4  0x7fddde0439e1 n/a (libglib-2.0.so.0 + 0x879e1)
#5  0x7f99f3ec n/a (libc.so.6 + 0x883ec)
#6  0x7fa1fa4c n/a (libc.so.6 + 0x108a4c)

Stack trace of thread 461779:
#0  0x7fa17ee9 syscall (libc.so.6 + 0x100ee9)
#1  0x7fddde071b70 g_cond_wait_until (libglib-2.0.so.0 + 0xb5b70)
#2  0x7ffe0133 n/a (libglib-2.0.so.0 + 0x24133)
#3  0x7fddde0443ea n/a (libglib-2.0.so.0 + 0x883ea)
#4  0x7fddde0439e1 n/a (libglib-2.0.so.0 + 0x879e1)
#5  0x7f99f3ec n/a (libc.so.6 + 0x883ec)
#6  0x7fa1fa4c n/a (libc.so.6 + 0x108a4c)

Stack trace of thread 461777:
#0  0x7fa12a1f __poll (libc.so.6 + 0xfba1f)
#1  0x7fddde016237 n/a (libglib-2.0.so.0 + 0x5a237)
#2  0x7fddde0168f0 g_main_context_iteration (libglib-2.0.so.0 + 0x5a8f0)
#3  0x7fddde016941 n/a (libglib-2.0.so.0 + 0x5a941)
#4  0x7fddde0439e1 n/a (libglib-2.0.so.0 + 0x879e1)
#5  0x7f99f3ec n/a (libc.so.6 + 0x883ec)
#6  0x7fa1fa4c n/a (libc.so.6 + 0x108a4c)

Stack trace of thread 461776:
#0  0x7fa17ee9 syscall (libc.so.6 + 0x100ee9)
#1  

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Pascal Hambourg]

On 15/09/2023 at 17:26, Todd Morgan wrote:

AFAIK /dev/sd* discovery and ordering was never guaranteed to be
deterministic nor persistent across boots nor match any hardware or
firmware ordering. One should not rely on these names, hence the use of
persistent identifiers such as UUID, device path or disk ID.


I agree. That is why I used UUID for the fstab entries. But this drive
ordering issue is specific to the installer. The preseed is expecting
a /dev/sd* type of entry in order for partman to partition the correct
drive...or in my case (using software RAID1) drives.


If I understand correctly, the issue is not drive ordering but the 
preseed capability to handle persistent drive identifiers.

Bug#1051611:

[Pascal Hambourg]

On 10/09/2023 at 16:59, G M wrote:

Install boot loader Grub - error.
Partitions: SCSI 20GB, Default partition layout for BIOS systems.


Failure to mount efivarfs in the target system. Looks like a duplicate 
of .

Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars

[Pascal Hambourg]

On 08/09/2023 at 13:56, Marc Haber wrote :


I tried installing sid from mini.iso into a libvirt/qemu/kvm VM with
BIOS "firmware", choosing mainly default values, and ended up with the
system logging "grub-installer: error: Error creating
/target/sys/firmware/efi/efivars" and an error message "Failed to mount
/target/proc, Mounting the proc file system on /target/proc failed".


This issue has been discussed in #1031183 starting from

(it is a different issue from the original bug report, so a separate bug 
should have been filed) and a merge request is in progress.

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Pascal Hambourg]

On 01/09/2023 at 01:17, Todd Morgan wrote:


When using the same method to install Debian 12, I am noticing that the
installer is detecting the drives out of order. It does not match what the
server BIOS or HPE ILO5 displays. With each PXE installation attempt the
ordering can vary. Looking in /dev/disk/by-path you can see the symlinks
differ between install attempts. Sometimes the order matches the PCI bus
reference and sometimes it's jumbled up.


AFAIK /dev/sd* discovery and ordering was never guaranteed to be 
deterministic nor persistent across boots nor match any hardware or 
firmware ordering. One should not rely on these names, hence the use of 
persistent identifiers such as UUID, device path or disk ID.



This is an issue when you want to tell partman to use /dev/sda (the first
drive) for the installation and have grub installed properly on /dev/sda.


I advise to not hardcode /dev/sd* anywhere and use persistent 
identifiers instead.

Bug#1050287: r8168-dkms: can't compile in kernel 6.4.0-3-amd64

[Pascal Hambourg]

On Fri, 25 Aug 2023 16:04:42 +0300 l...@forum-debian.fr wrote:


Replace
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,5,0)

By
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,4,10)


Indeed the gso split introduced in linux 6.5 was backported into linux 
6.4.10 (commit bbe07adbaf39c2c5a95c3ca7eb52b2119d50af7d). I did not find 
it in previous stable series.


PS: You can delete 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050328 which is a 
duplicate.


I don't think a bug report can be deleted and IIUC it should be closed 
only when the bug is fixed, so it should have been merged instead.

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Pascal Hambourg]

On 13/07/2023 at 08:54, Arnaud Rebillout wrote:
Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


FTR, this is due to the following change in linux 6.3:

commit 301de9a2055357375a4e1053d9df0f8f3467ff00
Author: Johan Hovold 
Date:   Thu Jan 19 17:42:53 2023 +0100

efivarfs: always register filesystem

The efivar ops are typically registered at subsys init time so that
they are available when efivarfs is registered at module init time.

Other efivars implementations, such as Google SMI, exist and can
currently be built as modules which means that efivar may not be
available when efivarfs is initialised.

Move the efivar availability check from module init to when the
filesystem is mounted to allow late registration of efivars.

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Pascal Hambourg]

On 21/08/2023 at 11:56, Arnaud Rebillout wrote:

On 21/08/2023 04:03, Philip Hands wrote:

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso


Hello, I download it and tested it in a QEMU VM. I tested it two times: 
with and without UEFI enabled. I can report that installation succeeded 
in both cases.


Did anyone test with EFI boot and fallback to legacy mode in partman 
("do not force EFI installation") ?

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

[Pascal Hambourg]

On 19/08/2023 at 10:28, Diederik de Haas wrote:

On Monday, 7 August 2023 18:25:07 CEST Jonathan Carter wrote:


Firstly, the instructions start off with "You need to set a password for
'root'", followed by seemingly uninteresting text about what a good password
should be, which makes it incredibly easy for users to miss the part that
sudo won't be set up for the first user.


Then just move the sudo text before the good password text.


So, many users, and especially newcomers to Debian, follow the instructions
in the first line and are then surprised when they can't use sudo from
their user from their newly installed system.


So what ? All they have to do is use su and add themselves to the sudoers.


Would it perhaps make more sense to move the root password setup to the
expert install d-i preseed entirely? Since this is likely only something
that expert users would require in the first place?


Unless there's something actually wrong about having an enabled root account
with a password, I would prefer if the option would stay.


Me too. Unless it changed recently, a root password is required to start 
the emergency shell when booting in recovery mode, so not having a root 
password makes fixing some problems harder.



move the explanation of what happens upward so that it's
more prominent and not so easy to miss.


Agreed. The good password text is relevant only when the user chooses to 
set a root password and not set up sudo for the first user.

Bug#936009: shim-unsigned:amd64 cannot be installed alongside shim-unsigned:i386

[Pascal Hambourg]

Control: tags -1 patch

Merge request !12 should fix this issue by adding "Multi-Arch: same".


Is there any reason to not accept it ?

Bug#1042437: partman-auto-lvm: using binary units for size of volume group does not work correctly

[Pascal Hambourg]

Hello Holger,

On 28/07/2023 at 10:48, Holger Wansing wrote:


With a bookworm 12.0 netinst image:
when choosing guided partitioning -> set up LVM, it is now allowed to use
binary units for volume group size (MiB, GiB, ...), but the size is wrongly
calculated.
For example, if I choose a volume group of 12 GiB, I get one with 11,9 GB, but
it should be roughly 12,9 GB.


1) How do you choose the VG size ? AFAICS, the only possible choice is 
to restrict the VG use to a given size or percentage.


2) How do you see the VG size ?

I tested guided LVM with all in one partition and restrict the VG used 
size to 12 GiB and I get a root LV of 11.9 GB and a swap LV of 1 GB, so 
a total use of 12.9 GB as expected. vgs shows 12 GiB used.

Bug#1041497: vmm: fails to run with python3 >= 3.10

[Pascal Volk]

On 2023-07-19 20:20, Bernd Zeimetz wrote:

[...]
AttributeError: module 'collections' has no attribute 'Callable'


collections.Callable is collections.abs.Callable since Python 3.10
[...]


Hi there,

this has been fixed in 
https://bitbucket.org/pvo/vmm/commits/29d157a4ee8f019fde92aa74976e9f168386a0fe/raw


Regards,
Pascal

Bug#1041500: amd64 installation images cannot install a signed 32-bit UEFI boot loader

[Pascal Hambourg]

Package: debian-cd
Version: 20230607

Dear maintainer,

Installation ISO images for amd64 can boot on 32-bit EFI with secure 
boot enabled but only install an unsigned 32-bit EFI boot loader so the 
installed system will be unbootable with secure boot enabled.


Causes:
- grub-efi-ia32-signed:amd64 and shim-helpers-i386-signed:amd64 do not exist
- grub-efi-ia32-bin:amd64 does not recommend grub-efi-ia32-signed
- shim-signed:amd64 and shim-unsigned:amd64 provide only files for 
64-bit EFI

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

On 17/07/2023 at 17:45, Christof B. wrote:

Am 15.07.23 um 22:57 schrieb Pascal Hambourg:

Replacing /lib/partman/init.d/50efi with either attached 50efi.1 or
50efi.2 as 50efi should fix the issue in guided partitioning with
encrypted LVM.


I tried each of them and they both solved my problem. /boot and 
/boot/efi were on the same (and correct) disk. The installed system was 
bootable :-)



Fixing the issue in guided partitioning with unencrypted LVM also
requires replacing /bin/autopartition-lvm with the attached
autopartition-lvm.


I could reproduce the same issue with unencrypted LVM (#1034812) on my 
machine with my stock installer image.


Like above, replacing 50efi by 50efi.1 plus the other file in /bin made 
the installation work alright. The system was bootable afterwards.


Thanks a lot for the quick fixes!


Thanks for testing. Should #1034812 and #1041168 be merged ?

Bug#1041231: bluetooth on debian bookworm@macbook pro 2012

[Pascal Hambourg]

Hello,

On 16/07/2023 at 06:07, Alex Wibowo wrote:


Image version: 


Please mention which ISO image you used, or at least which Debian 
version your installed. I assume Debian 12.



03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries
BCM4331 802.11a/b/g/n [14e4:4331] (rev 02)
Subsystem: Broadcom Inc. and subsidiaries BCM4331 802.11a/b/g/n 
[14e4:4331]
Kernel driver in use: bcma-pci-bridge
Kernel modules: bcma

This report is not for network issue. But I did have network issue
initially - wifi was not detected.
I had to install firmware-b43-installer package


Unfortunately the firmware required by this wireless controller cannot 
be packaged in Debian due to license incompatibility.



Anyway, back to the issue i want to report - I couldnt get bluetooth
to pair correctly with my mouse & keyboard.
I had to install bluez-firmware. After that, it works fine.


The bookworm installation image has this package but lacks 
/firmware/dep11/bluez-firmware.*, preventing the installer from 
detecting that this package is useful.


AFAICS BCM2033* files in the package are used by bcm203x and BCM434* 
files are used by btbcm. I could not find which module uses STLC2500* files.


The bcm203x module advertises both firmware and alias fields. However 
the btbcm module advertises neither. Relevant alias fields 
(acpi*:BCM2Exx:*) seem to be in the hci_uart module which depends on btbcm.


Can you please indicate which module is used and which firmware it 
loaded ? The information should be in the kernel log.

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

On 15/07/2023 at 21:17, Christof B. wrote:

Am 15.07.23 um 21:07 schrieb Pascal Hambourg:
If you are willing to test, I can provide patched files which replace 
the original ones in a running d-i.


Yes, I am willing to test this. If it can be patched by replacing some 
files at runtime (and not compiling some binaries or images), please 
provide me the files with a hint at where (path) and when (at which step 
of the installation process) to put them into place.


Replacing /lib/partman/init.d/50efi with either attached 50efi.1 or 
50efi.2 as 50efi should fix the issue in guided partitioning with 
encrypted LVM.


  cp /50efi.1 /lib/partman/init.d/50efi
or
  cp /50efi.2 /lib/partman/init.d/50efi

Fixing the issue in guided partitioning with unencrypted LVM also 
requires replacing /bin/autopartition-lvm with the attached 
autopartition-lvm.


  cp /autopartition-lvm /bin/autopartition-lvm

The files can be replaced after "Load installer components" and before 
"Partition disks".#!/bin/sh

# This script sets method "efi" for all fat16/fat32 partitions that
# have the bootable flag set.

ARCH="$(archdetect)"

# Prod the kernel to load EFI stuff and mount the efivarfs fs if
# needed
modprobe efivarfs >/dev/null 2>&1 || true
mount -t efivarfs none /sys/firmware/efi/efivars 2>&1 || true

in_efi_mode() {
[ -d /sys/firmware/efi ]
}

if in_efi_mode; then
> /var/lib/partman/efi
else
case $ARCH in
i386/mac|amd64/mac)
# Intel Macs have an EFI partition, regardless of
# whether we're currently booted using BIOS
# compatibility or not (if we are, we won't be able to
# talk to EFI directly).
> /var/lib/partman/efi
;;
*)
rm -f /var/lib/partman/efi
exit 0
;;
esac
fi

. /lib/partman/lib/base.sh

gpt_efi_type=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
gpt_bios_boot_type=21686148-6449-6e6f-744e-656564454649
msdos_efi_type=0xef

NUM_ESP=0
NUM_NOT_ESP=0

for dev in /var/lib/partman/devices/*; do
[ -d "$dev" ] || continue
cd $dev

open_dialog GET_LABEL_TYPE
read_line label_type
close_dialog

if [ "$label_type" = msdos ]; then
DISK_BIOS_BOOT=yes
else
DISK_BIOS_BOOT=no
fi

NON_EFI_THIS_DISK=0
partitions=
open_dialog PARTITIONS
while { read_line num id size type fs path name; [ "$id" ]; }; do
# Build a list of partitions that:
# 1. Will *not* be bios-bootable (e.g. ESP)
# 2. Might be bios-bootable (~anything that's not
#"free space"
if [ "$fs" = fat16 ]; then
partitions="$partitions $id"
elif [ "$fs" = fat32 ] && echo "$name" |
 grep -i "^EFI System Partition" >/dev/null; then
partitions="$partitions $id"
elif [ "$label_type" = msdos ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$msdos_efi_type" ]; then
partitions="$partitions $id"
elif [ "$label_type" = gpt ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$gpt_efi_type" ]; then
partitions="$partitions $id"
elif [ "$label_type" = gpt ] && \
 [ "$(blkid -o value -s PART_ENTRY_TYPE -p "$path" 
2>/dev/null)" = "$gpt_bios_boot_type" ]; then
# We have a GPT disk with a "BIOS BOOT"
# partition included, so this disk might be
# set up for BIOS boot.
DISK_BIOS_BOOT=yes
log "Disk $dev contains a BIOS boot partition"
partitions="$partitions $id"
else
if [ "$fs" != "free" ]; then
log "Partition $path might be bios-bootable, 
checking further"
partitions="$partitions $id"
fi
fi
done
close_dialog

# Now look for more details on each of those partitions
for id in $partitions; do
efi=no

open_dialog GET_FLAGS $id
# cannot break here until we've hit close_dialog below
while { read_line flag; [ "$flag" ]; }; do
  

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

On 15/07/2023 at 19:50, Christof B. wrote:


Am 15.07.23 um 18:35 schrieb Pascal Hambourg:


It looks like bug #1034812 (patches available).


Are there any (nightly) d-i images available to test these patches,
If you are willing to test, I can provide patched files which replace 
the original ones in a running d-i.

Bug#1041168: Installation of GRUB failed

[Pascal Hambourg]

Hello,

On 15/07/2023 at 15:28, Christof B. wrote:


Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/debian--vg-root
  120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234    352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi

(...)
Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition.


You mean /dev/sdb1. /dev/sdb2 is the /boot partition.

It looks like bug #1034812 (patches available).

Bug#1039058: shim-signed: Incorrectly depends on grub packages (grub-efi-amd64-bin, grub2-common)

[Pascal Hambourg]

Hello Wolf, maintainers,

On 25/06/2023 at 09:35, Wolf wrote:


 Was attempting to uninstall grub after switching to systemd-boot
 and adding it via mokutil to the allowed binaries for shim-signed.

(...)

 Effective workaround after shim-signed got uninstalled and system
 could no longer boot Linux: Extracted the shim-signed bootloader from
 the .deb and manually copied the file back into place as a stopgap.

 Side effect of workaround:

 No automatic updates when updates to shim-signed is released, need
 to notice it + unpack the update manually.


I guess shim-signed depends on grub2-common and grub-efi-amd64-bin 
packages because its postinst script calls grub-install to reinstall 
GRUB+shim files in the EFI partition on install or update. So even if 
the package dependency was removed and shim-signed could be installed 
without grub*, shim files in the EFI partition still would not be updated.


I am not the maintainer, but here is my opinion on this topic:

Calling grub-install in shim-signed postinst script is messy and wrong.
- It duplicates code from grub-efi-amd64 postinst script and must be 
kept in sync with it, e.g. to handle new debconf settings 
(force-extra-removable, no-nvram...).

- Also it runs grub-install even if grub-efi-amd64 is not installed.

Wouldn't a dpkg trigger to run grub-efi-amd64 (or any other bootloader 
using shim) postinst script on shim-signed update be a better option ?

Bug#1039872: Improve firmware package inclusion

[Pascal Hambourg]

On 05/07/2023 at 17:55, Steve McIntyre wrote:

On Wed, Jul 05, 2023 at 08:30:03AM +0200, Pascal Hambourg wrote:


As mentioned in #1032071, AFAICS firmware-ti-connectivity also contains
ARM-only firmware.


Hmmm, OK. The description isn't 100% clear here.


Indeed. I came to this conclusion after checking that the modules 
mentioned in the description were present only in ARM kernel-image packages.

Bug#1039872: Improve firmware package inclusion

[Pascal Hambourg]

On 05/07/2023 at 00:50, Steve McIntyre wrote:


I think that's quite a result! Comparing the ISOs, the differences are
just 5 missing firmware debs:

firmware-nvidia-gsp_525.116.04-1_amd64.deb
firmware-nvidia-tesla-gsp_525.105.17-2_amd64.deb
firmware-qcom-soc_20230515-2_all.deb
firmware-samsung_20230515-2_all.deb
raspi-firmware_1.20220830+ds-1_all.deb


As mentioned in #1032071, AFAICS firmware-ti-connectivity also contains 
ARM-only firmware.

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Pascal Hambourg]

On 04/07/2023 at 08:50, Samuel Thibault wrote:

Pascal Hambourg, le mar. 04 juil. 2023 08:09:33 +0200, a ecrit:

but AFAIK manual partitioning does not allow to create a partition
table on a RAID array.


Yes, but after creating the RAID array, one can use guided partitioning
and point it at the RAID disk, and that'll happily partition it


Yes, and this has always bothered me. IMO, for consistency, guided 
partitioning should not allow layouts that manual partitioning does not.

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Pascal Hambourg]

On 04/07/2023 at 08:36, Cyril Brulebois wrote:

Pascal Hambourg  (2023-07-04):

On 04/07/2023 at 03:24, Cyril Brulebois wrote:

It's fine to have an EFI partition inside a RAID array. One “just” needs
to pass --no-nvram and to register it manually. That's not something
that's achievable via d-i at the moment though (unless recent changes in
grub-installer, near the end of the bookworm release cycle) made it
possible indirectly.


Any pointer to these recent changes ?


kibi@tokyo:~/debian-installer/packages/grub-installer (master=)$ git log -p 
-Gno-nvram
→ 0007c1296f202fff8e84640d4e1737502690ca46


I expected more something about the "register it manually" part.

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Pascal Hambourg]

On 04/07/2023 at 03:24, Cyril Brulebois wrote:

Samuel Thibault  (2023-07-04):

As pointed out in #1040266, when using guided partitioning inside a
raid, partman-auto creates an EFI partition there, and then grub-install
fails because it can't register it. This error could also happen if a
user creates by hand an EFI partition inside the raid by mistake. Just
like partman-efi warns when no EFI partition is defined, it should also
warn when an EFI partition is defined inside a raid or lvm (thus
actually unreachable from EFI).


FWIW a long ime ago I submitted a MR to allow EFI partitions only on 
disk labels which support the ESP flag (i.e. not the "loop" disk label 
used on LVM logical volumes and unpartitoned RAID arrays). It won't 
prevent an EFI partition in a partitioned RAID array, but AFAIK manual 
partitioning does not allow to create a partition table on a RAID array.



It's fine to have an EFI partition inside a RAID array. One “just” needs
to pass --no-nvram and to register it manually. That's not something
that's achievable via d-i at the moment though (unless recent changes in
grub-installer, near the end of the bookworm release cycle) made it
possible indirectly.


Any pointer to these recent changes ?

Bug#815187: Bug debian-Installer (bookworm): Installation grub fails without error message

[Pascal Hambourg]

On 27/06/2023 at 17:55, CJ Kucera wrote:


Just popping in to say that I've run into this exact problem on Debian
12 (Bookworm) as well.  I'm installing onto a system with two drives in
a raid1 config, so the installer presents a dialog with these choices
for installing GRUB:

 - Enter device manually
 - /dev/sda  (ata-VBOX_HARDDISK_VBcb2c038a-37db3d41)
 - /dev/sdb  (ata-VBOX_HARDDISK_VB9084690a-b32386db)

If choose "Enter device manually", and type in "/dev/sda", I get two
statuses shown on the next progress bar:

 1. running "grub-install /dev/sda"
 2. running "update-grub"

If I instead pick the dropdown entry for "/dev/sda", the installer skips
the "grub-install" step and goes right to "update-grub," which leaves the
freshly-installed OS in an unbootable state.

Interestingly, if I *manually* type in /dev/sda (which installs GRUB
properly) and then go back and re-install GRUB using the dropdown entry,
from that point forward the dropdown selection works and I get the
"grub-install" step properly.


This looks like bug #1035096 (patch available but came too late for 
bookworm release).

Bug#1037261: Bookworm - OOM-killer called before partition hard drives

[Pascal Hambourg]

On 25/06/2023 at 17:44, Ben Hutchings wrote:

On Fri, 2023-06-09 at 17:16 +0200, Anael Mobilia wrote:

Jun  9 14:50:43 kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE
Jun  9 14:50:43 kernel: [0.00] signal: max sigframe size: 1440
Jun  9 14:50:43 kernel: [0.00] BIOS-provided physical RAM map:
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x-0x0009fbff] usable
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x000f-0x000f] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x0010-0x3ffc9fff] usable
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0x3ffca000-0x3fff] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
Jun  9 14:50:43 kernel: [0.00] BIOS-e820: [mem 
0xfffc-0x] reserved


That's 1 GiB RAM, not 32 GiB.  Still, that should be more than enough
for installation.


But:

Jun  9 14:50:43 kernel: [0.123770] Memory: 338616K/1047968K available (14342K kernel code, 2324K rwdata, 8728K rodata, 2772K init, 17436K bss, 171224K reserved, 0K cma-reserved) 


How come available memory is so low ? Or am I misunderstanding ?

Bug#993068:

[Pascal Terjan]

FYI, I had the same problem (not on Debian) and tracked it to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4dad599b8b5d1ffc5ef12a2edb13d15d537202ba

Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

[Pascal Hambourg]

On 21/06/2023 at 03:55, tomas k wrote:

On Fri, 2023-06-09 at 13:32 +0200, Pascal Hambourg wrote:


With /usr-merged layout (default since buster IIRC), a separate /usr
must be mounted before running any program. The initramfs mounts a
separate /usr before running init, but the installer rescue mode did not
before running a shell. This feature has been added to bookworm
installer (rescue 1.86) but not backported to bullseye installer
AFAIK.


That explains it. I can't open the root patitiion, because rescue
system says it's not a root partition until I try what is actually
/usr. But, I have finally given up separate /usr, and just lumped it in
with the pile. But in bookworm it should work?


Bookworm's installer rescue mode should detect a separate /usr in 
/etc/fstab and offer to mount it before running a shell in the root 
partition, like previous versions already did with a separate /boot or 
/boot/efi. Other improvements include properly unmounting nested 
filesystems (e.g. /boot/efi then /boot).

Bug#1037391: debian-installer: xorg configuration fails when booting d-i graphical mode on netinst iso under virtualbox

[Pascal Hambourg]

On 12/06/2023 at 12:51, Jonathan Carter wrote:


When booting the debian-12.0.0-amd64-netinst.iso image in VirtualBox
(7.0.8-dfsg-2 from unstable/contrib) under UEFI and selecting
the Graphical Install (default) option, Xorg fails to start,
apparently due to being incorrectly configured or incorrectly detecting
the hardware.


According to someone experiencing the same issue, a workaround is to set 
para-virtualization to legacy in virtualbox settings.

Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

[Pascal Hambourg]

On 09/06/2023 at 01:27, tomas k wrote:


I'm on a different system than the problem one. For years I have had to boot 
knoppix
and run a chroot to change a password I've forgotten, because I use a separate 
usr partition,
and rescue thinks it's the root directory. Butr without etc it's not going to 
work.


Rescue mode does not "think" anything about any partition. It is up to 
the user to select the proper root partition, although I admit this 
might be improved by providing more information about available 
partitions to the user.


With /usr-merged layout (default since buster IIRC), a separate /usr 
must be mounted before running any program. The initramfs mounts a 
separate /usr before running init, but the installer rescue mode did not 
before running a shell. This feature has been added to bookworm 
installer (rescue 1.86) but not backported to bullseye installer AFAIK.



My suggestion is, if a user wants a separate usr, to place a hidden flag file 
in root, the presence of which
informs the system to mount THAT partition AND look in /etc/fstab, and mount 
usr.


/etc/fstab already exists in the root filesystem, so no need to create a 
flag file.

Bug#651280: don't allocate all available disk space in standard LVM partioning scheme

[Pascal Hambourg]

On 31/05/2023 at 19:50, James Addison wrote:

On Wed, 31 May 2023 at 16:38, Cyril Brulebois  wrote:

James Addison  (2023-05-31):


The disk space required for e2scrub[1] snapshots is 256MiB and the
default allocation for LVM (encrypted or unecrypted) in the bookworm
RC4 installer is 100% (same as originally reported here in Y2011).


That's the default setting. Users who want to use e2scrub can tweak it.


The volume group allocation size can be adjusted during an interactive
install session, yep - the operator is prompted to input a size, and
the default value is the full extent of the block device (my
terminology may be a bit wonky).


Bug#651280 submitter's intent was to reserve enough free space in the VG 
for future LV creation or growth. This has been addressed in Buster 
installer so I thought this very old bug should be closed.


IMO reserving free space for e2scrub is a separate topic. Periodic 
execution of e2scrub is disabled by default in /etc/e2scrub.conf, so it 
is not unreasonable to consider that users willing to enable it should 
be aware of its requirements. However if you consider that guided 
partitioning should reserve a small amount of free space for e2scrub you 
may file a new bug report against partman-auto-lvm.



(the 256MiB requirement appears to static, though - it's a fixed size
for exactly one snapshot, I suppose)


The snapshot size is defined in /etc/e2scrub.conf. The actual required 
size must be enough to hold changes to the original LV during the check.

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 27/05/2023 at 17:08, Peter Ehlert wrote:


I suppose this use case is rather rare


I do not know how rare your use case is, but I can tell this bug has 
been around for several Debian releases. I have observed it several 
times, and I have seen several other people reporting it over time. 
However the more UEFI boot takes over from legacy BIOS boot, the more 
rare it is going to be as it affects only BIOS boot.

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

Control: tags -1 patch

On 27/05/2023 at 13:29, Peter Ehlert wrote:

On 17/05/2023 at 16:47, Peter Ehlert wrote:
On May 17, 2023 5:48:14 AM Pascal Hambourg  
wrote:


The proposed patch has not been accepted yet so is not applied to RC3.


Thanks, I was not aware of that.


If you are still willing to test it I can send you instructions.


Yes, I would like to try.

(...)

the patch works perfectly. no glitches or "odd" behavior

the resulting GRUB menu has the newly installed rc2 at the top as 
default, and the other three systems below that. They all boot properly.


Thank you for taking the time to test the patch and provide feedback.

Unfortunately I guess it is too late for inclusion in Bookworm's initial 
release. Maybe in the next point release.


Meanwhile, the workaround is to enter the boot device manually.

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 26/05/2023 at 15:29, Peter Ehlert wrote:


On 5/17/23 10:14, Pascal Hambourg wrote:


1. Copy the attached patched grub-installer onto a second USB drive 
formatted with FAT, ext* or any filesystem type the installer can read.


2. Start the installer (expert install recommended).

3. Between the steps "Load installer components from installation 
media" and "Install the GRUB boot loader", switch to a shell with 
Ctrl+Alt+F2.


4. Connect and mount the second USB drive seen as /dev/sdXY :
# mount -r /dev/sdXY /mnt


I am unable to get it to mount

using blkid I see the second USB as /dev/sdf1 with the label I gave it 
"grub-installer"


however running # mount -r /dev/sdf1 /mnt
says
mount: mounting /dev/sdf1 on /mnt failed: Invalid argument


What filesystem is it ?

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 17/05/2023 at 16:47, Peter Ehlert wrote:

On May 17, 2023 5:48:14 AM Pascal Hambourg  wrote:


The proposed patch has not been accepted yet so is not applied to RC3.


Thanks, I was not aware of that.


If you are still willing to test it I can send you instructions.


Yes, I would like to try.
Instructions need to be simple. This is obviously new to me.


1. Copy the attached patched grub-installer onto a second USB drive 
formatted with FAT, ext* or any filesystem type the installer can read.


2. Start the installer (expert install recommended).

3. Between the steps "Load installer components from installation media" 
and "Install the GRUB boot loader", switch to a shell with Ctrl+Alt+F2.


4. Connect and mount the second USB drive seen as /dev/sdXY :
# mount -r /dev/sdXY /mnt

5. Copy the file (check the executable permission is preserved):
# cp /mnt/grub-installer /usr/bin/grub-installer

6. Unmount and disconnect the USB drive:
# umount /mnt

7. Switch back to the installer with Alt+F1 if text or Alt+F5 if 
graphic, and resume the installation.#! /bin/sh

# export DEBCONF_DEBUG=5
set -e
. /usr/share/debconf/confmodule
#set -x

if [ "$1" ]; then
ROOT="$1"
chroot=chroot
else
ROOT=
chroot=
fi

. /usr/share/grub-installer/functions.sh
. /usr/share/grub-installer/otheros.sh

newline="
"

db_capb backup

log() {
logger -t grub-installer "$@"
}

error() {
log "error: $@"
}

info() {
log "info: $@"
}

debug () {
[ -z "${DEBCONF_DEBUG}" ] || log "debug: $@"
}

ARCH="$(archdetect)"
info "architecture: $ARCH"
SUBARCH="${ARCH#*/}"

# XXX cjwatson 2019-03-25: This is all far too complicated and fragile, and
# should be replaced with in-target or similar.

# Ensure proc is mounted in all the $chroot calls;
# needed for RAID+LVM for example
initial_proc_contents="$(ls $ROOT/proc)"
if [ -z "$initial_proc_contents" ]; then
info "Mounting /proc into $ROOT"
if [ "$(udpkg --print-os)" = "kfreebsd" ]; then
mount -t linprocfs proc $ROOT/proc
elif [ "$(udpkg --print-os)" = "hurd" ]; then
mount -t proc none $ROOT/proc
else
mount -t proc proc $ROOT/proc
fi
fi

# On Linux, we need /run in the chroot to work around
# https://bugs.debian.org/918590.
if [ "$(udpkg --print-os)" = "linux" ] && [ ! -d "$ROOT/run/udev" ]; then
mount --bind /run $ROOT/run
fi

get_serial_console() {
# Get the last 'console=' entry (if none, the whole string is returned)
local defconsole="$(sed -e 's/.*\(console=[^ ]*\).*/\1/' /proc/cmdline)"
if echo "$defconsole" | grep -qe 'console=\(ttyS\|com\)'; then
echo "$defconsole"
fi
}

grub_serial_console() {
#$1=output of get_serial_console
local serconsole=${1##console=ttyS}
serconsole=${serconsole##console=com}
local unit=${serconsole%%,*}
local options=""
if echo $serconsole | grep -q ","; then
options=${serconsole##*,}
fi
local speed=$(echo "$options" | sed -e 's/^\([0-9]*\).*$/\1/')
# Take optional 1st (parity) and 2nd (word) characters after speed
options=${options##${speed}}
local parity=$(echo $options | sed 's/^\(.\?\).*$/\1/')
local word=$(echo $options | sed 's/^.\?\(.\?\).*$/\1/')
if [ -z "$speed" ]; then
speed="9600"
fi
case "$parity" in 
n) parity="--parity=no" ;;
e) parity="--parity=even" ;;
o) parity="--parity=odd" ;;
*) parity="" ;;
esac
if [ "$word" ]; then
word="--word=$word"
fi

echo serial --unit=$unit --speed=$speed $word $parity --stop=1
}

serial="$(get_serial_console)"

grub_probe () {
if [ "$is_grub_common_installed" != true ]; then
apt-install grub-common
is_grub_common_installed=true
fi
$chroot $ROOT grub-probe $@
}

# Usage: convert os_device
# Convert an OS device to the corresponding GRUB drive
convert () {
tmp_drive="$(grub_probe -d -t drive "$1")" || exit $?
if [ "$partition_offset" != 0 ]; then
tmp_part="$(echo "$tmp_drive" | sed 's%.*,\([0-9]*\)).*%\1%')"
if [ "$tmp_part" ] && [ "$tmp_part" != "$tmp_drive" ]; then
tmp_drive="$(echo "$tmp_drive" | sed 
"s%\(.*,\)[0-9]*\().*

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 17/05/2023 at 14:24, Peter Ehlert wrote:


On 5/7/23 13:18, Pascal Hambourg wrote:


Attached is a minimal patch which uses grub-installer/bootdev only 
when if was manually set by the user, and not when the bootdev was set 
by select_bootdev. I tested it with the last case. Test and feedback 
appreciated.


Identical bug in RC 3 (debian-bookworm-DI-rc3-amd64-netinst.iso)


The proposed patch has not been accepted yet so is not applied to RC3.
If you are still willing to test it I can send you instructions.


I can create a new installation-report if desired


This is not necessary, the bug report is not closed.

Bug#1034814: debian-installer: bootable flag not toggling

[Pascal Hambourg]

Control: reassign -1 partman-partitioning
Control: tags -1 patch

On 30/04/2023 at 16:22, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-30):

On 30/04/2023 at 10:16, Matt Taggart wrote:

IMO "hide the bootable option if GPT" (but maybe that is non-trivial).


It should not be too hard. I can work on a patch against
partman-partitioning if the d-i developers agree with this solution.


Trivial patch attached. Sorry for the delay, I was busy on other topics 
and forgot a bit about this one. Should I open a MR too ?



I'm happy to defer to Steve's expertise and yours on those topics.


I'm no expert on partman, so that means Steve's.From 2216090668c175fe158c6935122b60aa09474d26 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sat, 13 May 2023 12:46:18 +0200
Subject: [PATCH] Hide the "Bootable" option on GPT

On GPT, the boot flag is the same as esp and means the partition
has the EFI type, so showing the Bootable option makes no sense.
Toggling it does not work anyway.

Closes: #1034814
---
 active_partition/toggle_bootable/choices | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/active_partition/toggle_bootable/choices b/active_partition/toggle_bootable/choices
index ed8d8d2..6cfb324 100755
--- a/active_partition/toggle_bootable/choices
+++ b/active_partition/toggle_bootable/choices
@@ -7,6 +7,12 @@ id=$2
 
 cd $dev
 
+open_dialog GET_LABEL_TYPE
+read_line label_type
+close_dialog
+# on GPT, the boot flag means type ESP, so hide the boot option
+[ "$label_type" != gpt ] || exit 0
+
 valid_boot=no
 open_dialog VALID_FLAGS $id
 while { read_line flag; [ "$flag" ]; }; do
-- 
2.30.2

Bug#1029962: check-missing-firmware fails to find firmware file or package on partitioned removable media

[Pascal Hambourg]

On 12/05/2023 at 07:07, Cyril Brulebois wrote:



These subcommands are intended to be used by check-missing-firmware
from package hw-media in order to search firmware files or packages
on all available media.


This should be hw-detect, rather than hw-media. :)


Thanks for spotting this.


-   mount --bind /hd-media /media
+   mount --bind /hd-media $MNT


Since new subcommands are supposed to have run and exited before, I
would expect the default operation to require no changes at all, so the
/media → $MNT update seems weird.


As you may have noticed previously, I have a tendency to insert 
unrelated trivial "cosmetic" fixes in my patches. My purpose here was to 
consistently make use of $MNT instead of /media like in the rest of the 
code.



-   if [ "$i" = 1 ]; then
+   if [ "$i" = 1 ]; then


Another cosmetic fix...


# Give USB time to settle, make sure all devices are
# seen next time though.
sleep 5


This part could have been dropped too, even if it's very minor compared
to the question above.

Bug#1035085: Bookworm RC2 grub-installer/os-prober quirks

[Pascal Hambourg]

On 29/04/2023 at 11:22, I wrote:
1) In expert install (or low priority), the new os-prober dialog 
displayed by grub-installer lists only unsupported OS but not supported OS.

(Patch attached)

2) "efi" os-prober type is considered unsupported.
In EFI mode, os-prober detects EFI boot loaders such as Windows Boot 
Manager with type "efi". GRUB can add menu entries for these boot 
loaders so this type should be in the supported list instead of the 
unsupported list. (AFAICS it does not matter much because the supported 
OS list is used only when installing GRUB for legacy boot and not EFI 
boot.)

(Patch attached)


Another one:

If the installer was booted in EFI mode but detected existing operating 
systems already installed using "BIOS compatibility mode" and the user 
chose to not force UEFI installation, update-grub executed in the target 
chroot still behaves in EFI mode: it detects and adds entries for EFI 
boot loaders  and UEFI firmware settings to the GRUB menu and ignores 
legacy boot loaders. It should do the opposite, even though running 
update-grub again after booting the installed system will fix the GRUB menu.

(Patch attached)

I tested the 3 patches together with BIOS boot, EFI boot + installation, 
EFI boot + BIOS installation.From 5adc3dd8bf3118f40018bc3447a9f60684f1343e Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sun, 30 Apr 2023 09:06:52 +0200
Subject: [PATCH 3/3] Do no run EFI probes in target chroot if ignore_uefi is
 set

If partman-efi set /var/lib/partman/ignore_uefi, we do not want
os-prober to skip legacy probes and perform EFI probes, so create
ignore_uefi in /target. We also do not want grub 30_uefi-firmware
to probe UEFI firmware settings, so do not mount efivarfs (only
needed when installing grub-efi).
---
 debian/postinst | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/postinst b/debian/postinst
index 85714195..1ff3f851 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -43,6 +43,16 @@ mountvirtfs () {
 # target. Maybe /proc too?
 mountvirtfs proc /target/proc
 mountvirtfs sysfs /target/sys
-mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+
+if [ -e /var/lib/partman/ignore_uefi ]; then
+	# prevent os-prober EFI probes in target chroot
+	mkdir -p /target/var/lib/partman
+	touch /target/var/lib/partman/ignore_uefi
+else
+	mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+fi
 
 grub-installer /target
+
+rm -f /target/var/lib/partman/ignore_uefi
+rmdir /target/var/lib/partman 2>/dev/null || true
-- 
2.30.2

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

Control: retitle -1 GRUB not installed or installed to the wrong device

I found that grub-installer may generate a wrong bootdev value for 
grub-pc when state=2 and previous_state!=1. This may happen at least in 
the following three cases if the user selects the device in the proposed 
list:


- if the first device listed by grub-mkdevicemap is the installation 
media (/cdrom or /hd-media) or has no known partition table nor 
filesystem, GRUB may be installed to the disk containing /boot instead 
of the device selected by the user;


- if unsupported OS are detected by os-prober, bootdev may be empty and 
GRUB is not installed;


- if the user answers "no" to "Install the GRUB boot loader to your 
primary drive?", bootdev may be empty and GRUB is not installed.


It does not happen if the user chose "Enter the device manually".

The common root cause is grub-installer/bootdev being used without being 
manually set by the user even after bootdev was set by select_bootdev.


Attached is a minimal patch which uses grub-installer/bootdev only when 
if was manually set by the user, and not when the bootdev was set by 
select_bootdev. I tested it with the last case. Test and feedback 
appreciated.
From 78376e99d67b713d79553f9cdfb924c261f633d6 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sun, 7 May 2023 20:19:07 +0200
Subject: [PATCH] Fix wrong or empty bootdev value for grub-pc

grub-installer may generate a wrong bootdev value for grub-pc when
state=2 and previous_state!=1. This may happen at least in the
following three cases if the user selects the device in the proposed
list:
- if default_bootdev is the installation media (/cdrom or /hd-media)
or has no known partition table nor filesystem, bootdev will be the
disk containing /boot instead of the device selected by the user;
- if unsupported OS are detected by os-prober, bootdev will be empty;
- if the user answers "no" to "Install the GRUB boot loader to your
primary drive?", bootdev will be empty.

It does not happen if the user chose "Enter the device manually".

The common root cause is grub-installer/bootdev being used without
being set by the user even after bootdev was set by select_bootdev.
This minimal patch uses grub-installer/bootdev only after being set
by the user.
---
 grub-installer | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/grub-installer b/grub-installer
index 2f0de04d..5656af84 100755
--- a/grub-installer
+++ b/grub-installer
@@ -912,25 +912,27 @@ while : ; do
 		fi
 
 		if [ ! -e "$bootdev" ]; then
-		db_input critical grub-installer/bootdev || true
-		fi
-		if ! db_go; then
-			if [ "$q" ]; then
-state=1
+			db_input critical grub-installer/bootdev || true
+			if ! db_go; then
+if [ "$q" ]; then
+	state=1
+else
+	# back up to menu
+	db_progress STOP
+	exit 10
+fi
 			else
-# back up to menu
-db_progress STOP
-exit 10
-			fi
-		else
-			db_get grub-installer/bootdev
-			bootdev=$RET
-			if echo "$bootdev" | grep -qv '('; then
-mappedbootdev=$(mapdevfs "$bootdev") || true
-if [ -n "$mappedbootdev" ]; then
-	bootdev="$mappedbootdev"
+db_get grub-installer/bootdev
+bootdev=$RET
+if echo "$bootdev" | grep -qv '('; then
+	mappedbootdev=$(mapdevfs "$bootdev") || true
+	if [ -n "$mappedbootdev" ]; then
+		bootdev="$mappedbootdev"
+	fi
 fi
+break
 			fi
+		else
 			break
 		fi
 	else
-- 
2.30.2

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

On 04/05/2023 at 16:21, Peter Ehlert wrote:


"Install the GRUB boot loader" menu ... 6 items
Enter device manually
/dev/sda (usb-SanDisk ...
/dev/sdb (ata-WL4000G ...
/dev/sdc (ata-WDC_WD300...
/dev/sdd (ata-WDC_WD300...
/dev/sde (ata-SanDisk_SDSSDA240G_162248447811)


I selected /dev/sde and pressed the Continue button

then the GUI progress bar Installing GRUB and I see Running 
"grub-install /dev/sdd" ...


in this case sdd was the install location, sde is the drive that has a 
bios_grub flagged partition


OK, I think I managed to reproduce the issue and it shares the root 
cause with another bug I am currently chasing (GRUB is not installed at 
all). Some logic in grub-installer seems to be flawed but I still need 
to understand the original intent before I can submit a patch for both bugs.


Meanwhile, a workaround is to enter the boot device manually.

setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant 
BIOS should not care about the partition table, even less the presence 
of any kind of partition. All a BIOS should care about is the presence 
of the "boot signature" 0x55, 0xAA at the end of the boot sector.


Yes, that is from the BIOS

(...)

root@z820-3:~# grub-install /dev/sda && update-grub
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot 
Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for 
cross-disk install.


This failure has nothing to do with the above. You are trying to install 
GRUB on a GPT disk which is not the one containing /boot ("cross-disk"), 
and this requires a BIOS boot partition.

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

On 02/05/2023 at 15:21, Peter Ehlert wrote:


DI asks on which drive to install GRUB
User says disk X
DI attempts to install on Drive Y
result ... GRUB does not get installed at all


This is completely different from what I understood.

The statement "GRUB does not get installed at all" is refuted by 
/var/log/syslog which indicates clearly that GRUB was successfully 
installed on /dev/sdb:



Apr 28 23:55:51 grub-installer: info: Running chroot /target grub-install  --force 
"/dev/sdb"
(...)
Apr 28 23:56:01 grub-installer: Installation finished. No error reported.


Can you described what happened exactly ?
Were you prompted to "Install the GRUB boot loader to your primary 
drive?" ? If yes, did you answer "yes" or "no" ?
Where you then prompted to select the "Device for boot loader 
installation" ? If yes, what option did you select exactly ?


setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant BIOS 
should not care about the partition table, even less the presence of any 
kind of partition. All a BIOS should care about is the presence of the 
"boot signature" 0x55, 0xAA at the end of the boot sector.

Bug#1017887: grub-efi-amd64-signed: SecureBoot Grub-Install with Custom Bootloader ID Drops Grub into Grub Shell

[Pascal Hambourg]

(Not replying to the submitter because gmail rejects all my mails)

On Mon, 22 Aug 2022 10:58:06 +0800 Chew Kean Ho 
 wrote:


When performing a manual grub-install in a debootstrap Debian OS setup,
installing SecureBoot Grub with --bootloader-id value other than 'debian' causes
the Grub to drop into Grub Shell (failed to locate /boot/grub/grub.cfg) despite
having the UUID and root prefix values correct at /boot/EFI//grub.cfg
level.


This bug should be partially fixed since version 2.06-3~deb11u5 as a 
lucky side effect of embedding a grub.cfg into memdisk.



Exact cause is unknown (still not sure what causes the drop). The only
workaround is NOT to mess with the --bootloader-id or set --bootloader-id to
strictly 'debian' as value.


The cause is well known, see #925309. (maybe merge the two bugs ?)


An effective workaround was to copy /boot/EFI//grub.cfg into 
/boot/EFI/debian/ where GRUB expected to find it.



The same thing happens when SecureBoot is turned off at BIOS.


If secure boot is disabled, another workaround was to install GRUB 
without secure boot support, either by removing shim-signed or by 
running grub-install --no-uefi-secure-boot.

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Pascal Hambourg]

On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian 
 wrote:

On 2023-05-01, Steve McIntyre wrote:

From there, I'd love to see what you get if you run "ls" here...


"ls" from the grub prompt did not show the other disk...
...until I made the second disk bootable from libvirt!
Then grub now sees both disks, and boots fine!
So this is possibly a quirk of the way libvirt exposes boot disks.


Apparently. GRUB can only see disks exposed by the BIOS/UEFI/other 
platform firmware. There are other known situations where a given 
firmware may not expose some disks, including but not limited to:

- disks connected to a SATA controller card without a BIOS expansion ROM
- unsupported media types: USB other than the boot disk, NVMe, SD/MMC...

The UEFI firmware on an old Intel board only had EFI drivers for the 
SATA controller in IDE mode and lacked EFI drivers for AHCI and USB. It 
has been reported that more recent boards had support for NVMe only in 
EFI mode, not in legacy mode.



I ran d-i in rescue mode to get into the system, simply ran
dpkg-reconfigure grub-pc (which will run grub-install *and*
update-grub), and the system now boots again. It looks like what we're
seeing might be a limit in what's built in to the core image by
default. grub-pc is deliberately designed to build minimal images
here, to minimise the chance of the image being too large to embed.


I wonder how much this policy is still relevant for PC platforms. 
Originally the core image was designed to fit in the "post-MBR gap" 
whose typical size was 62 sectors (31 KiB) because the first partition 
used to start at sector 63. But nowadays a 1-MiB post-MBR gap has been 
the standard for many years. I do not remember when this was introduced 
in fdisk and other Linux partition editors, but Windows 7 installer had 
it. Besides, I observe that the size of the core.img built for LVM+ext4 
on my bullseye system is 34 KiB so it would not even fit in a 31-KiB 
post-MBR gap.


The minimal core image policy is even less relevant for EFI images, as 
the EFI partition size is usually several MB so a few more kB won't 
hurt. I cannot tell for other platforms.


I think that when building the i386-pc core image with support for 
storage possibly involving multiple disks (LVM, RAID, btrfs), support 
for at least both MSDOS and GPT partition schemes (other partition 
schemes are unlikely to be used on PC) could be added unconditionally to 
prevent such GRUB failure after adding a disk with a different partition 
scheme to the /boot filesystem. It would add only 2 KB to the core 
image, and it is likely that the minimal size is already above 31-KiB 
anyway when the above storage drivers are embedded. Opinions ?



Re-running grub-install /dev/vda from debian-installer rescue mode did
*not* fix the issue for me


Because there were two issues preventing GRUB from seeing the new PV:
- the disk was not exposed by libvirt BIOS
- the disk had an unsupported GPT partition scheme

grub-install fixed only the second issue. Making the disk "bootable" in 
libvirt was required to fix the first issue.



(though, now I am curious if dpkg-reconfigure
grub-pc would do anything more?)


As Steve wrote, dpkg-reconfigure also runs update-grub to rebuild 
grub.cfg. AFAIK here the only difference with the old grub.cfg is 
additional "insmod part_gpt" commands to load GPT support, but the 
module must already be embedded in the core image so this addition is 
not required.

Bug#1034814: debian-installer: bootable flag not toggling

[Pascal Hambourg]

On 30/04/2023 at 10:16, Matt Taggart wrote:

On 4/25/23 01:59, Pascal Hambourg wrote:


If this should be fixed, not sure how.
- Set/unset the "esp" flag at the same time as the "boot" flag if GPT ?
- Hide the "bootable" option if GPT
- Map the "bootable" option to the "legacy_boot" parted flag instead of
"boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag)


IMO "hide the bootable option if GPT" (but maybe that is non-trivial).


It should not be too hard. I can work on a patch against 
partman-partitioning if the d-i developers agree with this solution.

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

On 30/04/2023 at 01:47, Peter Ehlert wrote:


On 4/29/23 15:41, Pascal Hambourg wrote:

On 29/04/2023 at 16:02, Peter Ehlert wrote:


reboot gave me the Old GRUB menu, not including my new system.


What do you mean by "old GRUB menu" ? The GRUB which was previously 
installed on /dev/sdb ? 


the GRUB that was on the only disk with a bios_grub flagged partition.


Thank you for the clarification. If I understand correctly,
- the machine usually boots with some GRUB on disk X,
- you installed a new Debian system with GRUB on disk Y,
- then the machine rebooted on disk X as usual.

The Debian installer will not add the newly installed system to another 
existing OS GRUB menu; it will only add other existing OS's to the new 
installed system GRUB menu, which will be displayed only if the machine 
boots from the disk containing the new GRUB. So what you describe is 
normal behaviour.


If you want to add the newly installed system to another OS GRUB menu, 
you need to run update-grub from that other OS. If you want to boot with 
the new installed GRUB, you need to set up the BIOS to boot from the 
disk which contains it.

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

Hello Peter,

On 29/04/2023 at 16:02, Peter Ehlert wrote:


Legacy aka BIOS booting
system has 4 physical disk drives, all GPT partition tables
only one drive has a partition with bios_grub

install was on a drive without bios_grub

when install was finished, a list of drives was displayed, asking where 
to install GRUB.

the install drive was highlighted
I selected the drive with bios_grub
the display showed "installing GRUB on (...drive it was installed on...)


According to /var/log/syslog, GRUB was successfully installed on 
/dev/sdb although this drive has no BIOS boot partition:


Apr 28 23:55:51 grub-installer: info: Installing grub on '/dev/sdb'
Apr 28 23:55:51 grub-installer: info: grub-install does not support
--no-floppy
Apr 28 23:55:51 grub-installer: info: Running chroot /target
grub-install  --force "/dev/sdb"
Apr 28 23:55:51 grub-installer: Installing for i386-pc platform.
Apr 28 23:56:01 grub-installer: grub-install: warning: this GPT
partition label contains no BIOS Boot Partition; embedding won't be
possible.
Apr 28 23:56:01 grub-installer: grub-install: warning: Embedding is not
possible.  GRUB can only be installed in this setup by using
blocklists.  However, blocklists are UNRELIABLE and their use is
discouraged..
Apr 28 23:56:01 grub-installer: Installation finished. No error reported.
Apr 28 23:56:01 grub-installer: info: grub-install ran successfully


(several other OS's are on that drive if that matters)

reboot gave me the Old GRUB menu, not including my new system.


What do you mean by "old GRUB menu" ? The GRUB which was previously 
installed on /dev/sdb ? That does not seem possible according to the 
above logs. Are you sure that the machine rebooted from this disk ? 
(note that /dev/sd* naming is not stable across reboots and does not 
match BIOS disk numbering/naming)



boot from another OS:
# grub-install /dev/sde && update-grub
now my GRUB menu includes the new system


In chroot or directly from the other OS ?
Running grub-install directly from another OS just installed that other 
OS's GRUB on /dev/sde and running update-grub directly just added the 
new Debian installation to that other OS's boot menu if os-prober is 
enabled.

Bug#1035085: Bookworm RC2 grub-installer/os-prober quirks

[Pascal Hambourg]

Package: grub-installer
Version: 1.190
Severity: minor
Tags: patch

Boot method: USB stick
Image version: debian-bookworm-DI-rc2-amd64-netinst.iso
Installation type: expert install
Date: 2023-04-29

Hello,

I observed a few minor quirks while testing the new os-prober 
re-enablement feature.


1) In expert install (or low priority), the new os-prober dialog 
displayed by grub-installer lists only unsupported OS but not supported OS.

(Patch attached)

2) "efi" os-prober type is considered unsupported.
In EFI mode, os-prober detects EFI boot loaders such as Windows Boot 
Manager with type "efi". GRUB can add menu entries for these boot 
loaders so this type should be in the supported list instead of the 
unsupported list. (AFAICS it does not matter much because the supported 
OS list is used only when installing GRUB for legacy boot and not EFI boot.)

(Patch attached)

3) Changing the previous answer to "Run os-prober automatically to 
detect and boot other OSes" does not work as expected.


Steps to reproduce:

- Start a new expert install.
- At the question "Run os-prober automatically to detect and boot other 
OSes", answer "yes".

- Go back to the main menu and select "Install the GRUB boot loader" again.
- At the question "Run os-prober automatically to detect and boot other 
OSes", answer "no".


Result: changing the previous answer to "no" does nothing: 
grub2/enable_os_prober and /target/etc/default/grub are unchanged so 
os-prober will still be run.


- Start a new expert install.
- At the question "Run os-prober automatically to detect and boot other 
OSes", answer "no".

- Go back to the main menu and select "Install the GRUB boot loader" again.
- At the question "Run os-prober automatically to detect and boot other 
OSes", answer "yes".


Result: Changing the previous answer to "yes" does half the job: 
grub2/enable_os_prober is changed but /target/etc/default/grub is 
unchanged so os-prober will not be run.


IIUC, this is because
- answering "no" is a no-op;
- grub2/enable_os_prober has an effect only when /target/etc/defaut/grub 
is generated by the selected grub-* package config script when the 
package is installed (after the first time the question is asked).From c117406bf936e0fd4ff3f31916b1cd22db3f46ed Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sat, 29 Apr 2023 09:35:42 +0200
Subject: [PATCH 1/2] Add all other OS to the complete OS list, not only
 unsupported OS

---
 grub-installer | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/grub-installer b/grub-installer
index 2f0de04d..3c177c41 100755
--- a/grub-installer
+++ b/grub-installer
@@ -566,6 +566,11 @@ if [ -s /tmp/os-probed ]; then
 		IFS="$OLDIFS"
 		title=$(echo "$os" | cut -d: -f2)
 		type=$(echo "$os" | cut -d: -f4)
+		if [ -n "$other_os_list" ]; then
+			other_os_list="$other_os_list, $title"
+		else
+			other_os_list="$title"
+		fi
 		case "$type" in
 		chain)
 			: ;;
@@ -579,11 +584,6 @@ if [ -s /tmp/os-probed ]; then
 else
 	unsupported_os_list="$title"
 fi
-if [ -n "$other_os_list" ]; then
-	other_os_list="$other_os_list, $title"
-else
-	other_os_list="$title"
-fi
 continue
 			fi
 			;;
@@ -595,11 +595,6 @@ if [ -s /tmp/os-probed ]; then
 			else
 unsupported_os_list="$title"
 			fi
-			if [ -n "$other_os_list" ]; then
-other_os_list="$other_os_list, $title"
-			else
-other_os_list="$title"
-			fi
 			continue
 			;;
 		esac
-- 
2.30.2

From 005333adb8d1f57a0620cac3206aaa78b7be0136 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sat, 29 Apr 2023 09:38:58 +0200
Subject: [PATCH 2/2] Add "efi" os-prober type to the supported OS list

In EFI mode, os-prober detects EFI boot loaders such as Windows boot
manager with type "efi". grub-mkconfig can add menu entries for these
boot loaders so this type should be in the supported list.

(It does actually not matter much because the supported OS list is used
only when installing GRUB for legacy boot and not EFI boot)
---
 grub-installer | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-installer b/grub-installer
index 3c177c41..afd65a26 100755
--- a/grub-installer
+++ b/grub-installer
@@ -572,7 +572,7 @@ if [ -s /tmp/os-probed ]; then
 			other_os_list="$title"
 		fi
 		case "$type" in
-		chain)
+		chain|efi)
 			: ;;
 		linux)
 			# Check for linux systems that we don't
-- 
2.30.2

Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

Control: tags -1 patch

On 25/04/2023 at 19:55, Pascal Hambourg wrote:

Suggested fix is two-fold:

1) Call clean_method() at the beginning of 
partman-auto-lvm/autopartition-lvm, as is done in 
partman-auto/autopartition and partman-auto-crypto/autopartition-crypto. 
This should solve the issue for swap partitions but is not enough for ESPs.


Patch attached for the partman-auto-lvm part.From 1d6b590b418184d1f5b92126542f33c90dfda945 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Thu, 27 Apr 2023 08:53:05 +0200
Subject: [PATCH] Call clean_method again

The call to clean_method was lost with commit cfc6797f.
As a result, if existing swap and EFI partitions on other disks were marked
used (which is the default), swap partitions will be used (and get new UUIDs,
which is bad if they belong to another system) and any EFI partition on another
disk may be used instead of the newly created one (#1034812).

This patch fixes the issue for swap partitions but fixing the issue for EFI
partitions also requires a change in partman-efi (same as #1034208).
---
 autopartition-lvm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/autopartition-lvm b/autopartition-lvm
index e081beb..40026c3 100755
--- a/autopartition-lvm
+++ b/autopartition-lvm
@@ -5,6 +5,9 @@
 devs="$*"
 method="lvm"
 
+# Ensure we have no pre-existing partitions marked as swap and efi
+clean_method
+
 auto_lvm_prepare "$devs" $method || exit $?
 
 auto_lvm_perform || exit 1
-- 
2.30.2

Bug#1034208: Partman may use the wrong ESP partition

[Pascal Hambourg]

Control: retitle -1 Partman may use the wrong ESP partition

On 15/04/2023 at 16:34, Pascal Hambourg wrote:


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


It seems that this patch is also needed to fix #1034812 (guided 
partitioning with LVM uses the wrong ESP), in combination with another 
(trivial) patch for partman-auto-lvm.


Updating the title accordingly.

Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

Hello,

On 25/04/2023 at 01:29, Adam wrote:


I installed from a thumb drive, to another thumb drive, on a computer
that had an nvme drive that should not have been touched.  The installer
overwrote data on the nvme drive despite the target being /dev/sda. I
manually mounted the installed system (the target thumb drive) on another
computer, figured out what happened (ESP was empty) and fixed it so I could
submit a bug report from the thumb drive that failed to install properly.

This is similar to the other UEFI installation problems, but it did
not install to the MBR, and it did not install any files on the correct
ESP, thus is is a separate issue.

The smoking gun for understanding what went wrong was in /etc/fstab, where
there were two comments:

# /boot was on /dev/sda2 during installation
# /boot/efi was on /dev/nvme0n1p1 during installation


From the partition layout I assume you used guided partitioning with 
LVM (without encryption). Guided partitioning is supposed to not use any 
partitions outside the selected disk by calling clean_method() defined 
in partman-auto/lib/recipes.sh. This is what I observe with non-LVM 
schemes, but the two LVM schemes have issues. Here is a summary of my 
observations:


Guided - use the largest continuous free space
 calls clean_method() in partman-auto/autopartition
 does not run partman-efi/init.d/efi
 does not use existing EFI or swap partitions on other disks (good)

Guided - use entire disk
 calls clean_method() in partman-auto/autopartition
 does not run partman-efi/init.d/efi
 does not use existing EFI or swap partitions on other disks (good)

Guided - use entire disk and set up LVM
 does not call clean_method()
 runs partman-efi/init.d/efi
 uses existing EFI and swap partitions on other disks (bad)

Guided - use entire disk and set up encrypted LVM
 calls clean_method() in partman-auto-crypto/autopartition-crypto
 runs partman-efi/init.d/efi
 uses existing EFI partitions on other disks (bad)
 does not use existing swap partitions on other disks (good)

partman-efi/init.d/efi detects possible EFI partitions and sets method 
"efi" on them.


As you can see, the issue also affects swap partitions (and they will be 
reformatted with new UUIDs, which can be harmful if they are used by 
another system).


Note: partman-auto-lvm used to call clean_method() in lib/auto-lvm.sh 
but it was removed by commit cfc6797f6f561b87069160ba7c375c5b487b7c1e 
with code factoring.


Suggested fix is two-fold:

1) Call clean_method() at the beginning of 
partman-auto-lvm/autopartition-lvm, as is done in 
partman-auto/autopartition and partman-auto-crypto/autopartition-crypto. 
This should solve the issue for swap partitions but is not enough for ESPs.


2) In partman-efi/init.d/efi, set method "efi" only once, as is done 
with swap partitions in partman-basicfilesystems/init.d/autouse_swap.
I already submitted two patch versions for #1034208 "Partman may reset 
user's choice for ESP partitions use" as a follow-up to Steve's latest 
fixes for #834373 and #1033913.


Caveat: I don't know if these changes could have any negative impact on 
preseeded automatic partitioning.

Bug#1034814: debian-installer: bootable flag not toggling

[Pascal Hambourg]

On 25/04/2023 at 03:24, Matt Taggart wrote:


When in the partitioning and editing a partition, if I am on the 
"bootable" option and select, it does not toggle but remains "no". The 
screen flashes, bot no change. I have not yet checked what ends up in 
the partition table after the install.


Is it a GPT partition table ?

GPT is the default partition table type with EFI boot or disk size above 
2 TiB. In GPT, "boot" and "esp" parted flags are equivalent and both 
represent the "EFI system partition" type (IMO this is a big mess).


If this should be fixed, not sure how.
- Set/unset the "esp" flag at the same time as the "boot" flag if GPT ?
- Hide the "bootable" option if GPT ?
- Map the "bootable" option to the "legacy_boot" parted flag instead of 
"boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag)


Also, there is another issue with this: changing the use of an ESP 
partition to something else will not remove the boot/esp flag. This is 
annoying when you want to change it to "BIOS boot" which should have the 
"bios_grub" flag instead.

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: reassign -1 hw-detect

On 17/04/2023 at 17:52, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-17):

Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the
pipeline, and restore it when running install_firmware_pkg.


I think I'd be happy to take this patch for bookworm, as a workaround…


Here is another patch for hw-detect moving the install_firmware_pkg()
call outside the pipeline instead of playing with file descriptors.


… before considering a real/better fix after bookworm.


Feel free to pick either patch you like. Both work for me.

To be fair, I searched if other firmware packages than firmware-ipw2x00 
had a preinst script using debconf dialog which required this fix, and 
the only other one I found is firmware-ivtv which is not related with 
networking or storage.



PS: shouldn't this bug report be reassigned to hw-detect ?


Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


I've never cloned a bug report, so I'd rather leave it to a more 
experienced user.

Bug#1034535: Installer boot menu displayed in text mode when UEFI secure boot is enabled

[Pascal Hambourg]

Package: debian-installer
Severity: minor

Boot method: USB stick
Image version: debian-bookworm-DI-rc1-amd64-netinst.iso
Boot mode: UEFI

When secure boot is disabled, GRUB displays the menu in graphic mode as 
expected.

When secure boot is enabled, GRUB briefly displays error messages:

 prohibited by secure boot policy
 no video mode activated

and displays the menu in text mode.

This is caused by loadfont failing in /boot/grub/grub.cfg:

if loadfont $prefix/font.pf2 ; then
  set gfxmode=800x600
  set gfxpayload=keep
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod gfxterm
  insmod png
  terminal_output gfxterm
fi

A recent change in grub prohibits loading fonts from outside the signed 
image, so loadfont was adapted to try and load the requested font from 
the embedded memdisk first instead of $prefix.


If I understand correctly, loadfont allows two types of arguments:
- a radix, which is expanded into $prefix/fonts/.pf2
- a pathname starting with / or (

The "magic" looking up (memdisk) first instead of $prefix works only 
with a radix whereas grub.cfg uses a full pathname. Also, it tries to 
load font.pf2 whereas the embedded font file is unicode.pf2.


I tested to replace "$prefix/font.pf2" with "unicode" or 
"(memdisk)/fonts/unicode.pf2" in /boot/grub/grub.cfg and the graphical 
menu was back. Actually, if I remove the loadfont command and the 'if' 
condition, as far as I can see the graphical menu is displayed 
correctly, except the border frame replaced by "?" in the menu entry 
editor, so maybe the condition could be removed.


PS: Maybe the issue also exists in live images ? Didn't check.

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: tags -1 patch

On 07/04/2023 at 01:05, I wrote:


Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the 
pipeline, and restore it when running install_firmware_pkg.


Here is another patch for hw-detect moving the install_firmware_pkg() 
call outside the pipeline instead of playing with file descriptors.


PS: shouldn't this bug report be reassigned to hw-detect ?From 5186662ea53ff694ba3fc841f623a521c9091d54 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Mon, 17 Apr 2023 15:16:20 +0200
Subject: [PATCH] check-missing-firmware: Fix firmware license acceptance

The standard input of a command run within a pipeline is redirected,
which disrupts debconf. So move the install_firmware_pkg() call out
of the pipeline, else the debconf dialog is not displayed when the
firmware package preinst script requires a license acceptance.
---
 check-missing-firmware.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 5db0e180..5ea194d7 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -318,18 +318,32 @@ install_firmware_pkg () {
 # This does not use anna because debs can have arbitrary
 # dependencies, which anna might try to install.
 check_for_firmware() {
+	# any non-space character which is not a shell pattern meta-character * ? ! [ ]
+	# and cannot be part of a component name a-z - will do as a delimiter
+	local delim="^"
+	local list item dir fw_file fw_pkg_file component filename
+
 	echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
 	for dir in $@; do
 		# An index file might exist, mapping firmware files to firmware
 		# packages, saving us from iterating over each firmware *.deb:
 		if [ -f $dir/Contents-firmware ]; then
 			log "lookup with $dir/Contents-firmware"
+			# environment modification in a pipeline is not persistent, so use stdout
+			list=$(\
 			grep -f /tmp/grepfor $dir/Contents-firmware | while read fw_file fw_pkg_file component; do
+echo $fw_pkg_file$delim$component
+			done)
+			# do not call install_firmware_pkg() inside a pipeline because stdin is redirected,
+			# it disrupts debconf in the package preinst script if license agreement is required
+			for item in $(echo $list); do
+fw_pkg_file=${item%$delim*}
 # Don't install a package for each file it ships!
 if grep -qs "^$fw_pkg_file$" /tmp/pkginstalled 2>/dev/null; then
 	continue
 fi
 if check_deb_arch "$dir/$fw_pkg_file"; then
+	component=${item##*$delim}
 	log "installing firmware package $dir/$fw_pkg_file ($component)"
 	install_firmware_pkg "$dir/$fw_pkg_file" "$component" || true
 	echo "$fw_pkg_file" >> /tmp/pkginstalled
-- 
2.30.2

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

[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

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

[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#1034389: installation-reports: bookworm cannot install base system

[Pascal Hambourg]

Hello,

On 14/04/2023 at 15:16, Steve Witt wrote:


/var/log/syslog attached as requested.


Thank you. According to the following messages:


sd 0:0:0:0: [sda] 7700480 512-byte logical blocks: (3.94 GB/3.67 GiB)
sda: p1 size 7758432 extends beyond EOD, truncated


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.


You may try with a bigger USB drive or a smaller ISO image (e.g. netinst 
if you have a good network connection).


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