You are not logged in.

Pages: 1

#1 2018-11-15 11:00:54

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 13,319

[solved] EFI system - use GPT or MBR partioning

Sometime next week I hope to receive my new threadripper system.
This will be my first EFI system.

It will have a 256 GB nvme2 SSD and a 512 GB sata-ssd for data (accessed through bind mounts) .
The limitations of MBR partition tables are no problem for me.

I intensely dislike automounting

If I partition the drives with gpt, I'll need to disable or workaround the https://www.freedesktop.orgwiki/Specifi … tionsSpec/ and systemd-gpt-auto-generator .
For / , /home , /srv this should be possible, swap partitions are harder (but could be replaced by swapfiles).
There's however one partition that's much harder to prevent being automounted : the EFI system partition .

Using MBR partioned disks with an efi bootloader (syslinux preferred) appears to solve the automounting problem.

https://wiki.archlinux.org/index.php/EF … oned_disks indicates that the EFI system partition can be put on an MBR partioned disk .
Does anyone have experience with such a setup ?

Last edited by Lone_Wolf (2018-12-04 17:51:21)

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#2 2018-11-15 11:18:31

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: [solved] EFI system - use GPT or MBR partioning

The UEFI spec doesn't cover booting from a MBR drive. Your specific motherboard may support this as an additional feature but it is board/firmware specific.

No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#3 2018-11-15 11:52:32

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 13,319

Re: [solved] EFI system - use GPT or MBR partioning

If an MBR partition has an OSType field of 0xEF (i.e., UEFI System Partition), then the firmware
must add the UEFI System Partition GUID to the handle for the MBR partition using
InstallProtocolInterface(). This allows drivers and applications, including OS loaders, to
easily search for handles that represent UEFI System Partitions.

UEFI 2.7 errata A , Section 5.2 suggests supporting ESP on MBR is mandatory for uefi firmware

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#4 2018-11-29 05:21:53

afader
Member
Registered: 2013-09-12
Posts: 176

Re: [solved] EFI system - use GPT or MBR partioning

Use REFInd http://www.rodsbooks.com/refind

Offline

#5 2018-11-29 08:44:35

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: [solved] EFI system - use GPT or MBR partioning

All motherboards that I have seen support booting in UEFI mode from MBR partitions; although I am unsure if this is in the spec. You can as well boot with GPT partitions in BIOS mode (easy with syslinux). Windows support GPT only in UEFI mode and MBR only in Bios mode but this is a limitation of Windows. Many people mistake what is possible with what Windows allows you to do, hence the numerous confusing posts on the web about this.

Anyway, using MBR to prevent automounting seems odd. What Desktop do you use? XFCE does not automount by default. You can configure it if you want it (open Thunar -> Preference -> Advanced -> Configure the management of removable drives). A Google search mentioning the Desktop will most probably point you to the solution. After only a few seconds, I found this for Gnome: https://access.redhat.com/solutions/20107

Update: My post only concerned removable media. You can easily disable automounting of the EFI (and other) partition by putting an entry in /etc/fstab like this (note the noauto option); this is what I do.

UUID=<UUID OF EFI PARTITION> /mnt/efi vfat noauto 0 0

I am unsure you can disable the automounter entirely without breaking the system. There is also a flag that you can set in individual GPT partitions to prevent automounting them (gdisk /dev/sda -> x -> a -> type the partition number -> see boot flag nr 63). But I am unsure this is respected by systemd.

Last edited by olive (2018-11-29 09:27:06)

Offline

#6 2018-11-29 09:56:24

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 13,319

Re: [solved] EFI system - use GPT or MBR partioning

I use LXQT / Openbox and don't have pcmanfm-qt installed, so no automounting from the DE/WM .
Preventing automounting on userland isn't hard, but there's automounting early in the boot process that's much harder to block.


I'll definitely use fstab, but it won't stop systemd-gtp-auto-generator.
Check it's man page, it runs way before fstab is processed.

Masking the generator through a symlink in /etc has some effect, but is still not enough.

man systemd.generator wrote:

Directory paths for generator output differ by priority: .../generator.early has priority higher than the admin configuration in /etc

generator.early is triggered by stuff in /run/systemd/system-generators/* .
Any generator can put things there.

TL;DR :
ensuring gpt-auto-generator isn't run at all even when you have gpt partitioned drives while using archlinux stock systemd package is hard.

The new pc arrived late last evening, so I can start trying out things soon now.
I'll definitely look into REfind as bootloader.

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#7 2018-11-29 10:03:58

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,490

Re: [solved] EFI system - use GPT or MBR partioning

@Lone_Wolf. I am not an expert of systemd but correct me if I am wrong. My understanding is that systemd-gpt-auto-generator does not mount the partitions by itself, it only discovers them to allow automounting them later. Disabling EFI automounting via an fstab entry definitively works for me.

I have not made extensive testing, but I would grep `systemctl list-units` and see what I could mask. For example, I see a swap.target.

Offline

#8 2018-11-29 10:58:53

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 13,319

Re: [solved] EFI system - use GPT or MBR partioning

Also, on systems where the units are explicitly configured (for example, listed in fstab(5)), the units this generator creates are overridden, but additional implicit dependencies might be created.

Even if the created units are not mounted until later, the additional implicit dependencies are unwanted (by me).

masking is a bad substitute for a decent enable/disable method using access rights.
I try to avoid it.

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#9 2018-11-29 13:21:09

respiranto
Member
Registered: 2015-05-15
Posts: 479
Website

Re: [solved] EFI system - use GPT or MBR partioning

Automounting is based on Parition GUIDs, so (for everything except the EFI partition) you could just use UIDs that are not automounted, e.g. the one gdisk references to as Linux filesystem (8300).  That's the one I always used on GPT for Linux partitions.

Also, from systemd-gpt-auto-generator(8):

Note that this generator has no effect on non-GPT systems, or
where the directories under the mount points are already
non-empty.

Hence, as a workaround, you could place a dummy file into e.g. /boot (where the EFI partition would be automounted), assuming its empty.


But it's probably easier not to use GPT at all.  Unfotunately I do not have any experience on this.

Offline

#10 2018-12-04 17:50:40

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 13,319

Re: [solved] EFI system - use GPT or MBR partioning

I checked how arch installation iso combines mbr/bios and uefi boot.
It uses exactly the same method i was considering :
boot the ESP from an MBR partioned disk
Configure the bootloader to start whatever is in /boot on the root partition

I now have a system without gpt drives (so systemd-gpt-auto-generator is irrelevant) with full uefi support.
Thank you all for your input.

$ fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 970 EVO 250GB               
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: 0x47430e07

Device         Boot     Start       End   Sectors  Size Id Type
/dev/nvme0n1p1           2048 159385599 159383552   76G 83 Linux
/dev/nvme0n1p2      159385600 484444159 325058560  155G 83 Linux
/dev/nvme0n1p3      484444160 488397167   3953008  1.9G ef EFI (FAT-12/16/32)
$ 
$ ls -l /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root    5  4 dec 15:06 aDefaultSetupConfig-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root   14  4 dec 15:06 AmdAcpiVar-79941ecd-ed36-49d0-8124-e4c31ac75cd4
-rw-r--r-- 1 root root  136  4 dec 15:06 AMD_PBS_SETUP-a339d746-f678-49b3-9fc7-54ce0f9df226
-rw-r--r-- 1 root root   12  4 dec 15:06 AMD_RAID-fe26a894-d199-47d4-8afa-070e3d54ba86
-rw-r--r-- 1 root root  449  4 dec 15:06 AmdSetup-3a997502-647a-4c82-998e-52ef9486a247
-rw-r--r-- 1 root root    8  4 dec 15:06 ApSyncFlagNv-ad3f6761-f0a3-46c8-a4cb-19b70ffdb305
-rw-r--r-- 1 root root    5  4 dec 15:06 ASR_TIMERSMI-2781600e-9df9-4ef8-a5a4-66501ae55c41
-rw-r--r-- 1 root root 1333  4 dec 15:06 ASR_USER_DEF04-8f132913-6907-4192-a227-6cbcd7a50e6c
-rw-r--r-- 1 root root   46  4 dec 15:06 ASR_USER_DEF_NAME04-8f132913-6907-4192-a227-6cbcd7a50e6c
-rw-r--r-- 1 root root   13  4 dec 15:06 ASR_USER_DEF_VER-8f132913-6907-4192-a227-6cbcd7a50e6c
-rw-r--r-- 1 root root    5  4 dec 15:06 ASR_USER_DEF_VER-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    5  4 dec 15:06 AuditMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  154  4 dec 15:06 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6  4 dec 15:06 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8  4 dec 15:06 BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6  4 dec 15:06 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   72  4 dec 15:06 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   72  4 dec 15:06 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40  4 dec 15:06 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40  4 dec 15:06 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5  4 dec 15:06 CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root 3147  4 dec 15:06 dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 3728  4 dec 15:06 dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6  4 dec 15:06 DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53
-rw-r--r-- 1 root root    5  4 dec 15:06 DeployedMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5  4 dec 15:06 DeploymentModeNv-97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6
-rw-r--r-- 1 root root 1284  4 dec 15:06 DmiArray-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   20  4 dec 15:06 DmiVar0200020700-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root  100  4 dec 15:06 DRAM-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root   40  4 dec 15:06 ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40  4 dec 15:06 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8  4 dec 15:06 FPDT_Volatile-01368881-c4ad-4b1d-b631-d57a8ec8db6b
-rw-r--r-- 1 root root    5  4 dec 15:06 GoodNightLed-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root   12  4 dec 15:06 HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
-rw-r--r-- 1 root root 1564  4 dec 15:06 KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_ATPSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_EntRevokeSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_RvkSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_SiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_SkuSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8  4 dec 15:06 Kernel_WinSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    5  4 dec 15:06 LoadSetupDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   43  4 dec 15:06 MacAddrVar-8f132913-6907-4192-a227-6cbcd7a50e6c
-rw-r--r-- 1 root root    6  4 dec 15:06 MaximumTableSize-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root    5  4 dec 15:06 MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
-rw-r--r-- 1 root root    5  4 dec 15:06 MemoryOverwriteRequestControlLock-bb983ccf-151d-40e1-a07b-4a17be168292
-rw-r--r-- 1 root root    8  4 dec 15:06 MonotonicCounter-01368881-c4ad-4b1d-b631-d57a8ec8db6b
-rw-r--r-- 1 root root   28  4 dec 15:06 OA3MSDMvariable-01368881-c4ad-4b1d-b631-d57a8ec8db6b
-rw-r--r-- 1 root root   12  4 dec 15:06 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  643  4 dec 15:06 PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   10  4 dec 15:06 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   54  4 dec 15:06 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    7  4 dec 15:06 PNP0303_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
-rw-r--r-- 1 root root   13  4 dec 15:06 PNP0303_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
-rw-r--r-- 1 root root    7  4 dec 15:06 PNP0F03_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
-rw-r--r-- 1 root root   13  4 dec 15:06 PNP0F03_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
-rw-r--r-- 1 root root  102  4 dec 15:06 PreviousBoot-36d08fa7-cf0b-42f5-8f14-68df73ed3740
-rw-r--r-- 1 root root    5  4 dec 15:06 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8  4 dec 15:06 SetUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65
-rw-r--r-- 1 root root    5  4 dec 15:06 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  132  4 dec 15:06 SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   12  4 dec 15:06 SmbiosEntryPointTable-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   12  4 dec 15:06 SmbiosScratchBuffer-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   12  4 dec 15:06 SmbiosV3EntryPointTable-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   34  4 dec 15:06 StageChk-8f132913-6907-4192-a227-6cbcd7a50e6c
-rw-r--r-- 1 root root    6  4 dec 15:06 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5  4 dec 15:06 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   68  4 dec 15:06 WriteOnceStatus-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root    6  4 dec 15:06 XhciDID-a7e92950-4ec9-4502-8576-f851308f8c18
$

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

Pages: 1

Board footer

Powered by FluxBB