| 2010-11-02 19:27:00 |
Purko Balkanski |
bug |
|
|
added bug |
| 2010-11-02 20:44:40 |
Purko Balkanski |
description |
Binary 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 in the device order BEFORE the partition on which the Ubuntu's "filesystem.squashfs" resides, ...
... AND that partition contains a supported file system, ...
... AND that partition is for some reason not able to be mounted, ...
that causes the booting process to panic and fail.
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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter. |
Binary 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) logically before the partition on which "filesystem.squashfs" resides, ...
... 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:45:00 |
Purko Balkanski |
description |
Binary 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) logically before the partition on which "filesystem.squashfs" resides, ...
... 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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) logically before the partition on which "filesystem.squashfs" resides,
... 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:45:31 |
Purko Balkanski |
description |
Binary 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) logically before the partition on which "filesystem.squashfs" resides,
... 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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) logically before the partition on which "filesystem.squashfs" resides,
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:45:56 |
Purko Balkanski |
description |
Binary 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) logically before the partition on which "filesystem.squashfs" resides,
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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) logically before the partition on which "filesystem.squashfs" resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:46:20 |
Purko Balkanski |
description |
Binary 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) logically before the partition on which "filesystem.squashfs" resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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) logically before the partition on which filesystem.squashfs resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:46:59 |
Purko Balkanski |
description |
Binary 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) logically before the partition on which filesystem.squashfs resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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 on which filesystem.squashfs resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-02 20:48:34 |
Purko Balkanski |
description |
Binary 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 on which filesystem.squashfs resides
...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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
Binary 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
|
| 2010-11-03 06:43:10 |
Gary M |
bug |
|
|
added subscriber Gary M |
| 2010-11-05 03:33:33 |
Purko Balkanski |
description |
Binary 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, if that search encounters a partition which for some reason can't be mounted, instead of silently ignoring that partition and moving on, the init script starts 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 would 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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 that's only half the problem with finding a file. The knowledge about which device the file is on is also needed.
So, it would be really nice if the bootloader would tell the OS which partition was currently active at the time. Let's say, for example, my Grub script would pass, a "grub2-root=" parameter, like this:
linux ${someplace}/casper/vmlinuz grub2-root=${root} iso-scan/filename=${isofile} ${other_boot_options}
initrd ${whatever}/casper/initrd.lz
When the OS takes over, it would find in "/proc/cmdline" BOTH the device AND the path.
(In my example, the OS would see "... grub2root=hd2,4 iso-scan/filename=/path/to/my/distro.iso ...")
That way 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 partition, (in this example, /dev/sdc4) and using the path on it. Cleaner and faster boot!
Of course, if for some reason that path is not found on that device, THEN the init script could go through that same loop as before. But definitely without raising any panic from within the loop! And if it goes through the whole loop without finding the needed path, only then would be the proper time to panic.
Yours,
Purko Balkanski
(ivan at y3klimousine dot com)
Note: I suggested the name "grub2root=" to avoid possible confusion coming from the way legacy-grub names its partitions. (Legacy-grub would have named that same partition in the example as "hd2,3"). For completeness, we could also have the OS recognize a "legacy-grub-root=" parameter.
|
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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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:
menuentry "Ubuntu 10.10" {
set isofile="/path/to/my/iso-dir/ubuntu-10.10-desktop-i386.iso"
loopback loop ${isofile}
probe -u $root -s bootloader-uuid
linux ${loop}/casper/vmlinuz bootloader-uuid=${bootloader-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
|
|
| 2010-11-05 03:36:55 |
Purko Balkanski |
initrd-tools (Ubuntu): status |
New |
Confirmed |
|
| 2010-11-05 03:57:50 |
Purko Balkanski |
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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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:
menuentry "Ubuntu 10.10" {
set isofile="/path/to/my/iso-dir/ubuntu-10.10-desktop-i386.iso"
loopback loop ${isofile}
probe -u $root -s bootloader-uuid
linux ${loop}/casper/vmlinuz bootloader-uuid=${bootloader-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
|
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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 bootloader-uuid
# ... ...
menuentry "Ubuntu 10.10" {
set isofile="${isopath}/ubuntu-10.10-desktop-i386.iso"
loopback loop ${isofile}
linux ${loop}/casper/vmlinuz bootloader-uuid=${bootloader-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
|
|
| 2010-11-07 06:48:39 |
Purko Balkanski |
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 line:
for dev in $(subdevices "${sysblock}"); do
to:
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", replace this line:
try_mount "$devname" "$mountpoint" "$mountoptions" || return 1
...with the following:
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 bootloader-uuid
# ... ...
menuentry "Ubuntu 10.10" {
set isofile="${isopath}/ubuntu-10.10-desktop-i386.iso"
loopback loop ${isofile}
linux ${loop}/casper/vmlinuz bootloader-uuid=${bootloader-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
|
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
|
|
| 2010-11-07 06:52:35 |
Purko Balkanski |
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
|
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
|
|
| 2013-03-08 06:26:36 |
Launchpad Janitor |
branch linked |
|
lp:~ossug-hychen/ubuntu/precise/lupin/fix-670096 |
|
| 2013-03-08 06:28:56 |
Hsin-Yi, Chen (hychen) |
affects |
initrd-tools (Ubuntu) |
lupin (Ubuntu) |
|
| 2013-03-08 09:19:29 |
Hsin-Yi, Chen (hychen) |
bug task added |
|
lupin |
|
| 2013-03-08 09:20:43 |
Hsin-Yi, Chen (hychen) |
affects |
lupin |
oem-priority |
|
| 2013-03-08 09:22:27 |
Hsin-Yi, Chen (hychen) |
oem-priority: importance |
Undecided |
Medium |
|
| 2013-03-08 09:22:40 |
Hsin-Yi, Chen (hychen) |
nominated for series |
|
oem-priority/precise |
|
| 2013-03-08 09:22:40 |
Hsin-Yi, Chen (hychen) |
bug task added |
|
oem-priority/precise |
|
| 2013-03-08 09:23:28 |
Hsin-Yi, Chen (hychen) |
oem-priority/precise: importance |
Undecided |
Medium |
|
| 2013-03-08 09:23:39 |
Hsin-Yi, Chen (hychen) |
bug |
|
|
added subscriber OEM Priority Team |
| 2013-03-11 21:59:32 |
James M. Leddy |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2013-03-15 20:01:42 |
James M. Leddy |
oem-priority: status |
New |
Confirmed |
|
| 2013-03-15 20:01:44 |
James M. Leddy |
oem-priority/precise: status |
New |
Confirmed |
|
| 2013-03-15 20:01:52 |
James M. Leddy |
lupin (Ubuntu): assignee |
|
Brian Murray (brian-murray) |
|
| 2013-03-15 20:01:57 |
James M. Leddy |
lupin (Ubuntu): status |
Confirmed |
Triaged |
|
| 2013-03-15 20:02:00 |
James M. Leddy |
oem-priority: status |
Confirmed |
Triaged |
|
| 2013-03-15 20:02:02 |
James M. Leddy |
oem-priority/precise: status |
Confirmed |
Triaged |
|
| 2013-03-18 17:58:16 |
James M. Leddy |
oem-priority: assignee |
|
James M. Leddy (jm-leddy) |
|
| 2013-03-18 18:25:36 |
James M. Leddy |
lupin (Ubuntu): status |
Triaged |
Confirmed |
|
| 2013-03-20 15:34:55 |
Brian Murray |
lupin (Ubuntu): assignee |
Brian Murray (brian-murray) |
Stéphane Graber (stgraber) |
|
| 2013-03-20 15:35:01 |
Brian Murray |
bug |
|
|
added subscriber Brian Murray |
| 2013-03-22 15:13:13 |
James M. Leddy |
nominated for series |
|
Ubuntu Precise |
|
| 2013-03-22 15:13:13 |
James M. Leddy |
nominated for series |
|
Ubuntu Raring |
|
| 2013-03-22 16:43:41 |
James M. Leddy |
lupin (Ubuntu): status |
Confirmed |
Triaged |
|
| 2013-03-25 12:00:18 |
James Page |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2013-03-27 07:29:57 |
Ibrahim M. Ghazal |
bug |
|
|
added subscriber Ibrahim M. Ghazal |
| 2013-04-01 06:00:52 |
Launchpad Janitor |
branch linked |
|
lp:~jm-leddy/ubuntu/raring/lupin/fix-670096 |
|
| 2013-04-01 06:02:02 |
James M. Leddy |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2013-05-06 10:04:43 |
Shih-Yuan Lee |
bug |
|
|
added subscriber Shih-Yuan Lee |
| 2013-05-08 21:28:07 |
James M. Leddy |
oem-priority/precise: assignee |
|
James M. Leddy (jm-leddy) |
|
| 2013-05-14 04:38:58 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/saucy/lupin/saucy-proposed |
|
| 2013-05-14 04:40:21 |
Launchpad Janitor |
lupin (Ubuntu): status |
Triaged |
Fix Released |
|
| 2013-07-22 10:55:46 |
Ara Pulido |
bug task added |
|
lupin (Ubuntu Precise) |
|
| 2013-08-09 10:00:26 |
Ara Pulido |
lupin (Ubuntu Precise): assignee |
|
Canonical Foundations Team (canonical-foundations) |
|
| 2013-08-14 19:22:02 |
Launchpad Janitor |
branch linked |
|
lp:~jm-leddy/ubuntu/precise/lupin/fix-670096 |
|
| 2013-08-14 19:24:44 |
James M. Leddy |
branch unlinked |
lp:~ossug-hychen/ubuntu/precise/lupin/fix-670096 |
|
|
| 2013-08-14 21:13:22 |
Brian Murray |
lupin (Ubuntu Precise): assignee |
Canonical Foundations Team (canonical-foundations) |
Brian Murray (brian-murray) |
|
| 2013-08-14 21:13:25 |
Brian Murray |
lupin (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2013-08-14 21:13:28 |
Brian Murray |
lupin (Ubuntu Precise): status |
New |
Triaged |
|
| 2013-08-14 21:13:30 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2013-08-15 22:10:35 |
Brian Murray |
lupin (Ubuntu Precise): status |
Triaged |
Fix Committed |
|
| 2013-08-15 22:10:37 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-08-15 22:10:39 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2013-08-15 22:10:42 |
Brian Murray |
tags |
boot grub2 iso loop |
boot grub2 iso loop verification-needed |
|
| 2013-08-15 22:24:29 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/lupin |
|
| 2013-08-20 15:25:22 |
Brian Murray |
tags |
boot grub2 iso loop verification-needed |
boot grub2 iso loop verification-done |
|
| 2013-08-21 11:07:48 |
Mantas Kriaučiūnas |
bug |
|
|
added subscriber Mantas Kriaučiūnas |
| 2013-08-21 11:07:54 |
Mantas Kriaučiūnas |
bug |
|
|
added subscriber Baltix GNU/Linux system developers |
| 2013-08-27 14:21:57 |
Launchpad Janitor |
lupin (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2013-08-27 14:22:02 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-09-02 11:27:22 |
Ara Pulido |
oem-priority: status |
Triaged |
Fix Released |
|
| 2013-09-02 11:27:28 |
Ara Pulido |
oem-priority/precise: status |
Triaged |
Fix Released |
|
