mjhjmtu

discussion - we have redhat linux machines and my question is about the UUID configuration in /etc/fstab file , and in which cases UUID risk the OS

as I understand we MUST NOT use UUID in /etc/fstab if using software RAID1.

Why? Because the RAID volume itself and the first element of the mirror will appear to have the same file system UUID. If the mirror breaks or for any other reason the md device isn't started at boot, the system will mount any random underlying disk instead, clobbering your mirror.

so my question is

what are the RAID levels ( numbers ) that we must not is UUID in fstab ?

info about the raid level - https://en.wikipedia.org/wiki/Standard_RAID_levels

We'll just go ahead and test this on ArchLinux and mdadm. But first of all this shouldn't matter for partition based arrays because then the member partitions have their own UUIDs so this would in theory only appply to whole disk members.

TL;DR: This isn't a real problem even with old metadata blocks. It might have been a bug in older software I don't know. But it doesn't affect a modern ArchLinux.

#uname -sr
Linux 4.14.7-1-ARCH

#modprobe raid1

#mdadm --create --verbose /dev/md0 --metadata 0.9 --level=mirror --raid-devices=2 /dev/sdb /dev/sdd
mdadm: size set to 102336K
mdadm: array /dev/md0 started.

#cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd[1] sdb[0]
102336 blocks [2/2] [UU]

unused devices: <none>

#mdadm --detail --scan >> /etc/mdadm.conf

fdisk /dev/md0
lsblk /dev/md0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 100M 0 disk
└─md0 9:0 0 100M 0 raid1
 └─md0p1 259:0 0 98.9M 0 md 
sdd 8:48 0 100M 0 disk
└─md0 9:0 0 100M 0 raid1
 └─md0p1 259:0 0 98.9M 0 md 
md0 8:0 0 100M 0 raid1
└─sda2 8:2 0 98.9M 0 md

mdstat -> [UU]

#blkid /dev/md0
/dev/md0: PTUUID="d49d8666-e580-8244-8c82-2bc325157e66" PTTYPE="gpt"
#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
#blkid /dev/sdb
/dev/sdb: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

#mkfs.ext4 /dev/md0p1
mke2fs 1.43.7 (16-Oct-2017)
creating filesystem with 101292 1k blocks and 25376 inodes
Filesystem UUID: 652bcf77-fe47-416e-952c-bbOa76a78407
Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done 

#mount /dev/md0p1 /mnt

#lsblk -o NAME,UUID,MOUNTPOINT /dev/sdb /dev/sdd
NAME UUID MOUNTPOINT
sdb b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
 └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt
sdd b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
 └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt

So far so good. Not only does this correctly identify the member devices as raid devices but there are two partition level UUIDs that match. In fact these as part of the same container device md0 and lists the same mount point. It DOES NOT list any normal partition containers on sdd or sdb. Note that the md0 device itself does NOT have a UUID. Only its members have the UUID and its actually the same UUID.

#echo "UUID=652bcf77-fe47-416e-952c-bbOa76a78407 /mnt ext4 rw,relatime,data=ordered 0 2" >> /etc/fstab
umount /mnt
mount /mnt
cd /mnt
fallocate -l 50MiB data

mdstat -> [UU]

Noting that we asked for the file system UUID of the raid members now lets try running the system without mdadm running.

#cd
#umount /mnt
#mdadm --stop /dev/md0
mdadm: stopped /dev/md0
#lsblk /dev/sdb /dev/sdd
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 100M 0 disk
sdd 8:48 0 100M 0 disk

Now the system thinks these are correctly raw disks because they have no partition table and so are not containers. However if we ask about what they are:

#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

It's still a linux_raid_member and if we try to mount it:

#mount /dev/sdd /mnt
mount /mnt: unknown filesystem type "linux raid member"

How about:

#mount /mnt
mount: /mnt can't find UUID=652bcf77-fe47-416e-952c-bbOa76a78407

And that makes sense because sdd is NOT a container and therefor there are no file systems that are probed. However if I run:

#mdadm --assemble --scan && mount /mnt
mdadm: /dev/md0 has been started with 2 drives.

And if I stop it again and remove mdadm.conf:

#umount /mnt && mdadm --stop /dev/md0
#modprobe -r raid1
#rm /etc/mdadm.conf
#modprobe raid1
#mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 2 drives.

Dually note that my configuration for md0 device name is no longer taking effect and its being created at /dev/md/0 automatically. Now lets reboot and see what systemd/Linux does with fstab.

#mdadm --stop /dev/md/0
mdadm: stopped /dev/md/0
#systemctl reboot


#dmesg | grep md0
[ 14.550231] md/raidl:md0: active with 2 out of 2 mirrors
[ 14.550261] md0: detected capacity change from 0 to 104792064
[ 14.836905] md0: p1
[ 16.909057] EXT4-fs (md0p1): mounted filesystem with ordered data mode. Opts: data=ordered

#lsblk /dev/md0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
md0 9:0 0 100M 0 raidl 
└─md0p1 259:0 0 98.9M 0 md /mnt

And again with raid=noautodetect kernel parameter as this would also simulate versions of Linux that would not autodetect all raids and in all superblock/metadata versions etc. Yet still it mounts the raid because I asked for it in fstab and it force loaded mod raid1. So lets try again with it black listed with modprobe.blacklist=raid1:

Okay so whats going on?:

So linux knows its a raid type device even if it has no raid support. When trying to mount it, it correctly detects its a raid device and when using fstab it doesn't find the UUID despite it being in the file systems super block.

And again! With no information in fstab or mdadm.

#mount /dev/sdd /mnt
mount: /mnt: unknown filesystem type "linux_raid_member".

I think the gist of this is not only is Linux's probing is smart. Besides that using tools like fdisk warm that there is extra information stuffed in the partition table area. You would have to be trying really hard to make this mistake your file system UUID for one of the member disks.

as per earlier answers you can use UUID in any RAID "level" with no concern, either by

• not using mdadm metadata v0.9 or v1.0 (instead use v1.1 or 1.2)


• use the UUID associated with the MD array, instead of the filesystem. Of course this requires reconfiguration if you move the FS off the software raid and onto a different device, but you probably don't have reason to be concerned about that.

in which cases it will be problematic to configure UUID in fstab