Discoverable Partitions Specification

fstab

Refreshing my memory with the inner workings of fstab I stumbled on a sentence in the Arch Wiki

GPT partition automounting

On a GPT partitioned disk it is possible to omit / , /home , /srv and swap partitions from /etc/fstab by partitioning according to the Discoverable Partitions Specification.

https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

TL;DR: Let's automatically discover, mount and enable the root partition, /home, /srv and the swap partitions based on GUID Partition Tables (GPT)!

The GUID Partition Table (GPT) is mandatory on EFI systems. It allows identification of partition types with GUIDs. So far Linux has made little use of this, and mostly just defined one GUID for file system/data partitions and another one for swap partitions. With this specification, we introduce additional partition types to enable automatic discovery of partitions and their intended mountpoint.

Reading this made me realize - this is what Windows are doing to evaluate partitions on a system.

That seems quite useful - but it would confuse the h*** out of an experienced user seeing it implemented for the first time.

It has been implemented in system from 211 - and I wonder why it is not in broader use?

Have you used it?

Are you aware of any systemd based distribution using this?

If - say Calamares implemented using the partition type guid - and skipped the corresponding fstab entries - can you image the :confounded: :confused: rising for this.

I can and I am laughing while writing this :rofl:

4 Likes

Personally, I'd rather rely on my customized /etc/fstab than on systemd for telling my system what partitions I want mounted, and where in the tree I want them mounted. :wink:

Besides, my partitioning layout is a lot more elaborate ─ and much more in line with the UNIX philosophy ─ than what you commonly find among GNU/Linux users these days. :wink:

Sorted list below... :arrow_down:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       511M  280K  511M   1% /boot/efi
/dev/sda2       488M  120M  333M  27% /boot
/dev/sda3       1.0G   40M  878M   5% /
/dev/sda4        22G  8.5G   13G  40% /usr
/dev/sda5       512M   17M  435M   4% /usr/local
/dev/sda6       2.0G   17M  1.8G   1% /opt
/dev/sda8       400G   60G  340G  15% /srv
/dev/sda9       450G  1.5G  447G   1% /home
/dev/sda11       20G 1016M   19G   6% /var
dev             3.9G     0  3.9G   0% /dev
run             3.9G   19M  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs           3.9G   43M  3.8G   2% /tmp
tmpfs           3.9G  171M  3.7G   5% /dev/shm
tmpfs           785M   24K  785M   1% /run/user/1000
Notes
  • /dev/sda7 is missing from that list, because that was my original /var, but it quickly proved too small after a few updates. So I created /dev/sda11 instead as a replacement ─ I always leave a little extra room at the end of the drive, for cases like this.

  • /dev/sda10 is missing from that list because it's my main swap partition. I have a secondary (and larger) swap partition on a spinning rust HDD, but I haven't had to use that yet so far, and it's not even in /etc/fstab.

5 Likes

IIRC we have seen system booting with no fstab at all.
I knew systemd can auto-detect partitions, but didn't know it was only GPT.

I never tested by intention.
I may try (with my new system-on-stick) later.

3 Likes

I am indeed gonna do it.


I can confirm it works.

I used the gnome disks utility to verify the partition type guid was set for the laptops partition.

The standard three (3) - efi and swap has the guid but the root partition just had the guid for data partition so I changed that to Linux Root type.

Commented all three lines in fstab - saved and rebooted.

Not a hickup - just plain normal boot.

3 Likes

Can you confirm your /boot (not /boot/efi) is in a separate partition and formatted as fat32?
If it is not (/boot not separate and not fat32), confirm also you are using that OS grub to boot and you have nothing in /etc/fstab and boots 'normally'.

And furthermore, if using that OS grub, confirm the menuentry is using the kernel (eg. vmlinuz-5.2-xxxx and initramfs-5.-xxxx.img) and not using efi files (core.efi or grubx64.efi).

It is my understanding from systemd bootloader interface and its specifications which this "DiscoverablePartitions" depends on would require systemd-boot or bootctl which in turn require /boot to be $esp and in fat32.

Would appreciate your further input.
Thanks.

1 Like

The test system has not been installed with this in mind - but fstab has been commented out of curiosity for the mentioned partition guids.

My boot is not a separate partition - it exist on root / which is formatted with ext4

Default Manjaro generated grub - with kernel entries - I did not rebuild grub after changing fstab (just a mention as it wouldn't change anything).

/etc/fstab -> https://pastebin.com/Uu5mfxkD
/boot/grub/grub.cfg -> https://pastebin.com/58MRE3Hu

Not using systemd boot but default Manjaro grub (no longer Fedora patched)

On bootloader installation on efi system - it seems necessary to mount the $esp

grub-install --target=x86_64-efi --efi-directory= esp --bootloader-id=GRUB

According to a note on Arch Wiki Grub - it is possible to install the bootloader using a temporary mount and adding a --boot-directory=/mnt/boot to the above command.

At runtime the $esp is not mounted as can be seen here and the folder /boot/efi/ is empty.

lsblk -la -> https://pastebin.com/VFewxUNj
lsblk -lo NAME,MOUNTPOINT,UUID,PARTUUID,PARTTYPE -> https://pastebin.com/58a1WPqw

1 Like

[OT]

This looks amazing!
My partition scheme is a humble /, /home, swap. I just wonder what /srv is for. In mine there are two empty folders /srv/ftp and /srv/http.

1 Like

/srv is for the data, scripts etc which a system shares through services - e.g. ftp, www, nfs, smb ...

3 Likes

Great!
Thank you @linux-aarhus!

cheers,
:m:

2 Likes

If you are interested in reading more - see this - which also has links to arch wiki

2 Likes

In my case, it also contains a directory /srv/mmedia ─ which contains my music collection, my movies and my TV/web series ─ as well as a directory /srv/backups, which contains an archived backup of the entire site at one of the two domains I administer. We needed to restore this backup a while ago due to corruption in the SQL database at that site. :wink:

1 Like

Thank you so much!

So in practice, apart from the use case mentioned above by @linux-aarhus and in the link you posted, /srv can contain any "regular" mount point for other partitions containing whatever data?

1 Like

You can use what ever structure you find suitable.

The Filesystem Hiearchy Standard - is a guideline so systems have a homogeneus structure for where files are located.

That said - if you use the definitions you will never be in doubt of what a folder is actually used for.

Examples:

  • /media/usb -> a removable drive - Manjaro default is /run/media/$USER
  • /data/local/music -> a folder containing music shared among users on the system
  • /data/nfs/music -> a mountpoint for music shared from other host
  • /srv/nfs/music -> a bind mount for sharing the above music folder on nfs
  • /mnt -> a temporary mount point for - e.g. copying music files from a remote location
2 Likes

Yes, of course. According to the FHS, /srv is intended for shareable data offered up by services on the system, but its internal organization is entirely site-specific and it may very well act as a mountpoint for other, nested filesystems.

So for instance, if you want /srv/ftp on a different filesystem, then you can do this. As long as everything's mounted into the tree when the machine is running normally, it's all accessible. You could even mount a NAS there.

Likewise, with /usr on a separate filesystem, you can mount /usr read-only during normal system operation ─ as I do ─ for increased stability and security, and as such, you can even export it over the network via NFS for other machines on the LAN, so that after updating your main machine, the other machines on the LAN will have the updated /usr available to them as well.

Caveat emptor: I don't know whether this has changed in the meantime with the official bump from 18.0.4 to 18.1.0, but in the 18.0.4 configuration, having /usr on a separate partition required that you changed the configuration of /etc/mkinitcpio.conf ─ it needed to have three hooks added to it, i.e. [usr], [fsck] and [shutdown] ─ and that you rebuilt the initramfs for every kernel you have installed. Otherwise the system wouldn't boot beyond the rescue shell in the initramfs, because it couldn't find systemd ─ a :chicken: & :egg: situation. :wink:

1 Like

Thanks for the further elaboration. Based on your feedback, I tried similarly and commented out my entries in fstab. And yes, it indeed booted.

But as I expect, swap is not enabled.
Don't need /boot/efi as grub entry does not need to specify if kernels in boot is specified instead.
But the surprising thing (for me) is that /root, not specified in fstab, works out okay. Though it is mounted as relatime and not noatime.

[pop@Dec ~]$ swapon -s
[pop@Dec ~]$ findmnt /
TARGET SOURCE     FSTYPE OPTIONS
/      /dev/sda12 ext4   rw,relatime,stripe=8191
[pop@Dec ~]$ findmnt /boot/efi
[pop@Dec ~]$ 


Thanks again for your testing.

ps: I changed back to the original fstab after this testing. :slightly_smiling_face:

2 Likes

@linux-aarhus, @Aragorn

Thank you so much for such great info! It all is much more clear to me now.
I am truly grateful for you taking your time and sharing of your wealth of knowledge.

cheers,
:m:

1 Like

The root partition is pointed out by $esp core grub, I suppose. Not a surprise it is found.

1 Like

Yes, the root partition is referred by grub.cfg in its UUID (root=UUID=xxxxxxxx). Correct.
But from my recollection (in years gone by) of fstab, if the root is not specified in fstab, the OS will not boot (even if specified in grub.cfg). Hence my surprise.

Do you have any linux OS with systemd version older than 211?
Try that (fstab no root entry) and let us know if that boots.

2 Likes

I did too :slight_smile: the relatime id part of the defaults for mounting and we have not defaults specified since we have no fstab so not surprised.

My swap worked - I think the PARTTYPE argument is responsible for that.

The swap specific guid is probably not set in your swap partitions properties.

No problem - I am happy to comply :tophat:

It probably won't. The specification referenced in OP states only systemd >= 211 will automatically recognize special guids - there is also a do's and dont's for systems implementing it.

1 Like

:+1:

Good point. And correct too. I have this swap in the old msdos disk. Nice.
So now I know (from you) that swap (in gpt) works too if not specified in fstab.
And /boot/efi (in gpt) is not mounted if there's no entry in fstab.

Heh heh.. I now know who to call for a guinea pig. :laughing:

Cheers, take care.

2 Likes

Forum kindly sponsored by