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

Hallo Christof,

Christof B. <debian@jamesie.de> (2023-07-15):

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,

Salut Cyril,

thanks for your quick reply!

Am 15.07.23 um 14:09 schrieb Cyril Brulebois:

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       136    391352   0% /run
devtmpfs               1933492         0   1933492   0% /dev
/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
/dev/mapper/debian--vg-root
                      120469224   1379448 112924068   1% /dev/.static/dev
devtmpfs               1933492         0   1933492   0% /target/dev
tmpfs                   391488       136    391352   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

Hello,
(...)

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

It looks like bug #1034812 (patches available).
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034812>

Hi!

Am 15.07.23 um 18:35 schrieb Pascal Hambourg:

Yes.

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

Christof B. <debian@jamesie.de> (2023-07-15):

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,

If you are willing to test, I can provide patched files which replace
the original ones in a running d-i.

Am 15.07.23 um 21:07 schrieb Pascal Hambourg:

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

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 <source path>/50efi.1 /lib/partman/init.d/50efi
or
   cp <source path>/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 <source path>/autopartition-lvm /bin/autopartition-lvm

The files can be replaced after "Load installer components" and before
"Partition disks".

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

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

Am 17.07.23 um 20:13 schrieb Pascal Hambourg:

Yes, I think so.