wubi kernel option "rw" required

Status changed to 'Confirmed' because the bug affects multiple users.

Did a test on a fresh install of Ubuntu 13.10 and this problem did not occur.

Another maybe oddity that might be related: when performing updates on that 13.10install, I noticed this in the logs:

'/usr/sbin/grub-bios-setup: error: attempt to read or write outside of disk `hostdisk//dev/loop2'.

Not quite sure if this was elegant or if it was correct but

'sudo dpkg-reconfigure lupin-support' ran the correct version of grub-install which worked. Why is lupin support being skipped on kernel updates?

Have a patch that I believe solves this.

....

first ubuntu patch ever:)

I believe that this comment:

https://code.launchpad.net/~noorez-kassam/ubuntu/utopic/initramfs-tools/fix-for-1317437/+merge/219927/comments/592175

""""
This is the way I understand this is and my testing is shown below:

Mounting and creating the loop device in the same step with the readonly option, makes it impossible to remount the loop device later as read-write.

By creating the loop device separately (which defaults to read-write capable unless the -r option is supplied), the loop device can then be mounted readonly, and later remounted as read-write.

This change is needed since release 14.04, which - for unknown reasons - now won't let the loop device be remounted read-write (perhaps it's passing the -r option to losetup internally and it's losetup which has started enforcing this?).

The end result is that Wubi installs cannot boot, because the remount read-write fails.

My tests confirm this:
Setup:
1. Create a file, format as ext4.
bcbc@neptune:~$ dd if=/dev/zero of=new.disk bs=1MB count=100
bcbc@neptune:~$ mkfs.ext4 -F new.disk

2. Old method, mount and create loop device as read only, then try to remount
bcbc@neptune:~$ sudo mount -r -t ext4 -o loop new.disk /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
mount : impossible de remonter périphérique bloc /dev/loop0 en lecture/écriture, est protégé en écriture
bcbc@neptune:~$ sudo umount /mnt

3. New method, first create loop device (defaults to read-write capable), then mount as read only, then try to remount read-write
bcbc@neptune:~$ sudo losetup /dev/loop0 new.disk
bcbc@neptune:~$ sudo mount -r -t ext4 /dev/loop0 /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
bcbc@neptune:~$ sudo touch /mnt/test
bcbc@neptune:~$ sudo umount /mnt
bcbc@neptune:~$ sudo losetup -d /dev/loop0

4. To confirm it's probably passing -r to losetup
bcbc@neptune:~$ sudo losetup -r /dev/loop0 new.disk
bcbc@neptune:~$ sudo mount -r -t ext4 /dev/loop0 /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
mount : impossible de remonter périphérique bloc /dev/loop0 en lecture/écriture, est protégé en écriture
bcbc@neptune:~$ sudo umount /mnt
bcbc@neptune:~$ sudo losetup -d /dev/loop0

Conclusion:
This fix is appropriate and required for loop mounted installs
""""

From "bcbc" is what this bug is all about.

This bug is being reported to happen also after a clonezilla based installation for Trusty.

"""
The issue with /tmp will timeout and continue to boot, / will hand the boot up unless there is some user intervention to continue the boot. The work around I mentioned came from a suggestion in the ‘askubuntu’ link listed below. What we did was modify /etc/grub.d/10_linux changing ‘ro’ to ‘rw’, but with the thought that this is just a temp patch with possible (unknown) downstream impact.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1308152
(can't boot from kernel 3.13.0.24 after upgrade to ubuntu 14.04 LTS but able to boot with kernel 3.11.0.20).
http://askubuntu.com/questions/453411/ubuntu-14-04-not-booting-after-error-message-tmp-could-not-be-mounted

Rebooting the system to get to the boot menu, I used the 'e' option to modify the parameters changing 'ro' to 'rw' as suggested in the 2nd thread. This temporary change allowed the system to boot.
"""

It seems that the fix that I had for this has long since been outstanding. I'd like to resurrect it if possible. If anyone has any thoughts on it, please let me know or what I should do please let me know.

https://code.launchpad.net/~noorez-kassam/ubuntu/utopic/initramfs-tools/fix-for-1317437

(It has been some time since I've been able to look at this so I might have to rebuild my development environment to reconfirm the fix)

@Noorez: Your fix still works for 14.04, 15.10 and 16.04. I have used it since summer 2014 without any problems. The only problem is that every update of an unfixed initramfs-tools package overwrites your fix.

The change, by itself, looks fine. However, I'd like to urge users to migrate away from wubi, as it is no longer supported (and 14.04 is about to be EOL too).

This doesn't mean we can't make the change, just that there should be more testing done to see how it affects other boot methods, and exactly in which cases it is useful (since it needs proper test cases anyway).

For this reason, please follow the steps at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to make sure this bug is all ready for the request to update stable releases. This mostly means updating the description with proper test cases and justification for the SRU.