wubi kernel option "rw" required

Bug #1317437 reported by syscon-hh on 2014-05-08
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Low
Unassigned

Bug Description

We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a windows 8.1.

Since upgrade
 * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
 * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
the wubi installation won't work / start and ends with the massage:
"Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

"key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer manuelle Wiederherstellung"

Changing the sequence of "/boot/grub/grub.cfg" inside the line:
 * linux /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 loop=/ubuntu/disks/root.disk ro quiet splash $vt_handoff
into
 * linux /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 loop=/ubuntu/disks/root.disk rw quiet splash $vt_handoff
(kernel option »ro« into »rw«) lets start the wubi installation without any restrictions.

For further system-information see -> annex

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: lupin-support 0.55
ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
Date: Thu May 8 10:53:53 2014
ProcEnviron:
 LANGUAGE=de_DE
 TERM=xterm
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: lupin
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

syscon-hh (syscon-kono) wrote :
syscon-hh (syscon-kono) wrote :
syscon-hh (syscon-kono) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in lupin (Ubuntu):
status: New → Confirmed
Noorez (noorez-kassam) wrote :

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

Noorez (noorez-kassam) wrote :

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

Noorez (noorez-kassam) wrote :

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?

Noorez (noorez-kassam) wrote :

Have a patch that I believe solves this.

....

first ubuntu patch ever:)

affects: lupin (Ubuntu) → initramfs-tools (Ubuntu)
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Rafael David Tinoco (inaddy)
Changed in initramfs-tools (Ubuntu):
assignee: Rafael David Tinoco (inaddy) → nobody

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.

Changed in initramfs-tools (Ubuntu):
assignee: nobody → Rafael David Tinoco (inaddy)
status: Confirmed → In Progress

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

Changed in initramfs-tools (Ubuntu):
status: In Progress → Incomplete
assignee: Rafael David Tinoco (inaddy) → nobody
Noorez (noorez-kassam) wrote :

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)

hakuna_matata (hakuna-matata) wrote :

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

Mathew Hodson (mhodson) on 2016-04-03
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Low
Mathew Hodson (mhodson) on 2016-05-17
Changed in initramfs-tools (Ubuntu):
status: Incomplete → New

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.

Changed in initramfs-tools (Ubuntu):
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers