| 2008-10-12 13:55:25 |
Tony Lewis |
bug |
|
|
added bug |
| 2008-12-16 22:42:52 |
Hugo Josefson |
devmapper: status |
New |
Confirmed |
|
| 2008-12-16 22:42:52 |
Hugo Josefson |
devmapper: statusexplanation |
|
|
|
| 2008-12-17 16:21:40 |
Hugo Josefson |
bug |
|
|
assigned to initramfs-tools |
| 2008-12-17 16:29:00 |
Hugo Josefson |
devmapper: status |
Confirmed |
Invalid |
|
| 2008-12-17 16:29:00 |
Hugo Josefson |
devmapper: statusexplanation |
|
This bug is not the fault of the dmsetup tool. It belongs with initramfs-tools. |
|
| 2008-12-17 16:30:26 |
Hugo Josefson |
initramfs-tools: status |
New |
Confirmed |
|
| 2008-12-17 16:30:26 |
Hugo Josefson |
initramfs-tools: statusexplanation |
|
This bug is not the fault of the dmsetup tool. It belongs with initramfs-tools, which should find a better way of determining all PV:s required to start the VG where a particular LV resides. |
|
| 2008-12-17 16:36:56 |
Hugo Josefson |
description |
Scenario:
My root fs is on LVM which has some LVs (including root) over a single VG over a single PV which is a physical partition.
I create an encrypted PV, and extend the VG with it. I do not, however, migrate any part of the root fs to the new PV.
"dmsetup deps" shows that the root fs depends only on the physical partition, not on the encrypted partition. However, the VG cannot start without that encrypted PV being available. "dmsetup deps" does not accurately detect that the root fs now depends on the encrypted PV being available.
This has bad consequences for booting. If I run "update-initramfs -u" it uses "dmsetup deps", and fails to note that there is now a "cryptroot" element involved. System will not boot (Recovery is possible using a live CD to then remove the encrypted partition from the VG)
This is probably a bug with dmsetup. Alternately you could consider it a bug with initramfs-tools, which needs a better way to detect this scenario. |
Scenario:
My root fs is on LVM which has some LVs (including root) over a single VG over a single PV which is a physical partition.
I create an encrypted PV, and extend the VG with it. I do not, however, migrate any part of the root fs to the new PV.
"dmsetup deps" shows that the root fs depends only on the physical partition, not on the encrypted partition. However, the VG cannot start without that encrypted PV being available. "dmsetup deps" does not accurately detect that the root fs now depends on the encrypted PV being available.
This has bad consequences for booting. If I run "update-initramfs -u" it uses "dmsetup deps", and fails to note that there is now a "cryptroot" element involved. System will not boot (Recovery is possible using a live CD to then remove the encrypted partition from the VG)
This is probably a bug with dmsetup. Alternately you could consider it a bug with initramfs-tools, which needs a better way to detect this scenario.
....
UPDATE by hugojosefson: This bug has now been moved to initramfs-tools, so that the problem can be solved in the method get_lvm_deps() in /usr/share/initramfs-tools/hooks/cryptroot. That method could use some other way of determining a LV's dependencies, instead of the current "dmsetup deps". |
|
| 2009-02-06 21:12:44 |
Hugo Josefson |
cryptsetup: status |
New |
Confirmed |
|
| 2009-02-06 21:12:44 |
Hugo Josefson |
cryptsetup: statusexplanation |
|
|
|
| 2009-02-06 21:12:59 |
Hugo Josefson |
initramfs-tools: status |
Confirmed |
Invalid |
|
| 2009-02-06 21:12:59 |
Hugo Josefson |
initramfs-tools: statusexplanation |
This bug is not the fault of the dmsetup tool. It belongs with initramfs-tools, which should find a better way of determining all PV:s required to start the VG where a particular LV resides. |
|
|
| 2009-02-06 21:13:50 |
Hugo Josefson |
description |
Scenario:
My root fs is on LVM which has some LVs (including root) over a single VG over a single PV which is a physical partition.
I create an encrypted PV, and extend the VG with it. I do not, however, migrate any part of the root fs to the new PV.
"dmsetup deps" shows that the root fs depends only on the physical partition, not on the encrypted partition. However, the VG cannot start without that encrypted PV being available. "dmsetup deps" does not accurately detect that the root fs now depends on the encrypted PV being available.
This has bad consequences for booting. If I run "update-initramfs -u" it uses "dmsetup deps", and fails to note that there is now a "cryptroot" element involved. System will not boot (Recovery is possible using a live CD to then remove the encrypted partition from the VG)
This is probably a bug with dmsetup. Alternately you could consider it a bug with initramfs-tools, which needs a better way to detect this scenario.
....
UPDATE by hugojosefson: This bug has now been moved to initramfs-tools, so that the problem can be solved in the method get_lvm_deps() in /usr/share/initramfs-tools/hooks/cryptroot. That method could use some other way of determining a LV's dependencies, instead of the current "dmsetup deps". |
Scenario:
My root fs is on LVM which has some LVs (including root) over a single VG over a single PV which is a physical partition.
I create an encrypted PV, and extend the VG with it. I do not, however, migrate any part of the root fs to the new PV.
"dmsetup deps" shows that the root fs depends only on the physical partition, not on the encrypted partition. However, the VG cannot start without that encrypted PV being available. "dmsetup deps" does not accurately detect that the root fs now depends on the encrypted PV being available.
This has bad consequences for booting. If I run "update-initramfs -u" it uses "dmsetup deps", and fails to note that there is now a "cryptroot" element involved. System will not boot (Recovery is possible using a live CD to then remove the encrypted partition from the VG)
This is probably a bug with dmsetup. Alternately you could consider it a bug with initramfs-tools, which needs a better way to detect this scenario.
....
UPDATE by hugojosefson: This bug has now been moved to project "cryptsetup (Ubuntu)", so that the problem can be solved in the method get_lvm_deps() in /usr/share/initramfs-tools/hooks/cryptroot. That method could use some other way of determining a LV's dependencies, instead of the current "dmsetup deps". |
|
