[solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

dawnofman · 2022-03-31 23:31:14

I guess ... no; but wanting to be sure anyway.

Would like to:

whatever=wwn-0x5000cca01318e82c-part2 / btrfs subvol=/@,defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 1

instead of current:

PARTUUID=85fff86f-c275-a347-b053-4baca4a05b65 / btrfs subvol=/@,defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 1

There is no mention of ID in fstab man page but since I keep hearing over-and-over that the linux man pages are often outdated (I wonder if ...):

The first field (fs_spec).
This field describes the block special device, remote filesystem or filesystem image for loop device to be mounted or swap file or swap partition to be enabled.
For ordinary mounts, it will hold (a link to) a block special device node (as created by mknod(2)) for the device to be mounted, like /dev/cdrom or /dev/sdb7. For NFS mounts, this field is <host>:<dir>, e.g., knuth.aeb.nl:/. For filesystems with no storage, any string can be used, and will show up in df(1) output, for example. Typical usage is proc for procfs; mem, none, or tmpfs for tmpfs. Other special filesystems, like udev and sysfs, are typically not listed in fstab.
LABEL=<label> or UUID=<uuid> may be given instead of a device name. This is the recommended method, as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed. For example, 'LABEL=Boot' or 'UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'. (Use a filesystem-specific tool like e2label(8), xfs_admin(8), or fatlabel(8) to set LABELs on filesystems).
It’s also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).
See mount(8), blkid(8) or lsblk(8) for more details about device identifiers.
Note that mount(8) uses UUIDs as strings. The string representation of the UUID should be based on lower case characters. But when specifying the volume ID of FAT or NTFS file systems upper case characters are used (e.g UUID="A40D-85E7" or UUID="61DB7756DB7779B3").

My drives:

someone:somewhere:~ $ cat /etc/fstab ### excerpt

UUID=a7340c61-9c4d-4d30-ac61-0111d68b7ef9 / btrfs subvol=/@,defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 1

someone:somewhere:~ $ ll /dev/disk/by-partuuid/

lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 0fe622cf-010d-9140-975e-ec8105978077 -> ../../sda3
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 76abfd88-5c6f-3b4b-8a10-b5fc3011cdbe -> ../../sda1
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 85fff86f-c275-a347-b053-4baca4a05b65 -> ../../sda2
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 c299dddc-3333-4621-b9a3-6bca7db625c6 -> ../../sda4

someone:somewhere:~ $ ll /dev/disk/by-id/

lrwxrwxrwx 1 root root  9 2022-03-28 13:12:17 scsi-35000cca01318e82c -> ../../sda
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 scsi-35000cca01318e82c-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 scsi-35000cca01318e82c-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 scsi-35000cca01318e82c-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 scsi-35000cca01318e82c-part4 -> ../../sda4
lrwxrwxrwx 1 root root  9 2022-03-28 13:12:17 wwn-0x5000cca01318e82c -> ../../sda
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 wwn-0x5000cca01318e82c-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 wwn-0x5000cca01318e82c-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 wwn-0x5000cca01318e82c-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 2022-03-28 13:12:17 wwn-0x5000cca01318e82c-part4 -> ../../sda4

Last edited by dawnofman (2022-04-01 16:19:18)

Zod · 2022-03-31 23:37:19

If you were to try it, what's the worst that could happen?

dawnofman · 2022-03-31 23:40:06

Zod wrote:

If you were to try it, what's the worst that could happen?

Unexpected and ... superb answer

I guess this is the spirit of arch anyway.

frostschutz · 2022-04-01 00:01:11

man mount has it so it might probably work

seth · 2022-04-01 06:58:27

ID=id
Hardware block device ID as generated by udevd. This identifier is usually based on WWN (unique storage identifier) and assigned by the hardware manufacturer.
See ls /dev/disk/by-id for more details, this directory and running udevd is required.
This identifier is not recommended for generic use as the identifier is not strictly defined and it depends on udev, udev rules and hardware.

dawnofman · 2022-04-01 16:18:35

Long-story-short: I'll be keeping those pesky partition UUIDs:

seth wrote:

This identifier is not recommended for generic use as the identifier is not strictly defined and it depends on udev, udev rules and hardware.

That I've seen on man mount yesterday as someone pointed me to this.

That the ID depends on hardware it is exactly what I was looking for: the WWNs are printed on the drive labels so I will never confuse/misplace the drives, and, since my partition layouts are always the same and in the same order the only thing I need to do is to add the -part# suffixes to the IDs.

What stopped me to doing this is the udevd dependency that should be placed on /etc/mkinitcpio,conf hooks.

I even forgot that the entries on loader on the EFI partition will not have access to these IDs so placing them in FSTAB and not in the EFI misses the point. For me it will be either one approach or the other but not a mix.

Thanks for your reply.

Arch Linux

#1 2022-03-31 23:31:14

[solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

#2 2022-03-31 23:37:19

Re: [solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

#3 2022-03-31 23:40:06

Re: [solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

#4 2022-04-01 00:01:11

Re: [solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

#5 2022-04-01 06:58:27

Re: [solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

#6 2022-04-01 16:18:35

Re: [solved] Any chance FSTAB can handle wwn-*-part# instead of PARTUUID ?

Board footer