arbitrary remote mount points under FHS directories (incl. /home) block the 'filesystem' signal

Adding noauto to the list of parameters also fixes the boot problem

Ah, I see the problem - since it's under /home it's waiting for it to come up, but it's the old boot scripts that bring that one up.

Remote filesystems under local ones should be tagged remote, not local; but under /home like that they probably shouldn't be tagged at all

I just checked 0.2.1 after seeing
   "Make mountall recognize that *remote* filesystems are still remote, given
    that their parent fs is almost always local. LP: #447654."
in the changelog, but the problem is still present with 0.2.1.

Not sure what you mean by "but under /home like that they probably shouldn't be tagged at all". The main problem as far as I can tell is that the cifs file systems are mounted by the mountall service as opposed to the mountall-net service. The mount fails since that early in the process NetworkManager has not brought up the interface that is used to connect to the cifs server.

Christoph,

It's normal that the mountall service will try to mount these, and then when the network interfaces are brought up mountall-net will signal mountall to try again if it hasn't succeeded.

In 0.2.1, this is working correctly for me with nfs3 mounts; I haven't tested cifs yet. nfs4 is failing because of another issue (discussed in bug #447654) that wouldn't affect cifs mounts.

Scott, I can't corroborate the claim that "old boot scripts" are responsible for bringing up the filesystem. If I configure, e.g., /srv as a cifs share, everything comes up successfully for me as long as the server is available. I think the difference is most likely that Christoph's network connection is managed by network-manager, and doesn't come up at all until after logging in via gdm. Christoph, can you confirm that this is the case - your network connection is managed by network manager, and user credentials (e.g., a WEP key or WPA passphrase) is needed in order to bring that connection up?

Either way, though, the fix is going to be the same - don't treat arbitrary submounts of FHS directories as blockers for starting the system.

Responding to comment 6:
My connection is wired, so I don't need to wait until unlocking my keyring to get the network connection. However I do believe that the cause of the problem that the network is not available when mountall tries to mount the cifs share, since the interface has not been brought up. I just assumed that that was done with NetworkManager for wired connections as well as for wireless ones.

Yes, by default in Ubuntu, NetworkManager manages wired connections as well as wireless ones. Whether the connection comes up at boot time vs. at login time is a question of the NM configuration - I think wired connections are *supposed* to attempt DHCP by default at boot time without requiring a user login first, but I could be mistaken.

"the network is not available when mountall tries to mount the cifs share" is a red herring, btw; mountall is supposed to try the mount multiple times - once at boot, once when each network interface comes up - until it succeeds. And this does work, except in the case that bringing the network interface up is blocked waiting for the filesystem.

(Confirmed; by default, NM will attempt DHCP on a wired interface when a link is detected.)

You are right, the networking is a red herring insofar as it is only a contributing cause for the failure and bringing the networking up earlier is not an option.

I think mountall needs to be able to distinguish between mounting local filesystems only and mounting remote filesystems as well. This would fix the problem described in this bug but also addresses a fundamental problem with the upstart events in karmic:

At the moment mountall.conf emits local-filesystems and remote-filesystems. This is problematic. In order to be able to mount remote filesystems at all, the computer needs networking. Networking however depends on local-filesystems. Therefore mountall.conf is emitting two events at the same time of which one (remote-filesystems) transitively depends on the other (local-filesystems). This is why making mountall ignore the mount error of the cifs filesystem and causing it to retry all mounts that failed in mountall-net.conf is a bad idea in my opinion, since then remote-filesystems is a wrong event.

Here is why: Suppose I want to write a daemon that creates a list of all files that are stored on some remote filesystem. For example to be able to indicate to the user that the filename that the user is searching for is stored on machine foo. The daemon works with remote filesystems so I set it to start when remote-filesystems is emitted. At the moment this is clearly wrong, since remote-filesystems is emitted even before the network is brought up.

On Sun, Oct 11, 2009 at 12:23:13PM -0000, Christoph Burger-Scheidlin wrote:
> At the moment mountall.conf emits local-filesystems and remote-
> filesystems. This is problematic. In order to be able to mount remote
> filesystems at all, the computer needs networking. Networking however
> depends on local-filesystems. Therefore mountall.conf is emitting two
> events at the same time of which one (remote-filesystems) transitively
> depends on the other (local-filesystems).

No, it is not. "emits" is documentation that a job /may/ emit certain
signals; it does not mean that these signals are emitted automatically when
starting the job.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

It seems that my assertion in comment 4 on 0.2.1 was incorrect. I just updated again and spotted mountall-0.2.1 as an update. Could have sworn that it was already 0.2.1 on my system.

In 0.2.1 the cifs shares are listed as other and booting works. As far as I am concerned, the initial issue is closed.

Ah, great to hear that this is fixed for you; sounds like your problem was bug #447654 then (network-manager wouldn't start because it was waiting for remote filesystems to be mounted first). There's still another outstanding bug as described in the title of this bug report, which we will hopefully also have resolved for karmic.

What's the outstanding bug? I'm lost.

The outstanding bug is that all mountpoints under /home block the 'filesystem' signal, regardless of depth; that's a regression vs. jaunty because the network may not be available until the user logs in, or may not be available at all at boot time.

Steve, that statement is not true for 0.2.1. At least cifs filesystems are classified as 'other' and thus do not affect the 'filesystem' signal.

I spot 2 possibly only minor issues:

1) CIFS is classified as 'other' in my setup in 0.2.1 which means that remote-filesystems is never emitted since I only have CIFS shares under /home. I think that CIFS should be of type 'remote', right?

2) The event all-filesystems is currently not emitted at all. I am not sure what the semantics of it are, but I don't find an emit for it anywhere in the source of mountall. No service depends on it at the moment so that is ok, I guess.

On Mon, 2009-10-12 at 23:23 +0000, Steve Langasek wrote:

> The outstanding bug is that all mountpoints under /home block the
> 'filesystem' signal, regardless of depth; that's a regression vs. jaunty
> because the network may not be available until the user logs in, or may
> not be available at all at boot time.
>
Ok, great.

This is fixed in 0.2.2 :-)

 status fixreleased

Scott
--
Scott James Remnant
<email address hidden>

My cifs shares are still not mounted after reboot. Even after 0.2.2 mountall release.

I got the all on /etc/fstab to be mounted on /home/xxx/Music etc..

exacly the same laptop i used for jantu where this used to work.

i can mount them after log in by using "sudo mount -a" by the way.

anibal, you should probably open a separate bug report and post the contents of your /etc/fstab.

On Wed, 2009-10-14 at 08:38 +0000, anibal wrote:

> My cifs shares are still not mounted after reboot. Even after 0.2.2
> mountall release.
>
Could you file a new bug for this, e.g. "CIFS shares not mounted" and
attach your /etc/fstab and the output of running "sudo mountall --debug"

Thanks,

Scott
--
Scott James Remnant
<email address hidden>