Running the Intrepid LiveCD in persistent mode results in busybox prompt

Marking this for beta as it completely breaks persistence support, which is something we hope to use and advertise as part of usb-creator.

Attached is a casper log with set -x enabled, and with mount and /proc/mounts appended.

I hope I am testing this the right way: I created a USB stick with usb-creator, and booted by using F6 to add the "persistent" option to the kernel command line. The system was booted into busybox in initramfs.

The casper.log Evan attached has this:

+ mount -o remount,ro /dev/sda1 /cdrom
mount: mounting /dev/sda1 on /cdrom failed: Device or resource busy

When I try the similar command in my busybox environment, I get the same error. /dev/sdX1 (the USB stick is sdc for me) is mounted as both /cdrom and /casper-rw-backing. I suspect that this may be reason the remount doesn't work. It also makes unmounting impossible!

It ought to be possible to mount the same filesystem in multiple places, but I'm not sure how that interacts with remounting. Can you figure out the casper logic involved here?

Sorry, I wouldn't know how to, but if there's anything I can do to help find out the source of the problem I'd be glad to :)

Vincent: Sorry if I was unclear; I was addressing Lars in my last comment.

Hi,

I've followed the code through some and I see the following steps
happen (with root persistence, something similar probably happens
with home persistence)

  1) It finds the live image and mounts that at /cdrom, then finds
      the squashfs within, loop mounts it, and remembers the mount
      point for the ro part of the aufs mount.

  2) It finds the device with casper-rw on it, and mounts this at
      /casper-rw-backing.

  3) It loop mounts casper-rw and then mounts that at /cow

  4) It then sets up the aufs mount to combine the two parts.

  5) It then attempts to mount the home persistence. This could
      cause the issue as well, but as it tries to remount with rw then
      it may not as it doesn't need to change anything.

  6) It then attempts to look for the snapshots. This calls find_files
      which in turn causes try_mount with "ro", which tries to remount
      already mounted filesystems, causing this issue.

find_files has a "# FIXME: merge with above function ", referring to
find_cow_device, which could possibly fix this. I'm not too sure how this
would be done though.

How about this as a hack in try mount?
     if where_is_mounted ${dev} > /dev/null; then
- mount -o remount,"${opts}" ${dev} $(where_is_mounted ${dev}) || panic "Remounting failed"
+ if [ "${opts}" != "ro" ]; then
+ mount -o remount,"${opts}" ${dev} $(where_is_mounted ${dev}) || panic "Remounting failed"
+ fi
         mount -o bind $(where_is_mounted ${dev}) ${mountp} || panic "Cannot bind-mount"

as there is no point remounting read-only for the uses that are made of try_mount.

Alternatively the attached may be slightly more palatable. It just re-uses the existing
mount if there is one, as all it wants to do is copy files from it.

I'm sure you will come up with something far more elegant to solve the problem
though.

Oh, and of course it is completely untested. If testing is just a case
of unpacking the live CD, installing a patched new version and repacking
it then I will be happy to test any patches.

Thanks,

James

This bug was fixed in the package casper - 1.148

---------------
casper (1.148) intrepid; urgency=low

  * Skip remounting read-only in try_mount as it's unnecessary and
    breaks persistence. Thanks James Westby (LP: #274076).

 -- Evan Dandrea <email address hidden> Wed, 15 Oct 2008 13:13:38 -0400

Sorry if im bringing this up again. Ive run into this issue. Casper in intrepid currently is 1.151 and is not installed on my system. Will the newer casper ship with intrepid and do I need to install it to fix this? I guess Im a little confused. Thanks

On Mon, 2008-10-20 at 19:41 +0000, Elias K Gardner wrote:
> Sorry if im bringing this up again. Ive run into this issue. Casper in
> intrepid currently is 1.151 and is not installed on my system. Will the
> newer casper ship with intrepid and do I need to install it to fix this?
> I guess Im a little confused. Thanks
>

Casper is only installed on the live CD, and this bug only affects
the live CD, so if you have Intrepid installed this bug won't matter
to you.

If you are trying to use persistence on a recent live CD (a daily from
the last few days), and it doesn't work then please post that fact
here.

Thanks,

James

no sorry ill have to post a new bug

Accepted casper into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Is there something that differentiates any testing that needs to be done for this bug versus bug 219192, or is the testing done for bug 219192 sufficient for this bug as well? Thanks.

To me, these bugs are sufficiently similar to treat your testing of bug 219192 as enough verification of this one. Thank you!

This bug was fixed in the package casper - 1.132ubuntu0.3

---------------
casper (1.132ubuntu0.3) hardy-proposed; urgency=low

  * Backports from trunk to fix persistence:
    - Do not use mode= when mounting /cow using persistent mode (LP: #219192).
    - Skip remounting read-only in try_mount as it's unnecessary and breaks
      persistence. Thanks James Westby (LP: #274076).

 -- Evan Dandrea <email address hidden> Wed, 17 Jun 2009 10:39:35 +0100