Adding pquota to /etc/fstab for rootfs requires adding dracut rootflags argument

[dustymabe]

On a Fedora (27,26) Atomic Host system I specify pquota as a filesystem option in anaconda and this properly gets placed in the fstab:

[root@cloudhost ~]# cat /etc/fstab | grep root
/dev/mapper/atomicos-root /                       xfs     pquota          0 0

but the option does not actually get applied when mounting the root filesystem:

[root@cloudhost ~]# cat /proc/self/mountinfo  | grep -P 'sysroot '
66 40 253:0 / /sysroot rw,relatime shared:3 - xfs /dev/mapper/atomicos-root rw,seclabel,attr2,inode64,noquota

version used:

[root@cloudhost ~]# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora/27/x86_64/atomic-host
                   Version: 27.7 (2017-10-11 12:40:10)
                    Commit: 64db5bc7d82da05a9221c8e4eb484aaf318095376c104db2aff2b62508228237
              GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4

[dustymabe]

note this is needed for https://pagure.io/atomic-wg/issue/352

[rhatdan]

I think you need to add a kernel option to /etc/grub2.cfg

rootflags=pquota

This is what my f26 machine looks like.
linux16 /vmlinuz-4.13.4-200.fc26.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8 rootflags=pquota

[cgwalters]

Ah yes, dracut already supports rootflags as an alternative to embedding /etc/fstab in the initramfs. That's exactly what we need, thanks @rhatdan !

@dustymabe So for cloud images we can just set this in the bootloader flags for kickstart, but we also need to change the product image to do this (and only do it if the partitioning is the default? Or maybe change anaconda to do it if it finds pquota in the mount options for /)?

[dustymabe]

rootflags seems like a nice workaround. I still think there is an issue here where what is in fstab is not reflected in what gets mounted. Shouldn't that get addressed?

[cgwalters]

Yes...but we'd need some mechanism to know to update the bootloader configuration whenever /etc/fstab changes. Perhaps we could just have XFS-specific logic that lives in libostree that updates rootflags on the kernel cmdline whenever it sees one in /etc/fstab. On a traditional system this happens indirectly because dracut is run client side, which happens whenever the kernel changes. I don't think we'd want to go to client-side initramfs generation by default just for this; it undercuts an important part of the "image" approach of ostree.

(But of course rpm-ostree initramfs --enable exists, it's just not the default)

[cgwalters]

Or TL;DR I think we could do something to make it Just Work but it'd be rather nontrivial. One reason to do that work though is to support people disabling or changing the option - they'd need to know to find the option in two places too.

[dustymabe]

we should probably try to match what users expect. The best approach would be to make whatever is in fstab be the source of truth.

if we can't have that without a lot of pain and suffering then we could have something that checks and reports to the user when there is an issue (i.e. out of sync rootflags and fstab). This could show up in the rpm-ostree status output.

[cgwalters]

Another huge wrinkle in this is that I suspect (but haven't tested) that if one takes the FAH ostree commit and deploys it on a filesystem without pquota, it will probably break. Offhand it looks like ext4 supports it...but btrfs doesn't.

[cgwalters]

(Er, ignore the last comment, I was thinking about this wrong, it's just a kernel arg)

[jlebon]

systemd also ships an initrd-parse-etc service to reload configs from the sysroot after it's mounted in the initrd to take into account this sort of thing. Not sure if fstab falls under that domain, but worth investigating.

Also with #2170, it's much cheaper now to inject configuration into the initrd. There's work missing though in Anaconda to actually leverage it.

That said, this is less relevant now with the move towards fstab-less systems. Tentatively closing.