Ubuntu

mountall trying to check mounts with pass=0

Reported by Paul Crawford on 2010-05-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Undecided
Unassigned
Lucid
Low
James Hunt

Bug Description

Binary package hint: mountall

When testing the automated check of file systems with 10.04 LTS release version, it seems that mountall 2.14 is going through all entries in fstab and trying to check all of my CIFS mounts with <dump> and <pass> set to zero, generated warnings in boot.log about the missing fsck.* programs.

Also I expected the messages to be in /var/log/fsck/checkfs and fsck/checkroot rather than boot.log (which is also a bug I noticed in Ubuntu 9.10)

Paul Crawford (psc-sat) wrote :

Tested again with updates from Arand's unstable PPA for plymouth and mountall (though mountall --version still says 2.14!?) and it still complains about CIFS mounts when I forced a check of file systems:

sudo touch /forcefsck

<reboot>

boot.log shows:

fsck from util-linux-ng 2.17.2

/dev/sda7: 169050/3227648 files (0.1% non-contiguous), 1662457/12893952 blocks

mount error: cifs filesystem not supported by the system

mount error(19): No such device

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount error: cifs filesystem not supported by the system

mount error(19): No such device

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount error: cifs filesystem not supported by the system

mount error(19): No such device

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mountall: mount /media/scratch [877] terminated with status 32

mountall: mount /media/mp3 [881] terminated with status 32

mountall: mount /media/pscpc [869] terminated with status 32

yeti (utu) wrote :

mountall 2.15 is available as a backport to 10.04 LTS.
Try apt or synaptic.
Dev group is working on (at least) mountall 2.5, but I don't know where you'd get that.
I don't know if either of these will help, but it may be worth a try at least for 2.15

yeti (utu) wrote :

Forget the previous mountall 2.5 comment, that's a much earlier version of mountall.

I'm not happy that mountall 2.15 forces long-winded fscks of presumably clean ext3 partitions. In my case, it's a trivial two-minute wait, once every 20 mounts, but I don't think this delay should be there for a journaled system mounted read-only.

Paul Crawford (psc-sat) wrote :

It seems my system has been updated to 2.15 but there are still the odd warnings about CIFS mounts in fstab
Also the stage 2 of 3 pass had no text on the plymouth screen, but it came back for stage 3 of 3.

Changed in mountall (Ubuntu):
status: New → Confirmed
Changed in mountall (Ubuntu Lucid):
importance: Undecided → Low
status: New → Confirmed
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Colin Watson (cjwatson) on 2011-06-14
Changed in mountall (Ubuntu Lucid):
assignee: Canonical Foundations Team (canonical-foundations) → James Hunt (jamesodhunt)
Steve Langasek (vorlon) wrote :

The bug description talks about checking mounts with pass=0; but the log output included in the bug shows errors when trying to *mount* the cifs mounts. What exactly is the problem you're experiencing?

Changed in mountall (Ubuntu):
status: Confirmed → Incomplete
Paul Crawford (psc-sat) wrote :

The original problem, though sadly I did not post the exact messages, was saying it could not run fsck.cifs (which of course is non-existent). The bug in this case was that with pass=0 it should not even have tried to run a check on boot-up.

The bug now is the same underlying problem, that during the initial pass though fstab to do any file system checks during booting it is trying to mount the CIFS systems which (a) won't work as networking, etc, is not up yet, and (B) the log-in credentials are missing as they are on my /home partition, also not mounted yet.

Basically the problem is at this stage it should only be considering locally mounted file systems, as anything else cannot be mounted until the system has booted further and has networking, samba, nfsd, etc, are up.

Maybe even stronger, it should not bother at this stage with anything if pass=0 since you are basically telling it not to check things.

Paul Crawford (psc-sat) wrote :

The current (64-bit 10.04) boot.log file has messages such as these appearing:

error -1 (Unknown error 18446744073709551615) opening credential file /home/paul/.smbcredentials
mountall: mount /media/swdev [1087] terminated with status 1
mount error: could not resolve address for smb: Temporary failure in name resolution
No ip address specified and hostname not found

Again, not a surprise given this is before partitions such as /home are mounted, and before networking, NIS, samba, etc, are up.

Steve Langasek (vorlon) wrote :

Ok; the error message for fsck.cifs has been resolved now via bug #838091. I don't know if mountall is still trying to find fsck for filesystems with pass=0 set - it's not meant to, and the code is written to specifically avoid fscking them.

> The bug now is the same underlying problem, that during the initial pass
> though fstab to do any file system checks during booting it is trying to
> mount the CIFS systems which (a) won't work as networking, etc, is not
> up yet, and (B) the log-in credentials are missing as they are on my
> /home partition, also not mounted yet.

So I don't agree that a) is a problem. networking *may or may not* be up at the time mountall first tries to mount the filesystems; and networking may be *partially* up, but the route to the required server may not be up yet. mountall cannot sanely determine the "right" time to try to mount the network filesystems, so it does the only reasonable thing and tries to mount them at startup, and if that fails, tries to mount them again each time a network device comes up (and signals mountall with SIGUSR1).

b) however means that you have a dependency between your mounts, and that's not something that mountall is designed to cope with. It's not going to introspect the fstab options for each filesystem type to detect when a mount has dependencies on files stored on other filesystems. For your use case, I think the only appropriate solution is to mark the filesystem 'noauto' and use an upstart like this to mount it at the right time:

  start on mounted MOUNTPOINT=/home and network-device-up IFACE=$my_interface
  task
  pre-start exec mount /media/swdev

We could conceivably *also* hide the error messages from mount rather than displaying them since we know that in many cases they will be spurious; but then how do we ensure debuggability of the system when there really is a problem with a network mount?

Steve Langasek (vorlon) wrote :

oops, I think that 'task' bit in the sample upstart job is wrong.

Paul Crawford (psc-sat) wrote :

OK, that makes sense. I had assumed this was a check-only pass through fstab

Steve Langasek (vorlon) wrote :

Based on the bug comment history, I don't believe there are any further changes to be made to mountall here. If I've overlooked something, please reopen.

Changed in mountall (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments