mountall fails on loop-device without losetup

Bug #441454 reported by JensLechtenboerger
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Fix Released
Low
Scott James Remnant (Canonical)
Karmic
Fix Released
Low
Scott James Remnant (Canonical)

Bug Description

Binary package hint: mountall

My /etc/fstab contains the following line for an encrypted partition:
/dev/loop1 /backup reiserfs defaults 0 2
mountall seems to see that /dev/loop1 is there and attempts to mount without prior invocation of losetup. Hence, the mount fails.
In Jaunty, I had a script /etc/rcS.d/S08losetup, which did a proper setup of the loop device, before it was mounted later in the boot process. On Karmic, this script is still executed but too late (due to upstart). I tried to use /etc/init/losetup with "start on startup". However, this fails as the underlying device (/dev/hdb1) is not yet created.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 3 17:02:33 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: mountall 0.1.8
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature:

SourcePackage: mountall
Uname: Linux 2.6.31.1 i686
XsessionErrors:
 (gnome-settings-daemon:3726): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:3726): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:3761): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:3802): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

Revision history for this message
JensLechtenboerger (lechten) wrote :
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Could you attach your S08losetup script?

Changed in mountall (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Note that fstab, for a loop device, should generally contain something like:

  /home/backup.img /backup reisfers loop 0 0

mount will take care of calling losetup for you, and mountall is smart enough to do that mount after /home is mounted (assuming separate partition) or once root is writable

Changed in mountall (Ubuntu):
milestone: none → ubuntu-9.10
status: Incomplete → In Progress
assignee: nobody → Scott James Remnant (scott)
Changed in mountall (Ubuntu Karmic):
status: In Progress → Fix Committed
Revision history for this message
JensLechtenboerger (lechten) wrote :

As you suggested I changed fs_passno from 2 to 0 and added the options of losetup to /etc/fstab. Now it works without separate script. Thanks!

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

I've uploaded a new mountall package to the ubuntu-boot PPA:

https://launchpad.net/~ubuntu-boot/+archive/ppa

I would appreciate it if you could install this and try it out. *BEFORE* you reboot though, could you run "sudo mountall --debug > mountall.log 2>&1" and attach that to this bug - then after you reboot, let me know whether it worked or not.

Thanks

Revision history for this message
JensLechtenboerger (lechten) wrote :

This file contains the output of sudo mountall --debug, slightly edited to delete output related to windows partitions and no-auto /media entries.

Revision history for this message
JensLechtenboerger (lechten) wrote :

The new version of mountall (mountall_0.2.0~boot3_i386.deb) did not work at all.
I got: "mountall: /proc/filesystems: No such file or directory"
"mount" showed /proc as mounted, yet it wasn't. After deleting the entry in /etc/mtab I was able to "mount /proc" successfully.
However, after ctrl-d, the boot process stopped.
Luckily, the old mountall-package was still available in /var/cache/apt/archives/...

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Sorry about the issues with the previous PPA versions, as usual things worked just fine when I tested it in the various rigs I have here - of course it flatly failed when installed on normal systems because I hadn't actually tested that ;)

I've uploaded a new ~boot4 version, this one feels much better (and I'm running it on my laptop now :p)

As before, after installing the package but *before* you reboot, please run with --debug and attach the log to the bug - then after rebooting, let me know how it works out.

Thanks for all your help with testing, this is a big change and it's good to know that it's now working for 95% of people and your help getting it work for the final 5% is greatly appreciated!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 0.2.0

---------------
mountall (0.2.0) karmic; urgency=low

  [ Colin Watson ]
  * Always check the root filesystem if --force-fsck is used, regardless of
    passno. LP: #435707.

  [ Johan Kiviniemi ]
  * Have each fsck instance create a lock for each underlying physical device.
    If you have a single disk or RAID, all filesystem checks will happen
    sequentially in order to avoid thrashing. On more complex configurations,
    you’ll benefit from the parallel checks mountall has been doing all along.
    LP: #434974.

  [ Scott James Remnant ]
  * Flush standard output and error before spawning processes to make
    capturing logs easier (otherwise we end up repeating things still in
    the buffer), and before calling exec().
  * Turn the code upside down so that each mount knows what it's waiting
    for, and allow multiple dependencies. This makes the code much more
    readable putting the "policy" in a single function, and will make it
    much easier in future when this is done by Upstart.
  * For kernel filesystems listed in fstab, honour the order that they
    are listed in fstab. LP: #432571, #433537, #436796
  * Always create new swap partition mounts for each fstab entry, don't
    treat them as updating the same. LP: #435027.
  * Virtual filesystems under local or remote filesystems (and local under
    remote) don't delay the virtual or local events. LP: #431040.
  * Simplify event emission, this has the advantage that we can now output
    what mount points we're waiting for and what they are waiting for as
    well.
  * Fixed issue with trailing slashes. LP: #443035.
  * Only run hooks if the filesystem was not already mounted. LP: #444252.
  * Don't clean up /tmp when run without --tmptime argument.
  * Ignore loop and ram devices until ready. LP: #441454.
  * Add options to binfmt_misc filesystem, which will probably cause it to
    be mounted on boot as well.
  * Synchronously mount local and virtual filesystems, I suspect this is
    the real cause behind the XFS races as one will modprobe and the other
    will not (and fail). LP: #432620.
  * Synchronously activate swap to avoid out of memory issues when checking
    the root filesystem.
  * Enumerate existing udev devices on startup, so we don't always have to
    see udev be coldplugged.
  * Don't break on general errors for non-essential filesystems.
    LP: #441144.
  * Don't repeat attempts to mount a filesystem without having first
    succeded to mount another.
  * Still restart mountall even if the recovery shell fails.
  * Don't queue filesystem check when device is "none", or missing, or the
    filesystem is marked nodev.
  * Generate a "mount" event before mounting a filesystem, and wait for its
    effects to complete.

 -- Scott James Remnant <email address hidden> Fri, 09 Oct 2009 16:50:46 +0100

Changed in mountall (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
JensLechtenboerger (lechten) wrote :

Almost. I stlll get: "mountall:/proc/filesystems: No such file or directory"
This happens with as well as without "proc /proc proc defaults 0 0" in /etc/fstab.

If I enter the root password, /proc is mounted correctly, and I see /proc/filesystems. After hitting ctrl-d the boot process resumes successfully. The loop device is set up correctly via /etc/rcS.d/08losetup, and /backup is mounted.

Revision history for this message
JensLechtenboerger (lechten) wrote :

I forgot to mention: I tested ~boot5, not ~boot4.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 441454] Re: mountall fails on loop-device without losetup

On Fri, 2009-10-09 at 19:20 +0000, JensLechtenboerger wrote:

> Almost. I stlll get: "mountall:/proc/filesystems: No such file or directory"
> This happens with as well as without "proc /proc proc defaults 0 0" in /etc/fstab.
>
This doesn't appear in the log you attached - in fact the log shows it
parsing /proc/filesystems. Can you get a new log when you see that
error?

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Fri, 2009-10-09 at 19:20 +0000, JensLechtenboerger wrote:

> Almost. I stlll get: "mountall:/proc/filesystems: No such file or directory"
> This happens with as well as without "proc /proc proc defaults 0 0" in /etc/fstab.
>
Oh, sorry, I see the problem.

Can you open a new bug for the "mountall:/proc/filesystems: No such file
or directory" error?

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Fri, 2009-10-09 at 19:20 +0000, JensLechtenboerger wrote:

> "mountall:/proc/filesystems: No such file or directory"
>
This may be bug 447525

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
JensLechtenboerger (lechten) wrote :

I guess it was bug 447947. Now everything is working.

Many thanks
Jens Lechtenbörger

Revision history for this message
nivlac (carndt) wrote :

Scott,

mount and its options in fstab will not mount a raid device attached to a file.

/somefile /somelocation ext4 loop 0 0

because mdadm must assemble and start the array first:

mdadm --assemble --scan /dev/someloopdevice

and losetup needs to setup that loop device first:

losetup /somefile /dev/someloopdevice

Any idea what the right way to do this is on boot!

More background:

This device won't be mounted in the host os.

the array gets mounted in an lxc container

yet the host OS must do the losetup and the array assemble

and start for the container to use the device...

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.