Comment 27 for bug 537133

I have analysed the problem again and found the following sequence of events:

* root fs (nfs) is detected as local (see tag_mount)
* resulting in 1 local fs, a dozen of virtual fs and NO remote fs remaining
* / is going to be remounted, because it is already mounted, but read-only (see run_mount. also take a closer look on needs_remount and has_option)
* run_mount spawns a mount process for this remount with wait = FALSE, because is_remote tells that it is in fact a remote mount
* accordingly to the options spawn adds a child watch for the mount process and returns immediately
* try_mounts is continually executed by the mainloop (when all is mounted and nothing needs a remount try_mounts exits the mainloop)
* All mounts except the / remount finishes

Somehow magically the read-only flag used by need_remount changes before the mount process finishes. (I think this is caused by an udev event, which then may call update_mount, which then again may change opts)
As a result try_mounts thinks all mounts are done and simply exists, which then causes a blocked boot process, because the necessary events (local-filesystems, ...) weren't sent.

As you can see this seems to be a bug not only related to nfs mounts, more generally it is related to all remounts. I think it doesn't show up on local filesystems because remounts are much faster and therefore the risk is rather low to run into such a situation. In contrast remote filesystems (like nfs) require more time for remounting and also show up this bug.

I can think of the following possible ways to fix this:
* Also check in try_mounts if mount_pid > 0
* Spawn all remounts with wait = TRUE
* Set mounted to FALSE, when a remount is started - possible side effects?
* Maybe it is also possible to somehow change the behaviour of update_mount and needs_remount

I can provide my detailed system setup, mountall logs and patches for the various ways to fix this if you like.

I hope that a fix could be released soon ;)