Bad attributes written in fstab for xfs filesystems

Bug reports
1

I’m having an issue with my XFS filesystem entries being overwritten in “/etc/fstab”.

I am running AlmaLinux 10

I use UUIDs to define my xfs filesystems as I need to lock down them to the correct partition. These are being overwritten by just the path name, such as “/dev/sda”.

The second problem is that non-xfs attributes are being written, and this seems to be disabling the quota support.

My original fstab entry

UUID=f733e851-d155-4b83-a705-6916595efb79 /home xfs defaults,uquota,gquota,pquota,noatime 0 0

is being changed to

/dev/sda /home xfs defaults,uquota,gquota,pquota,noatime,attr2,inode64,usrquota,grpquota,prjquota 0 0

I then see error messages in the console -

May  1 07:35:48 eric systemd-fstab-generator: Quota was requested for /dev/sda, but not supported, ignoring: xfs
May  1 07:36:43 eric systemd-fstab-generator: Quota was requested for /dev/mapper/almalinux-root, but not supported, ignoring: xfs

Is there a way to exclude fstab from being updated?

2

What setup are you using that would cause partitions to float? Genuine usage of device rather than UUID is for failover purposes. UUIDs inhibit failover if the device changes. UUIDs are useful for USB or other attached storage in which the enumeration order isn’t guaranteed.

Benign. See RHEL #169955.

3

I am building under Proxmox 9 VE and I did see the device names change from boot to boot.

Maybe it’s a one-off, but at least with UUID I know I won’t experience that issue. I would hate for this to happen in production, and it seem that respecting the UUIDs is a much more secure way to go.

4

Slipped a change upstream that’ll preserve UUID/partition scheme based upon detection going forward :+1:.

upcp will bring that codebase current; upcp -b filesystem/make-mounts confirms its usage.

5

Excellent! Thanks for that.