1

I run Debian Testing on a Dell Latitude E5450.

I created a USB environment with debootstrap following the instructions posted here, and here. As per those instructions (and others), I mounted my running /dev/{pts}, /proc and /sys inside the appropriate directory, installed the lattest kernel, systemd and the lot. The last step is to configure GRUB by first installing it on the EFI partition of my USB stick (formated to FAT32 and with a boot flag) from inside the chroot environment (with the appropriate parameters such as the EFI directory), and then running update-grub; again, and I cannot stress this enough, I ran this command from inside the chroot environment of the system created via debootstrap.

The problem with that is that it detects my running system on dev/sda2, which is my main partition. So when I try to boot this USB using virt-manager, nothing happens; my laptop doesn't detect it as a bootable device when I go to the "One-time boot menu" (pressing F12 while the Dell logo is displaying), so I enter the setup and set the grubx64.efi inside the USB stick as a boot option, then reboot. Upon doing that, unsurprisingly, it wants to boot the kernel in my laptop, not the one in the USB drive.

This is what happens:

# grub-install --boot-directory=/boot/ --efi-directory=/boot/efi --recheck --removable /dev/sdb1
Installing for x86_64-efi platform.
Installation finished. No error reported.
# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-3-amd64
Found initrd image: /boot/initrd.img-5.10.0-3-amd64
Found Debian GNU/Linux bullseye/sid on /dev/sda2
done

This is the grub.cfg file I get. In line 106 I do see a menu entry with the kernel in the USB, but this doesn't show up when trying to boot from it; again, the one-time boot menu doesn't recognise the first partition (FAT fs, EFI) as a bootable device. If I don't mount the /dev directory into the tree with the new environment, I cannot run grub-install (this makes a lot of sense, but I thought it was worth mentioning).

I don't know what to do because Google doesn't return anything useful, other than more instructions on how to do everything I already did. Firstly, it is very frustrating not to have my USB EFI partition recognised by the boot menu. Secondly, I would really like to know what command, with what parameters, and with what directories mounted inside the chroot tree I have to run in order for GRUB to recognise the kernel inside the USB stick, not the one in my laptop.

Below are screencaps of how the USB sticks show in GParted and in fdisk.

Gparted fdisk

Improve this question
6
  • Is the partitioning of the USB stick MBR or GPT type? If MBR, the FAT32 partition with the UEFI bootloader should use partition type 0xef, not the standard type for generic FAT32 partitions.
    – telcoM
    Feb 22, 2021 at 15:49
  • @telcoM As far as I remember it is a GPT type, but I don't recall just now the partition type of the EFI one. Thank you for the information, I'll check it. :)
    – mathbekunkus
    Feb 22, 2021 at 17:03
  • 1
    The EFI System partition's type on GPT-partitioned disk should be C12A7328-F81F-11D2-BA4B-00A0C93EC93B, which is an obnoxious thing to remember (I looked it up). If you partitioned it with (G)Parted or a tool based on it, setting the "boot" flag on a GPT partitioned disk actually means setting the partition type GUID to exactly that.
    – telcoM
    Feb 22, 2021 at 17:16
  • @telcoM I added screencaps of how the stick looks in GParted and on fdisk (just realized I could've pasted that dump). How does one find out that indeed the partition type is what you wrote above? lsblk doesn't return that, and the entries in fstab are the devices IDs. Thanks! :)
    – mathbekunkus
    Feb 23, 2021 at 1:53
  • 1
    The fdisk -l output says Disklabel type: gpt and it indicates the type as "EFI System", which is a human-friendly name of that type GUID I mentioned. Note that GParted indicates flags boot, esp: on GPT partitioning, those both always appear together as GParted only has "flags" to identify the various partition types, which is a bit poor fit for GPT partitioning.
    – telcoM
    Feb 23, 2021 at 11:42

1 Answer 1

Reset to default
0

It all worked fine after installing GRUB from inside the chroot environment; grub-install detected the kernel on my primary partition, but it doesn't necessarily boot from it; the entry still shows in the menu, and I'd like to know how to delete it. Booting in QEMU only required adding the parameter --bios /usr/share/qemu/OVMF.fd. Thank you all for your comments!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .