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. -- arbitrary remote mount points under FHS directories (incl. /home) block the 'filesystem' signal https://bugs.launchpad.net/bugs/447649 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
