Bug 214877

Created attachment 140824 [details]
util-linux-mtab-create.patch

Your request make sense, but if create_mtab() fails:
  * old version: the system is still in consistent state (= no mount, no mtab)
  * with your patch: the system is inconsistent (= device succesfully mounted, 
    but no mtab, the mount returns error). 

I think this is the reason why the mount util checks all things befor real mount(2).

Also, the mount uses the lock file for mtab updates too. The solution should be
more generic (= useful for create_mtab() and for update_mtab())

I think the best way will be found a way how detect real place (FS) where is
writeable /etc/mtab and create the lock file on the same FS. I think implement a
heuristic that from /proc/mounts detects the bind mount for /etc/mtab won't be
so difficult. It means the lock should be /var/lib/stateless/writable/mtab~<pid>
if there is a bind for mtab to /var/lib/stateless/writable/mtab.

You have to update all programs which touch the mtab and use same lock method of
course.

I hope I didn't overlook something :-)

(In reply to comment #2)
> Your request make sense, but if create_mtab() fails:
>   * old version: the system is still in consistent state (= no mount, no mtab)
>   * with your patch: the system is inconsistent (= device succesfully mounted, 
>     but no mtab, the mount returns error). 

Note, update_mtab() can fail in exactly this way right now

My proposal is that such a failure is fine, but create_mtab() should fail in the
same way

We have two sane choices, I think:

  1) If updating mtab fails, then the mount fails
  2) Whether updating mtab succeeds has no impact on the mount

But it's not sane for it to sometimes be (1) and sometimes be (2)

Maybe we just need to fix it to be (1) ... but we'd also need to figure out some
way to allow the updating to succeed on readonly-root (i.e. fix the locking)

> I think this is the reason why the mount util checks all things befor real
mount(2).

Except it doesn't (and can't?) check for everything - i.e. whether the locking
will succeed.

> Also, the mount uses the lock file for mtab updates too. The solution should be
> more generic (= useful for create_mtab() and for update_mtab())
> 
> I think the best way will be found a way how detect real place (FS) where is
> writeable /etc/mtab and create the lock file on the same FS. I think implement a
> heuristic that from /proc/mounts detects the bind mount for /etc/mtab won't be
> so difficult. It means the lock should be /var/lib/stateless/writable/mtab~<pid>
> if there is a bind for mtab to /var/lib/stateless/writable/mtab.

Something like that would be feasible ... but it's a little hairy. Hmm.

> You have to update all programs which touch the mtab and use same lock method of
> course.

Suck. :-)

This has been idle for a couple weeks, it's time to figure out how we're going
to deal with this problem.  In fact, it's become more important as we need it
addressed so that we can use anaconda to instantiate a stateless image given
system profile metadata (1).

I think we've agreed that we need to reach some level of consistency in
creation/updating of mtab.  The only question is how to best do that.

Since /etc/mtab~ and its relatives are lock files, I'd really prefer to see them
in /var/lock; the main objection to that was what to do when /var is a separate
filesystem and isn't currently mounted (as might be the case early in the boot
process).  Right?

ISTM that problem can be cleanly addressed by issuing:

mount -n /var
mount -n /var/lock

Immediately after we've performed filesystem checks (IIRC, this is what Solaris
used to do eons ago).

For a normal system both operations would be NOPs. 

For a system with /var on its own FS, the first command would mount it and we
can continue on our merry way.  The second command would be a NOP.

For a readonly-root system (without a separate /var) we'd have an entry in
/etc/fstab for /var/lock using tmpfs.

None of this seems particularly difficult to implement.  Then it's a "simple"
matter of updating all the appropriate utilities.  Right?

Jeff  

OK. I think we can move it to /var/lock/mtab (depends on initscript changes of
course), but there should be at least symlink from /etc/mtab to this new
location (for backward compatibility).

By the way, the best way is discuss changes like this at fedora-devel list.

Hmm.. now I think about rescue mode. The basic idea is keep the root partition
usable and consistent in itself. It means without any other partition :-(

Maybe the mount (and the others utils) can stat(/var/lock) and only if this
operation failed use old good /etc/mtab. Comments?

Just to be 100% clear, we're talking about moving mtab~ and mtabXXXX~, the lock
files, not /etc/mtab.

With that in mind, I don't think we should bother with a symlink to the lock
file; it doesn't make a lot of sense to me.  Every application which mucks with
the lock file should be updated rather than relying on a symlink.

To ensure rescue mode works all I think we need to do is create /var/lock in the
root filesystem.  That is a NOP for normal system.  For systems with a separate
/var it provides a suitable lock directory when running in rescue mode (which is
probably a good idea anyway).

And yes, this should ultimately move to fedora-devel; I'll take care of that
once we've got a solution we're pretty sure will work cleanly.

Jeff

One more note.  Mark's patch only deals with getting some consistency in regards
to error messages and the like.  It does not address the need to move the lock
file out of /etc.  They are separate, but related issues.

Jeff

Yeah ... see bug #214891

Ah.. yes mtab~, sorry for misunderstanding.

Created attachment 289873 [details]
util-linux-ng-2.13.1-rc1-consistent-mtab-update-failure.patch

kzak: the patch and the subject of this bug got lost in the discussion around
moving the mtab locks to /var/lock (bug #214891)

What the patch does is goes from the situation where:

  1) If /etc/mtab doesn't exist and /etc is read-only, you get the "can't create
     lock file" message and the mount fails
  2) If /etc/mtab does exist and /etc is read-only,you get the same message but
     the mount succeeds

Clearly, the failure to update /etc/mtab should either cause the mount to fail
or not ... sometimes causing it to fail, and sometimes not (each with the same
message) is not useful.

The attached patch takes the approach of making it so failure to update/create
/etc/mtab does not cause the mount to fail

I'll apply the patch to the upstream devel tree and rawhide. Thanks and sorry
for delay.