multipath installations generate incorrect fstab

[Dimitri John Ledkov]

multipath installations generate incorrect fstab

currently /etc/fstab is generated with `UUID= / ext4' line, which for multipath is wrong.

It should be `/dev/mapper/mpatha-part1 / ext4' line or some such.

[Ryan Harper (raharper)]

What's the bad path if we don't specify the mpath device name?

[Ryan Harper (raharper)]

the UUID is already bound to the device mapper device:

% cat fstab
UUID=50e5271d-665f-4edb-a023-e2f744679751 / ext4 defaults 0 0
UUID=5d9f777b-c102-4d8f-b4f5-56195c4ae21c /home ext4 defaults,nofail 0 0

% cat ls_al_byuuid
total 0
drwxr-xr-x 2 root root 120 Oct 8 14:37 .
drwxr-xr-x 8 root root 160 Oct 8 14:37 ..
lrwxrwxrwx 1 root root 9 Oct 8 14:37 2019-10-08-09-33-25-00 -> ../../vdc
lrwxrwxrwx 1 root root 10 Oct 8 14:37 50e5271d-665f-4edb-a023-e2f744679751 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 5d9f777b-c102-4d8f-b4f5-56195c4ae21c -> ../../dm-2
lrwxrwxrwx 1 root root 9 Oct 8 14:37 b53526d8-5027-430a-ae4b-73347b6a28a1 -> ../../vdb

% cat ls_al_byid
total 0
drwxr-xr-x 2 root root 380 Oct 8 14:37 .
drwxr-xr-x 8 root root 160 Oct 8 14:37 ..
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-name-mpath0 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-name-mpath0-part1 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-name-mpath0-part2 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-uuid-mpath-0QEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-uuid-part1-mpath-0QEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 dm-uuid-part2-mpath-0QEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../dm-2
lrwxrwxrwx 1 root root 9 Oct 8 14:37 scsi-0QEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 8 14:37 scsi-0QEMU_QEMU_HARDDISK_IPR-0_1234567890-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 scsi-0QEMU_QEMU_HARDDISK_IPR-0_1234567890-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 9 Oct 8 14:37 scsi-SQEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 8 14:37 scsi-SQEMU_QEMU_HARDDISK_IPR-0_1234567890-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 scsi-SQEMU_QEMU_HARDDISK_IPR-0_1234567890-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 9 Oct 8 14:37 virtio-output_disk.img -> ../../vdb
lrwxrwxrwx 1 root root 9 Oct 8 14:37 virtio-seed.img -> ../../vdc
lrwxrwxrwx 1 root root 10 Oct 8 14:37 wwn-0xQEMU_QEMU_HARDDISK_IPR-0_1234567890 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Oct 8 14:37 wwn-0xQEMU_QEMU_HARDDISK_IPR-0_1234567890-part1 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 8 14:37 wwn-0xQEMU_QEMU_HARDDISK_IPR-0_1234567890-part2 -> ../../dm-2

[Dimitri John Ledkov (xnox)]

Whilst it is bound to the devicemapper device, that is incorrect fstab as per ubuntu policy for how to declare root device.

Furthermore, if fstab was correctly specifying /dev/mapper/ device curtin would need not to generate unpackaged conffile /etc/default/grub.d/50-curtin-multipath.cfg with
GRUB_DEVICE=/dev/mapper/mpath0-part2
GRUB_DISABLE_LINUX_UUID=true
as those would be then automatically detected from fstab.

Whenever DM devices are used, fstab should use DM names. This affects all of: multipath, lvm, raid, luks. And may not use the filesystem UUID.

[Steve Langasek (vorlon)]

Using the UUID in the fstab is wrong because it's racy. The individual member devices appear at boot, and are exposed via udev, before the system knows that they're part of a multipath set. And if systemd winds up mounting the member instead of the mpath device, you get degraded mounts without multipath redundancy.

The /etc/fstab needs to reference a device that is *unique* to the system, will only appear once, and points to the multipath device.

I don't remember which is the right name schema to use for multipath devices in particular - the mpathN-partM names may not be guaranteed to be stable - but prior art in debian-installer for partman-multipath should illuminate; or Matt may be able to provide some guidance.

[Dimitri John Ledkov (xnox)]

we enfoce mpathN-partM names as stable, as the installer requires and copies in the mapping of WWIDs to pretty-names.

However, to be extra safe we could start using the WWID symlinked name instead.

[Dimitri John Ledkov (xnox)]

/me ponders if we should create https://wiki.ubuntu.com/FSTAB similar to https://wiki.ubuntu.com/PATH such that we have a reference cheat-sheet if and when questions like these come up.

[Rafael David Tinoco (rafaeldtinoco)]

IIRC the unique symlink for the multipathed device will be named:

/dev/disk/by-id/dm-uuid-mpath-36006016095b03a00a8b3bc647644e711

this will guarantee mount wont round-robin through same UUIDs for multiple devices.

Been there already :(

[Dimitri John Ledkov (xnox)]

And given that we have identical stock VG and LV names across all installations, imho for LVM we might want to start using by-id symlink names in /etc/fstab too, which encode unique UUID of the VG/LV or some such.

Effectively, using UUIDs of the DM devices, for the same reasons we use UUIDs of the filesystems for simple block devices.

I.e. UUID-harder, never less =)

[Michael Hudson-Doyle (mwhudson)]

I fixed this in grub recently, although only for multipath, not other uses
of device mapper. grub-mkconfig and whatever makes fstab files should be
consistent I guess...

On Thu, 10 Oct 2019, 11:25 Dimitri John Ledkov, <email address hidden>
wrote:

> And given that we have identical stock VG and LV names across all
> installations, imho for LVM we might want to start using by-id symlink
> names in /etc/fstab too, which encode unique UUID of the VG/LV or some
> such.
>
> Effectively, using UUIDs of the DM devices, for the same reasons we use
> UUIDs of the filesystems for simple block devices.
>
> I.e. UUID-harder, never less =)
>
> --
> You received this bug notification because you are subscribed to
> subiquity.
> https://bugs.launchpad.net/bugs/1847263
>
> Title:
> multipath installations generate incorrect fstab
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/1847263/+subscriptions
>

[Michael Hudson-Doyle (mwhudson)]

I think this is fixed in 20.04 now?