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.
** Also affects: mountall (Ubuntu Karmic)
Importance: Medium
Status: Triaged
** Changed in: mountall (Ubuntu Karmic)
Milestone: None => ubuntu-9.10
** Tags added: regression-potential ubuntu-boot
** Summary changed:
- remote filesystem under local filesystem treated as local
+ arbitrary mount points under FHS directories (incl. /home) block the
'filesystem' signal
** Summary changed:
- arbitrary mount points under FHS directories (incl. /home) block the
'filesystem' signal
+ arbitrary remote mount points under FHS directories (incl. /home) block the
'filesystem' signal
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
