changes to fstab not effective
Hello, I'm having this problem on a MicroOS Desktop install, but I think it may be due to something not desktop-specific, and that's why I'm posting here. What I'm doing is changing the line of fstab associated to the / filesystem. However, if I reboot and check how the fs is mounted, it seems that the old configuration is still in place and effective. It's not a problem about modifying fstab itself, or it retaining the changes, as the file is indeed updated (e.g., I can also add lines relative to new mounts, and they work. So, basically, I've put this in fstab: UUID=66a3c92a-6044-43b3-973d-1973c281bd73 / btrfs ro,noatime,compress=zstd:3,ssd,space_cache,autodefrag 0 0 But, even after several reboots, I still see this in `mount` /dev/nvme0n1p2 on / type btrfs (ro,relatime,seclabel,ssd,space_cache=v2,subvolid=458,subvol=/@/.snapshots/51/snapshot) I've got another system where the changes are applied and effective, so it must be something that happened or that I've done in that specific installation. Maybe something wrong with overlays, but I have to admit I'm pretty ignorant about the details of how that work, so I'm not even sure what to check for investigating. Thoughts? Ideas? Thanks in advance! -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Moin, Am Samstag, 19. Februar 2022, 17:57:42 CET schrieb Dario Faggioli:
Hello,
I'm having this problem on a MicroOS Desktop install, but I think it may be due to something not desktop-specific, and that's why I'm posting here.
What I'm doing is changing the line of fstab associated to the / filesystem. However, if I reboot and check how the fs is mounted, it seems that the old configuration is still in place and effective.
It's not a problem about modifying fstab itself, or it retaining the changes, as the file is indeed updated (e.g., I can also add lines relative to new mounts, and they work.
So, basically, I've put this in fstab:
UUID=66a3c92a-6044-43b3-973d-1973c281bd73 / btrfs ro,noatime,compress=zstd:3,ssd,space_cache,autodefrag 0 0
But, even after several reboots, I still see this in `mount`
/dev/nvme0n1p2 on / type btrfs (ro,relatime,seclabel,ssd,space_cache=v2,subvolid=458,subvol=/@/.snapshots/51/snapshot)
I've got another system where the changes are applied and effective, so it must be something that happened or that I've done in that specific installation. Maybe something wrong with overlays, but I have to admit I'm pretty ignorant about the details of how that work, so I'm not even sure what to check for investigating.
Thoughts? Ideas?
Changes in /etc/fstab done in the running system (outside of a t-u shell) are written to the overlay and not used for the initial mount of /. They'll be applied after the initrd by systemd-remount-fs, but that only works for some options, not all of them. Maybe that applies to the options you set as well. It looks like changes to /etc/fstab from inside the t-u shell are not applied in the root filesystem either, which is IMO a bug. If t-u behaved differently when you did the change on your other system, that would explain it. What you can do instead is /etc/fstab on the running system and then create a new snapshot. t-u uses /etc/fstab from the running system as base for the next snapshot, so it should have the changes for / applied. Cheers, Fabian
Thanks in advance!
participants (2)
-
Dario Faggioli -
Fabian Vogt