[Bug 670096] Re: Ubuntu fails to boot from ISO if there's a NTFS partition with Windows hibernated on it.

[Dmitry Shachnev]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/670096

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

Status in OEM Priority Project:
  Triaged
Status in OEM Priority Project precise series:
  Triaged
Status in “lupin” package in Ubuntu:
  Confirmed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/670096/+subscriptions