mountall trying to check mounts with pass=0

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

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

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.

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.

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?

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.

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.

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?

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

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

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.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".