mount(8) does not handle "update" option in the fstab(5) correctly

[sobomax]

Summary

We are implementing two-stage bootsrap here, where /etc is it's own FS which we first mount read-only and then need to promote to read-write later in the boot. There is an "update" option in fstab(5), which seemed like a solution for our need but there is also a logic in mount(8) which skips over already mounted filesystems. Which makes this option a no-op essentially. I believe if FS is marked with an "update" flag, the same logic applies as if -u command-line option has been specified.

$ ./mount_bug.sh
+ set -e
+ echo '/tmp /mnt nullfs ro 0 0'
+ echo '/tmp /mnt nullfs rw,update 0 0'
+ sudo mount -a -F fstab1
+ sudo mount -a -F fstab2
+ touch /mnt/somefile
touch: /mnt/somefile: Read-only file system

Test Plan

$ cat mount_bug.sh
#!/bin/sh

set -x
set -e

echo "/tmp /mnt nullfs ro 0 0" > fstab1
echo "/tmp /mnt nullfs rw,update 0 0" > fstab2
sudo mount -a -F fstab1
sudo mount -a -F fstab2
touch /mnt/somefile
rm /mnt/somefile
sudo umount /mnt

[mckusick]

This change does not seem wrong, though the only way I can see it being usable is to have the read-only mount's in /etc/fstab, then a special fstab that has the desired update mount lines in it. Because if the update mount's are in /etc/fstab, then for 'mount -a' the read-only mount will happen immediately followed by the read-write mount. Though I suppose that the update mount line could appear first (and fail) followed by the read-only mount which would presumably succeed. Then on the second 'mount -a' the update would succeed and the read-only would be skipped because it was already mounted. But this seems like a really obscure way of doing things. Plus you would have to change mount so that would not exit when the initial "ro,update" failed.

Why not have a `mount -u -w /etc' at the appropriate part of your startup script?

[kib]

So what happen when somebody run 'mount -a' second time, with non-idempotent mount option + update ?

[sobomax]

In D18586#396505, @mckusick wrote:

This change does not seem wrong, though the only way I can see it being usable is to have the read-only mount's in /etc/fstab, then a special fstab that has the desired update mount lines in it.

This is precisely our scenario. We have "stage0" fstab, which only contains barebone fses needed to bootstrap multi-user, which resides in the root fs:

/dev/ufs/root_20181217203526 /    ufs   ro         0 0
/dev/ufs/etc_20181217203526  /etc ufs   ro         0 1

And then the "normal" fstab which resides in the /etc being mounted over it:

/dev/ufs/root_20181217203526 /                 ufs   ro             0 0
/dev/ufs/etc_20181217203526  /etc              ufs   rw,update,sync 0 1
auto                         /tmp              tmpfs rw             0 0
vol-0aba51a72d1feb3ea        /usr/local        zfs   rw             0 0

Because if the update mount's are in /etc/fstab, then for 'mount -a' the read-only mount will happen immediately followed by the read-write mount. Though I suppose that the update mount line could appear first (and fail) followed by the read-only mount which would presumably succeed. Then on the second 'mount -a' the update would succeed and the read-only would be skipped because it was already mounted. But this seems like a really obscure way of doing things. Plus you would have to change mount so that would not exit when the initial "ro,update" failed.

Why not have a `mount -u -w /etc' at the appropriate part of your startup script?

The advantage of our method is that it plays nicely with loader and other parts that peek over /etc/fstab. And it also integrates with zero efforts into our fsck rc.d framework, so that /etc is actually checked and fixed if needed before it's being upgraded rw. In fact, we can potentially use it to get rid of the root_rw_mount rc.conf(5) knob and other "special" code in the mount(8) to handle updating root fs. By just requiring marking root fs with an update option in the stock fstab.

[sobomax]

In D18586#396514, @kib wrote:

So what happen when somebody run 'mount -a' second time, with non-idempotent mount option + update ?

Sorry, having a hard time parsing your question. Could you give me some more specific example of the scenario you have in mind?

[mckusick]

Given that this plausibly works only with two different /etc/fstab files, I think your change should also include an update to the manual page to explain how the update keyword is intended to be used.

[sobomax]

Document "update" option, as suggested by @mckusick

[sobomax]

In D18586#397007, @mckusick wrote:

Given that this plausibly works only with two different /etc/fstab files, I think your change should also include an update to the manual page to explain how the update keyword is intended to be used.

Done, please check. Thanks!

[bcr]

Hi @sobomax,
can you run textproc/igor and "mandoc -Tlint" over your man page change? It will give you a few suggestions (not many). Thanks!

[mckusick]

The addition to fstab.5 is helpful, but slightly incomplete in that it is not clear in what context the update keyword would be used.I would add text at the end of your new block that says something like:
The
.Dq update
option is typically used in conjuction with two
.Nm
files.
The first
.Nm
file is used to set up the initial set of file systems.
The second
.Nm
file is then run to update the initial set of file systems and
to add additional file systems.

A small nit, by convention only trailing punctuation follows a macro. So, your:
.Nm , unless it's a root file system, in which case logic similar to
should be
.Nm ,
unless it's a root file system, in which case logic similar to

[mckusick]

Has this been resolved / committed?

[sobomax]

Document usage scenario bit further. Fix some mandoc formattings nits. Suggested by @mckusick

[mckusick]

Looks good.