After building a debootstick uefi/lvm image and succesfully booting using update-grub renders it unbootable

[anon99]

It complains with errors from grub-probe about not finding the LVM volume. The newly generated /boot/grub/grub.cfg also lacks the lines inserted when built to do with LVM and hints and rootfs setup. It looks like the rootfs issue was intended to be addressed with the contents of file /boot/efi/EFI/BOOT/grub-dbstck-blah.cfg built by configure_grub_uefi() in scripts/create-image/target/pc/grub referenced by BOOTX64.efi in that same directory. The image boots fine its just gets messed up if update-grub is ever used. It looks like somehow the grub-dbstck-blah.cfg file is somehow supposed to be referenced by update-grub but nothing in etc/default/grub or /etc/grub.d/ refers into /boot/efi/ The error about the lvm volume comes from grub-probe -v -d /dev/mapper/DBSTCK-blah-ROOT-FS -t fs grub-probe: info: drive = -1. grub-core/kern/disk.c:281: Opening lvmid/gjpv7A-AkVo-9rZ1-qSLh-DHod-R267-9IP89E/ZY5Ae6-Jc3W-d3yP-bLdc-0ZRP-C2gc-sxYQdE' failed. grub-core/kern/disk.c:295: Closinglvmid/gjpv7A-AkVo-9rZ1-qSLh-DHod-R267-9IP89E/ZY5Ae6-Jc3W-d3yP-bLdc-0ZRP-C2gc-sxYQdE'. grub-probe: error: disk `lvmid/gjpv7A-AkVo-9rZ1-qSLh-DHod-R267-9IP89E/ZY5Ae6-Jc3W-d3yP-bLdc-0ZRP-C2gc-sxYQdE' not found. grub-probe -V grub-probe (GRUB) 2.04-1ubuntu26.13 root@blah:~# ls /boot/efi/EFI/BOOT/ BOOTX64.efi grub-dbstck-7af3388e.cfg root@blah:~# cat /boot/efi/EFI/BOOT/grub-dbstck-7af3388e.cfg search --set rootfs --fs-uuid 1fe71eb0-f92c-4e63-a38a-a35d81a85a3f configfile ($rootfs)/boot/grub/grub.cfg

The referenced lvmid and fs-uuid do appear accurate.

[eduble]

Hi, Can you indicate which debootstick and target OS version version you are using?

debootstick should generate images that can be booted on both UEFI and BIOS machines, without any sort of reconfiguration. For instance, you can use the image on a BIOS machine first, for a while, apply kernel security updates, etc., and then boot the same USB drive on an UEFI machine. This should work. update-grub is called by the installation scripts, so it is surprising that you found a problem running it yourself.

background: debian-based OS do not allow to install both the UEFI and BIOS version of grub (package conflict). Thus current version of debootstick (master branch) uses the following trick. Only the BIOS version of grub is installed on the OS. However, a standalone UEFI image is generated and put in the EFI partition. This standalone UEFI image embeds a script whose purpose is to find the grub.cfg file which is maintained by the BIOS grub installation and run it. Thus when the kernel is updated for instance, package installation scripts call update-grub, which update the grub.cfg file, which will update both UEFI and BIOS boot modes. In branch secure-boot (not well tested and not yet applied to master), this changed. The OS embeds both UEFI and BIOS grub packages, avoiding the package conflict by not installing the top-level grub-efi package. With this setup the standalone UEFI image trick is no longer needed. And since UEFI boot procedure is managed in a more standard way, this method allows to handle secure-boot.

[anon99]

Your tip with a few changes to get 4096 sectors working (which I somehow need to appraise you of) and Ubuntu 20.05 x86_64. Looks like the grub-pc/grub-efi is at the root of the update-grub issue. I saw the script you mentioned. I'll go look at secure-boot and maybe try that. I don't "think" the issue relates to 4096 sectors and would reproduce on 512 its just that 4096 forces efi, its the LVM part that upsets finding the rootfs, without that it wouldnt be so painfully difficult, just using a uuid...

[eduble]

I am quite busy these days but I can probably look at it on monday. If you want to check whether it works without LVM, you can use the --disk-layout option and replace LVM volumes with regular partitions. LVM is mostly useful when live migrating the OS from the USB device to the disk (i.e. using the --system-type installer option). If you are not using this option, LVM is not mandatory.

[eduble]

I have been working on this but could not reproduce your issue. I did a few more updates on top of branch secure-boot, because it will be pushed to master soon. Those latest updates are pushed to a new branch dev (see https://github.com/drakkar-lig/debootstick/network), and I suggest that you test from this dev branch. It also includes 4K compatibility updates.

Regarding your setup with 4K disks, the setup I have tested the most is the one of the wiki (obviously with KVM since I have no 4K-disks to test with): https://github.com/drakkar-lig/debootstick/wiki/kvm#simulating-disks-with-non-default-sector-size I generate the debootstick image without the --sector-size option, but with --system-type installer. If you flash this image on a USB dongle, the OS migrates on first boot to the internal disk of the machine. This is the purpose of the --system-type installer feature. Since USB dongles usually have 512-bytes sectors, default sector size is fine. And the fact the internal disk has a different sector size should not be a problem. Could you try this setup on the new dev branch?

[anon99]

I looked thru the dev branch and read your comments again and I'll have to try it out. My use case is to build an image, copy it to a 4k disk and boot it. As the disk is larger than expected the resize is triggered. All that works at present, but I will retry with dev. The resulting bootable disk has a few quirks as I pointed out with update-grub. I'll gather some data as requested and reply.

[eduble]

My use case is to build an image, copy it to a 4k disk and boot it.

I believe this is a perfect match for the --system-type installer option. You flash a USB device instead of the target disk, you boot the target machine on it, and the OS automatically migrates from the USB device to the target disk.

But maybe you are relying on another system for the image installation? How do you perform the copy of the image to the 4K disk, currently?