Cannot remount loopfiles

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

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.

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

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.

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

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

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

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.

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.

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...)

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