You have been subscribed to a public bug:
I am currently running CentOS 6.x on my primary workstation. I want to
replace CentOS with Ubuntu after I found that Ubuntu has better software
repositories.
I booted up my workstation with Ubuntu 12.10 Live to test and see if
Ubuntu will recognize my CentOS encrypted luks container and determine
whether or not I can replace CentOS with Ubuntu. My system root and home
partitions are logical volumes stored in a luks container that was
originally created with Red Hat's Partitioning Tool.
I discovered that Ubuntu's Partitioning Tool does not recognize Red
Hat's encrypted luks container and will not allow Ubuntu to be installed
onto an existing logical volume. When experimenting with Ubuntu's
Partitioning Tool options to get the installer to recognize Red Hat's
partitioning scheme, I accidentally clicked the "-" next to "change" and
the Partitioning Tool recalculated the luks container to "free space". I
clicked "revert" over and over again, but to no avail. Ubuntu's
Partitioning Tool trashed my partition table and would not let me undo
the changes. I then clicked "quit" to exit out of the Advanced
Partitioning Tool window.
I tried to open the luks container, but Ubuntu's Partitioning Tool
resized the container to below the Payload Offset's boundary and
therefore the encryption failed. I then used fdisk to recreate the
partition table that the luks container is held in, starting at the same
cylinder, but with the full size of the original container. I can now
successfully use "cryptsetup luksOpen /dev/sda2 crypt" to open the luks
container, but my logical volumes have vanished.
I was able to reproduce part of this problem (Partitioning Tool changes
partition id and will not revert): When changes are made to an existing
LVM physical volume with Ubuntu's Advanced Partitioning Tool, the
"revert" function is defective and will not revert the changes made to
the partition table. Ubuntu's Partitioning Tool changes the partition
identifier from hex code 8E (Linux LVM) to a hex code of 83 (Linux).
This causes the beginning sector of the physical volume not to line up
with where it used to be, and the logical volumes are unreadable as a
result of this bug.
Can someone who is knowledgeable about the ins and outs of Ubuntu's
Advanced Partitioning Tool please inform me as to exactly what this tool
did when it recalculated my partitions. Even after I used fdisk to
recreate the partition table with the correct size and changed the
partition identifier from 83 (Linux) to 8E (Linux LVM), my logical
volumes are still unavailable. When I use "dd if=/dev/mapper/crypt
bs=512 count=255 skip=1 of=./lvm.recovery" to recover the LVM backup
headers, there is no reference to any LVM metadata.
I am very puzzled as to exactly how Ubuntu's Partitioning Tool scrabbled
my partition table and why it can't be recreated with fdisk. I can't
mount /dev/mapper/crypt as it appears to be misaligned. I tried every
backup superblock with e2fsck and none work (Bad magic number in super-
block). There must be a way to reverse this partition alignment problem
since the only thing that Ubuntu's Partitioning Tool changed is the size
and partition id?
Perhaps someone who is knowledgeable about Ubuntu's Partitioning Tool
can let me know how to reverse the damage this tool has caused to my
partition table.
** Affects: unity (Ubuntu)
Importance: Undecided
Status: Incomplete
** Tags: bot-comment
--
Ubuntu's Partitioning Tool does not revert changes to partition table
https://bugs.launchpad.net/bugs/1179122
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
