Ubuntu fails to boot from ISO if there's a NTFS partition with Windows hibernated on it.

Bug #670096 reported by Purko Balkanski on 2010-11-02
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Medium
James M. Leddy
Precise
Medium
James M. Leddy
lupin (Ubuntu)
Undecided
Stéphane Graber
Declined for Raring by Ara Pulido
Precise
Medium
Brian Murray

Bug Description

Package hint: initrd-tools

Greetings!

The Bug:

When booting Ubuntu from a frugal install, or when booting Ubuntu through Grub2 directly from the Ubuntu LiveCD ISO-file, the booting process fails if there's a partition with Windows hibernated on it.

Reportedly such boot also fails if there's an encrypted partition, logically before the partition which holds the Ubuntu files.

In short: If such a partition exists, which...
... is (1) logicly BEFORE the partition which holds filesystem.squashfs
...AND (2) that partition contains a supported file system, ...
...AND (3) that partition is for some reason not able to be mounted, ...
then the booting process panics and fails.

Distros affected:

I encountered the problem with: ubuntu-10.10-desktop-i386.iso
The problem likely exists in all distros that use the same Casper startup scripts.
I confirmed the same problem with the downstream linuxmint-10-gnome-rc-i386.iso

The Problem:

When the OS takes over from the boot loader, it needs to find its "filesystem.squashfs". It knows the path, we've supplied it through the "iso-scan/filename=" boot option, but it doesn't know on which device it is on.

So what the init-scripts currently do, is they start a big search loop through all partitions on all devices, mounting them in a row, looking for the needed path in the file systems of those partitions.

So far so good. But the problem is that if the search encounters a partition that for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init-thing keeps trying to mount that same partition over and over again, for a long time, until it finally throws a tantrum, raises panic, and sets my computer on fire.

On my computer Windows is usually hibernated on the first partition of the first disk. Unfortunately, that is the first partition Ubuntu will encounter in its attempted search through all the partitions. If I remove that hibernation file (which I don't like!), it allows Ubuntu to boot normally.

On closer look, it turns out the culprit is in the file called "lupin-helpers". No mater how I think about it, I find no good reason why it would raise panic from within the loop if a certain partition refuses to mount. What it really needs to do is to just silently ignore it, and move on looking through the rest of the loop.

Posible workaround...

Since Windows installations are most often on the first partition, my first impulse was to simply reverse the device order in which the search loops.

i.e., in "lupin-helpers", change this one line:
---- for dev in $(subdevices "${sysblock}"); do
++++ for dev in $(subdevices "${sysblock}" | tac -s' '); do

That would "fix" the problem for most setups. But that's not really fixing the bug, it's just making the bug less likely to ever manifest itself. A proper solution to the problem is the fix below.

The Fix:

In file "lupin-helpers", change this one line:
---- try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
++++ mount -o $mountoptions $devname $mountpoint || true

I tested that by repackaging the initrd.lz, remastering the iso file, and booting directly from it.
It works flawlesly, as far as I can see.

Even Better:

It was nice when Ubuntu implemented the "iso-scan/filename=" boot option. But the path is only half the problem with finding a file. The knowledge about which device the file is on is also needed. The bootloader can easily pass along that knowledgeto the OS: the UUID of the needed partition.

For example, the Grub2 grub.cfg script can do something like this:

# ... ...
set isopath="/path/to/my/iso/collection"
probe -u $root -s booted_uuid
# ... ...
menuentry "Ubuntu 10.10" {
  set isofile="${isopath}/ubuntu-10.10-desktop-i386.iso"
  loopback loop ${isofile}
  linux ${loop}/casper/vmlinuz booted_uuid=${booted_uuid} \
      iso-scan/filename=${isofile} ${other_boot_options}
  initrd (loop)/casper/initrd.lz
}

When the OS takes over, it would find in its "/proc/cmdline" BOTH the device AND the path. So it won't be necessary to start that whole messy search loop through all the partitions on all the block devices. The OS can go straight to mounting that particular partition. The result is a cleaner and faster boot!

Of course, if for some reason that path is not found on that device, only then the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if, per chance, it goes through the whole loop without finding the needed path, only then it would be the proper time to panic.

Yours,
Purko Balkanski

Related branches

Purko Balkanski (purko) on 2010-11-02
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
Purko Balkanski (purko) on 2010-11-05
description: updated
Changed in initrd-tools (Ubuntu):
status: New → Confirmed
Purko Balkanski (purko) on 2010-11-05
description: updated
Purko Balkanski (purko) on 2010-11-07
description: updated
description: updated

There is another case could make mount failed. The mount command will failed if a CD/DVD device does not have any medium.

the casper-premount/20iso-scan is provided by lupin-casper.

affects: initrd-tools (Ubuntu) → lupin (Ubuntu)
affects: lupin → oem-priority
Changed in oem-priority:
importance: Undecided → Medium
Changed in oem-priority:
status: New → Confirmed
Changed in lupin (Ubuntu):
assignee: nobody → Brian Murray (brian-murray)
status: Confirmed → Triaged
Changed in oem-priority:
status: Confirmed → Triaged
Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
Changed in lupin (Ubuntu):
status: Triaged → Confirmed
Changed in lupin (Ubuntu):
assignee: Brian Murray (brian-murray) → Stéphane Graber (stgraber)
Dmitry Shachnev (mitya57) wrote :

Your branch should be against raring, not precise. If you want to get this SRUed to precise, you should:

(a) get it fixed in raring;
(b) revert the "bump standards version" change, not appropriate for precise.

James M. Leddy (jm-leddy) wrote :

Hi Dmitry,

I've nominated raring and precise. Thanks for your input.

Changed in lupin (Ubuntu):
status: Confirmed → Triaged
James Page (james-page) wrote :

Nothing for ubuntu-sponsors todo here right now; unsubscribing for the time being

Please re-subscribe once fixes have been prepared inline with Dmitry's comment in #3

Cheers

James

James M. Leddy (jm-leddy) wrote :

Dmitry, James,

I've rebased the branch to raring, sorry for the confusion. Also I've resubed sponsors.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lupin - 0.54

---------------
lupin (0.54) saucy; urgency=low

  [ James M Leddy ]
  * casper-premount/20iso-scan: Don't panice the system if try_mount
    function returns error when it encount a CD/DVD device does not
    have any meidum or a partition has a file system does not be
    supported by kernel. This should not panic the system because the
    target file could be in other devices. (LP: #670096)
  * debian/control: bump standards version.
 -- Steve Langasek <email address hidden> Mon, 13 May 2013 22:44:04 -0500

Changed in lupin (Ubuntu):
status: Triaged → Fix Released
Ara Pulido (ara) wrote :

Any chances to have this SRU'ed to Precise?

Ara Pulido (ara) wrote :

Any chance to get this SRU'ed in Precise?

Changed in lupin (Ubuntu Precise):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
James M. Leddy (jm-leddy) wrote :

The precise merge request now has the standards version taken out per comment #3.

Brian Murray (brian-murray) wrote :

I'll upload this to Precise.

Changed in lupin (Ubuntu Precise):
assignee: Canonical Foundations Team (canonical-foundations) → Brian Murray (brian-murray)
importance: Undecided → Medium
status: New → Triaged

Hello Purko, or anyone else affected,

Accepted lupin into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lupin/0.51ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in lupin (Ubuntu Precise):
status: Triaged → Fix Committed
tags: added: verification-needed

I've verified, it works.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lupin - 0.51ubuntu1.1

---------------
lupin (0.51ubuntu1.1) precise-proposed; urgency=low

  * casper-premount/20iso-scan: Don't panic the system if try_mount
    function returns an error when it encounters a CD/DVD device that
    does not have any medium or a partition has a file system that is
    not supported by kernel. This should not panic the system because
    the target file could be in other devices. (LP: #670096)
 -- James M Leddy <email address hidden> Wed, 14 Aug 2013 15:16:53 -0400

Changed in lupin (Ubuntu Precise):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Ara Pulido (ara) on 2013-09-02
Changed in oem-priority:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers