Booting from live systems drops into GRUB CLI
paulmenzel opened this issue · comments
With the daily Sid full image from today (MD5 sum b61c426af66ea5fdbd9d8becec29af8b), dd’ing that to a 64 GB USB 3 device results in an image dropping in a GRUB CLI with the partition with the GRUB configuration not visible.
The type of the first partition does not seem to get set.
$ sudo fdisk /dev/sdb
Welcome to fdisk (util-linux 2.31.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 58.4 GiB, 62746787840 bytes, 122552320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1754a5eb
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 1396735 1396736 682M 0 Empty
/dev/sdb2 580 8771 8192 4M ef EFI (FAT-12/16/32)
Command (m for help):
GNU parted also only detects one partition.
$ sudo parted /dev/sdb print
Model: SanDisk Extreme (scsi)
Disk /dev/sdb: 62.7GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
2 297kB 4491kB 4194kB primary esp
It looks to me like a firmware bug, as the image works fine on other (Dell) devices.
The Ubuntu 18.04.1 ISO dd’ed to the same USB device works though, so it might be useful to find out what they do differently. (It can also be, that the Dell OptiPlex 5055 firmware has special adaptations for Ubuntu, as they ship with Ubuntu.)
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 58.4 GiB, 62746787840 bytes, 122552320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x663eb4c4
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 3815135 3815136 1.8G 0 Empty
/dev/sdb2 3737268 3741939 4672 2.3M ef EFI (FAT-12/16/32)
The type is also empty, so it shouldn’t be a problem.
Here are the hashes of the files in the ESP.
$ md5sum /run/media/pmenzel/Ubuntu\ 18.04.1\ LTS\ amd64/efi/boot/*
6e94c3d33194c89bd327bfaa5871e294 /run/media/pmenzel/Ubuntu 18.04.1 LTS amd64/efi/boot/bootx64.efi
b5396a73432683098774e9bc14ff5503 /run/media/pmenzel/Ubuntu 18.04.1 LTS amd64/efi/boot/grubx64.efi
Thanks for reporting this, this is interesting. I also observed a similar issue with being dropped into GRUB CLI with enabled Secure Boot on Lenovo x280 laptops, as soon as Secure Boot is disabled it works fine. Needs further investigation.
Ah, thanks for adding another test case. Jepp, the Debian daily's don't support Secure Boot yet (AFAICT).
Merge/pull request #60 did not help. I still get dropped into the GRUB CLI.
ls in GRUB only shows (hd0) and (hd0,msdos2). Doing configfile (hd0,msdos2)/EFI/ubuntu/grub.cfg, the Grml configuration is correctly loaded.
So, a GRUB issue, that the configuration file is not found? Does the configuration file need to be signed or something like this?
Thanks for the update. What does probe output (and what's its exit-code?) when executed on the GRUB CLI? If it's not failing then I'm afraid we're ending up in the wrong branch inside templates/secureboot/grub.cfg (also see templates/boot/grub/grmlenv.cfg).
I just pushed 8c2668b which works for me in virtualbox, qemu/kvm with recent OVFM versions and I'll provide some further ISO on real™ hardware at some customers. Would be interesting to know whether the daily ISOs as of 2018-10-18 or later work for you?
This issue should be fixed by now. Closing hereby.