bootctl does not support installation on a dos/mbr partitioned disk

[floppym]

I have a very strange Dell laptop with a UEFI firmware which does not support GUID partition tables (GPT). It does support running EFI binaries, and it will detect an ESP on an MBR-style disk (a partition with type id 0xEF).

When I attempt to install systemd-boot using bootctl, it complains that my /boot file system does not reside on a GPT partitoned disk.

systemd-boot works just fine on this system if I manually copy the binary to the ESP.

cp /usr/lib/systemd/boot/efi/systemd-bootx64.efi /boot/EFI/BOOT/BOOTX64.EFI

[kaysievers]

We support only GPT formatted disks and so far have no intention to add support for legacy setups like MBR. For simplicity reasons, the use of systemd-boot is very limited in its options and the focus is entirely on current technology.

[poettering]

My guess is that EFI firmware that is so old that it doesn't support GPT is something we should be very careful to support with bootctl, given that it is likely create more problems all over the place...

[floppym]

I understand not wanting to support every permutation of the UEFI spec. No worries.

[johannbg]

@floppym
Since late 2013 the company that dictates and decide (MS$ ) which version of the UEFI spec manufactures has ship to be compliant with their OS releases ( which at that time was 2.0 today it's most likely 2.3.1 due to secure boot ) has refused to install itself if the computer has been booted in UEFI mode and MBR partition has been detected ( users dont get option to select MBR if that boot mode is UEFI ) so it's consumers have literally been forced to either (re)format the drive to be GPT or going through the hoops of booting into bios and switch from UEFI to legacy BIOS-compatibility ( and visa versa for UEFI support ) and disable uefi secure boot ( if available ) then you can install/ use MBR but you will be also just be booting using the legacy mode ( not UEFI ) so bottom line there is no point in supporting both in bootctl since manufactures probably they themselves expect other OS to follow M$ lead ( detect which bios boot mode is in use and act accordingly ) and or they are coding specifically in accordance to M$ default behaviour ( which might not be surprising ).

Anyway there is a firmware bug in the wild where BIOSes and EFIs require that at least one hard disk have at least one MBR partition that's marked as bootable/active to boot. Since the protective MBR's single EFI GPT (0xEE) partition is not normally flagged in this way, the affected firmware won't boot from GPT disk ( you can install using GPT partitioning in any *nix distribution but you wont be able to boot which fails with "BootDevice not found" ) so you might need to flag it as such, to be able to use GPT with that firmware ( parted /dev/sd disk_set pmbr_boot on I believe ) and that might be the underlying root cause for your problem. It would be good to know if you try this if things work for you or not. ( as in you can use GPT and bootctl works accordingly afterwards )

[floppym]

@johannbg Thanks I'll give it a try. The disk won't even appear in my EFI file browser though, so I'm not sure that's the issue.