Cannot remount loopfiles

[Agostino Russo]

Binary package hint: initramfs-tools

Loopfiles inside of vfat cannot be remounted rw. This preventfs people from booting off loopinstallations in vfat. At the moment there is an exception in scripts/local to mount ntfs filesystems rw by default since those too cannot be remounted (bug #186117). It might be necessary to extend the treatment to all loopinstalation filesystems. Following are some of my experiments, not sure if there is some other way to be able to remount the host/loopfile.

root@nbago~#mount -t vfat -o rw /dev/sda8 /mnt
root@nbago~#mount -o loop,ro /mnt/root.disk /media/tmp
root@nbago~#mount -o remount,rw /media/tmp
mount: block device /mnt/root.disk is write-protected, mounting read-only
root@nbago~#umount /media/tmp
root@nbago~#mount -o loop,rw /mnt/root.disk /media/tmp
root@nbago~#mount -o remount,ro /media/tmp
root@nbago~#mount -o remount,rw /media/tmp
root@nbago~#mount -o remount,ro /mnt
mount: /mnt is busy
root@nbago~#mount -o remount,ro /media/tmp
root@nbago~#mount -o remount,ro /mnt
mount: /mnt is busy
root@nbago~#umount /media/tmp
root@nbago~#umount -d /mnt
root@nbago~#mount -t vfat -o ro /dev/sda8 /mnt
root@nbago~#mount -o loop,rw /mnt/root.disk /media/tmp
root@nbago~#mount -o remount,rw /media/tmp
mount: block device /mnt/root.disk is write-protected, mounting read-only
root@nbago~#umount /media/tmp
root@nbago~#losetup /dev/loop3 /mnt/root.disk
root@nbago~#mount -o ro -t ext3 /dev/loop3 /media/tmp
root@nbago~#mount -o remount,rw /media/tmp
mount: block device /dev/loop3 is write-protected, mounting read-only

[Agostino Russo (ago)]

The workaround involves mounting all loopinstallations rw to begin with:

--- local 2008-03-13 11:15:50.346417000 +0000
+++ local.new 2008-03-13 11:16:44.140677000 +0000
@@ -62,7 +62,7 @@
        [ "$quiet" != "y" ] && log_end_msg

        if [ ${readonly} = y ] && \
- ([ -z "$LOOP" ] || [ "${FSTYPE#ntfs}" = "$FSTYPE" ]); then
+ [ -z "$LOOP" ]; then
                roflag=-r
        else
                roflag=-w

[Luke Yelavich (themuso)]

This work-around allows a FAT32 install to boot successfully. The questin is however, whether we want to support FAT32 installs, and whether there is a more sane approach.

[Agostino Russo (ago)]

I think that the issue is due to the fact that the ro/rw status of a loopdevice is set once that is created and cannot be changed later on.

So if /host is ro or if the loop device is created via losetup ro or if it is created implictily via mount -o loop,ro, then it will not be possible to remount the underlying filesystem rw even if the loopfile contains an ext3 filesystem.

It might be worth trying to see if blockdev --setrw can fix that (cannot test that now).

losetup -r /dev/loop5 loop_file_with_ext3
#the generated loop device is now ro for life
mount -o ro /dev/loop5 /mnt
blockdev --setrw /dev/loop5
mount -o remount,rw /mnt

[Agostino Russo (ago)]

I did some preliminary tests with blockdev (which was suggested to me by Colin Watson) and added some code to mounthost (Mounthost is the init.d scripts that takes care of remounting the host directory for loopinstallations, see http://bazaar.launchpad.net/~ubuntu-installer/lupin/hardy/revision/93).

I can remount a loopfiles using blockdev --setrw in a simple set-up (ext3 file inside of a vfat partition), but that does not work as well when said loopfile contains /.

For the time being I would suggest to apply the workaround in the first comment, to make it possible for vfat users to install via Wubi and hence to avoid needless tickets.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.85eubuntu33

---------------
initramfs-tools (0.85eubuntu33) hardy; urgency=low

  * Edit scripts/local with patch from
    https://bugs.edge.launchpad.net/wubi/+bug/201750 comment 1
    "Cannot remount loopfiles inside of vfat"
    "The workaround involves mounting all loopinstallations rw to begin with"
    Closes LP: #201750

 -- Jonathan Riddell <email address hidden> Mon, 17 Mar 2008 14:35:20 +0000

[Agostino Russo (ago)]

Resetting status to in progress, since a proper fix would involve being able to actually remount filesystems.

[Agostino Russo (ago)]

Changing priority since the partial fix, although not very elegant, does address the issue, and I have not seen many complaints that can be linked to this bug

[Noorez (noorez-kassam)]

Looks like a related (possibly smae) has emerged in ubuntu 14.10

https://bugs.launchpad.net/ubuntu/+source/lupin/+bug/1317437

It seems that not only does the host file system have to be rw but also the loop file. The ticket above shows that by changing the kernel parameter from ro->rw corrects the issue in that ticket.

[Noorez (noorez-kassam)]

Did a quick test: In a loopmounted ubuntu 13.10 installation:

>boot into a fresh loopmounted install of ubuntu 13.10
>drop to the root shell in recovery mode
>try to remount the loop file system as rw (sucess).

This fails with loopmounted installs of Ubuntu 14.04.

[Noorez (noorez-kassam)]

ref: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437

possibly related to this bug:

The kernel parameter 'rw' was required to make loopinstalled (wubi) ubuntu 14.04 boot. I have a small fix for the initramfs-tools that fixes this.

The loop device that root.disk was mounted on needs to be setup read-write so that the loop filesystem can be remounted as read-write from read-only.

I have a patch almost ready... (first ever ubuntu patch so working through the process...)

[Benjamin Drung (bdrung)]

Setting back to New after being "in progress" for years.