You are not logged in.
Pages: 1
Topic closed
I recently built a new Arch system using BTRFS subvolumes for all the mounts. I use the "ro" option in /etc/fstab for any file system that generally doesn't need to be written to, such as /opt. Having used variations of the ext file systems until recently, this always worked very well, as I could always "mount -oremount,rw /opt" if I needed to write to it, and then use "mount -oremount,ro /opt" to make it read-only when I was done updating it. I am finding that I'm not able to do this with BTRFS. I can make the file system "ro" in /etc/fstab, and it is indeed not writable. However, as soon as I make it writable, I cannot make it read-only. The mount command gives me a "busy" error. In fact, I noticed that even if I execute "mount -oremount,ro /opt" when /opt is already mounted "ro", I still get the busy error. I am able to completely unmount /opt and then mount it read-only, however, so obviously it is not really busy. This isn't too big of a deal for file systems that aren't actually busy, so I can unmount and remount it if necessary, but if the file system contains an executable that is currently running and can't be killed, I'm stuck with the file system staying writable until a reboot.
So, what gives? Do other people see this behavior, too? Is it a bug? A feature? Anyone know if there is there a reason it behaves this way?
Thanks.
Offline
I find this behavior somewhat annoying, too: fstab ro, then `remount,rw` for some tinkering, then after that `remount,ro` would fail, OTOH `umount` then `mount` works just fine.
Offline
You do realise this thread is 11 years old ?
Moderator Note
Please re-read necro-bumping
Closing this old thread.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Pages: 1
Topic closed