search

grml / grml-live

build system for creating a Grml (based) live system
https://grml.org/grml-live/
123 stars 39 forks source link

Booting from live systems drops into GRUB CLI #59

Closed paulmenzel closed 4 years ago

paulmenzel commented 5 years ago

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
paulmenzel commented 5 years ago

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
mika commented 5 years ago

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.

paulmenzel commented 5 years ago

On 08/29/18 11:24, Michael Prokop wrote:

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. That’s what I thought too, but Secure Boot is disabled. It could of course be a firmware bug, that this is actually not the case.

Booting the daily Debian installer image works though. It doesn’t work on a Dell XPS 13 9360 with Secure Boot enabled, so it looks unrelated to Secure Boot.

mika commented 5 years ago

Ah, thanks for adding another test case. Jepp, the Debian daily's don't support Secure Boot yet (AFAICT).

paulmenzel commented 5 years ago

Merge/pull request https://github.com/grml/grml-live/pull/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?

mika commented 5 years ago

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).

mika commented 5 years ago

I just pushed https://github.com/grml/grml-live/commit/8c2668bf55e917289d87d9f59f93763d019a32ca 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?

jkirk commented 4 years ago

This issue should be fixed by now. Closing hereby.