after fsck on startup, no network filesystems are shown in mtab

Bug #196420 reported by disabled.user
6
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Whenever a file system check (possibly only affects the root file system) happens on system boot (due to maximum mount count or check interval reached on ext3), after system startup is complete, no network shares from fstab show up in mtab, but the shares have been mounted. I've noticed this behaviour since Dapper, Gutsy is still affected, don't know for Hardy.

It may seem more like a cosmetical bug, but imagine this:
Multiple NFS- and CIFS shares are mounted via fstab from servers which are connected via remote VPN connections. Now, after a "normal" (without fsck) startup, network mounts show up in mtab an therefore won't be scanned when slocate runs, because the default behaviour of slocate won't scan on network file systems. But if the network mounts don't show up in mtab, slocate won't notice that network mounts actually are network mounts, and therefore scans them like normal, local subdirectories.

A possible solution for this would be changing /etc/updatedb.conf, but this would only be a workaround and wouldn't solve the original problem.

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Thanks for your bug report. Since this issue affect CIFS / fsck, shouldn't that be a linux of fsck bug rather than a usplash bug? Is there something related to usplash in that bug?

Changed in usplash:
assignee: nobody → saivann
status: Confirmed → Incomplete
Revision history for this message
Dereck Wonnacott (dereck) wrote :

I'm sorry, being fairly new to Launchpad, I was misinformed that bugs that occur at boot-time should be moved to usplash. I have since learned much about bug management.

I'll try not to make the same mistake again, there are plenty of new ones to be made after all. :)

Changed in usplash:
status: Incomplete → New
Revision history for this message
disabled.user (disabled.user-deactivatedaccount) wrote :

My guess would be something related to busybox-initramfs or initramfs-tools. fsck on the root file system on system boot happens while the system is still running from initrd.

Changed in linux:
assignee: saivann → nobody
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

I don't suppose you would be willing to test the Hardy Alpha release as that is currently under development: http://www.ubuntu.com/testing . Thanks.

Changed in linux:
status: New → Incomplete
Revision history for this message
disabled.user (disabled.user-deactivatedaccount) wrote :

I've tested the current Kubuntu Hardy Alpha within VMware Server running on Kubuntu Gutsy. It seems Hardy is NOT affected by this bug report, but Dapper up to Gutsy are. But since this is not a security related bug, my hopes for a fix for the stable releases aren't that high...

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

I'm glad to hear this is working in Hardy. Unfortunately you are correct that this does not qualify for a stable release update for earlier releases. I'm going to go ahead and close this as "Fix Released" against Hardy. Thanks.

Changed in linux:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.