Bug#1034812: Bug#1041168: Installation of GRUB failed

[Christof B.]

Am 17.07.23 um 20:13 schrieb Pascal Hambourg:

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


Yes, I think so.

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#1041168: Installation of GRUB failed

[Christof B.]

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.
>
>cp /50efi.1 /lib/partman/init.d/50efi
> or
>cp /50efi.2 /lib/partman/init.d/50efi
>

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.
>
>cp /autopartition-lvm /bin/autopartition-lvm
>
> The files can be replaced after "Load installer components" and before
> "Partition disks".

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!

Cheers
Christof

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
log "$dev $id has $flag flag"
if [ "$flag" = boot ] && [ "$label_type" = gpt ]; then
efi=yes
elif [ "$flag" = esp ]; then
efi=yes
fi
done
close_dialog

if [ "$efi" = yes ]; then
# An ESP is clearly 

Bug#1041168: Installation of GRUB failed

[Christof B.]

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.


If technically feasible (if all files can be replaced at once) a tarball 
would be best.


Thanks and cheers
Christof

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

[Cyril Brulebois]

Christof B.  (2023-07-15):
> Probably this is a duplicate.
> Are there any (nightly) d-i images available to test these patches,
> because otherwise (i. e. building d-i myself) this is over my head.

Not yet. Speaking only for myself, I'm still in dire need of rest
after the whole Bookworm release marathon over the last few months,
and I haven't been able to dive into those patches just yet.

They're on my list of things to look into on the short term though,
including considering them for some point release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1041168: Installation of GRUB failed

[Christof B.]

Hi!

Am 15.07.23 um 18:35 schrieb 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.


Yes.



It looks like bug #1034812 (patches available).



Probably this is a duplicate.
Are there any (nightly) d-i images available to test these patches, 
because otherwise (i. e. building d-i myself) this is over my head.


Cheers,
Christof

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#1041168: Installation of GRUB failed

[Christof B.]

Salut Cyril,

thanks for your quick reply!

Am 15.07.23 um 14:09 schrieb Cyril Brulebois:


Thanks for sharing all those logs in advance. syslog has:

 Jul 15 11:00:47 grub-installer: grub-install: error: cannot copy 
`/usr/lib/shim/shimx64.efi.signed' to `/boot/efi/EFI/debian/shimx64.efi': No 
space left on device.

And the ESP is close to 500M, so ENOSPC is very surprising. Any chance
you could check what's inside/what filled it?


I hat a look at the disk, but the ESP partition was completely empty. I 
redid the whole installation (with the same error) to get runtime 
information about what is going on.


Et voilà - df:

Filesystem   1K-blocks  Used Available Use% Mounted on
tmpfs   391488   136391352   0% /run
devtmpfs   1933492 0   1933492   0% /dev
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /dev/.static/dev
devtmpfs   1933492 0   1933492   0% /target/dev
tmpfs   391488   136391352   0% /target/run
/dev/sdc1  3906068  1200   3904868   0% /mnt/s

Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition. I have no clue why.

For further investigation I added the lastest syslog as well.

Thanks in advance for your efforts!

Cheers,
Christof[1:0:0:0]   diskATA SAMSUNG SSD PM872D0Q
[2:0:0:0]   (5) PLDSDVD+-RW DS-8ABSHLD11
[7:0:0:0]   disktakeMS  Mem-drive EasyII1100
[0:0:0:0]   diskUSB Flash Disk  2.00


syslog.gz
Description: application/gzip
lrwxrwxrwx1 root root 9 Jul 15 12:49 
ata-PLDS_DVD+_-RW_DS-8ABSH_23HW6736395B764G9A03 -> ../../sr0
lrwxrwxrwx1 root root 9 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418 -> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part3 -> ../../sdb3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0 -> ../../sda
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part1 -> ../../sda1
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part2 -> ../../sda2
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part3 -> ../../sda3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0 -> ../../sdc
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0-part1 -> ../../sdc1
lrwxrwxrwx1 root root 9 Jul 15 13:05 wwn-0x5002538d401cb207 
-> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part3 -> ../../sdb3

Bug#1041168: Installation of GRUB failed

[Cyril Brulebois]

Hallo Christof,

Christof B.  (2023-07-15):
> Boot method: USB stick (written with usbimager), UEFI
> Image version: 
> https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso
> Date: 2023-07-15
> 
> Machine: Dell Optiplex 9020 SFF
> Partitions: see attached files hardware-summary and partman
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect media:   [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[E]
> 
> Comments/Problems:
> 
> I did a pretty minimal installation with the base system but no graphical
> environmend. I used the "Guided - use entire disk and set up encrypted LVM"
> partitioning scheme. Then I chose the harddisk sdb instead of USB stick sda.
> Installing GRUB (more precisely: configuring shim-signed:amd64) failed
> with a message complaining that GRUB could not be installed on dummy
> (execution of "grub install dummy" failed).

Thanks for sharing all those logs in advance. syslog has:

Jul 15 11:00:47 grub-installer: grub-install: error: cannot copy 
`/usr/lib/shim/shimx64.efi.signed' to `/boot/efi/EFI/debian/shimx64.efi': No 
space left on device.

And the ESP is close to 500M, so ENOSPC is very surprising. Any chance
you could check what's inside/what filled it?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1041168: Installation of GRUB failed

[Christof B.]

Package: installation-reports

Boot method: USB stick (written with usbimager), UEFI
Image version: 
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso

Date: 2023-07-15

Machine: Dell Optiplex 9020 SFF
Partitions: see attached files hardware-summary and partman

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[E]

Comments/Problems:

I did a pretty minimal installation with the base system but no graphical 
environmend. I used the "Guided - use entire disk and set up encrypted 
LVM" partitioning scheme. Then I chose the harddisk sdb instead of USB 
stick sda.

Installing GRUB (more precisely: configuring shim-signed:amd64) failed
with a message complaining that GRUB could not be installed on dummy 
(execution of "grub install dummy" failed).


Conclusion: I was unable to install GRUB using the Debian installer. That 
left me with a non bootable installation.


Thanks for looking into this,
Christof

hardware-summary.gz
Description: application/gzip
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230607"
X_INSTALLATION_MEDIUM=netboot


partman.gz
Description: application/gzip


status.gz
Description: application/gzip


syslog.gz
Description: application/gzip