parted doesn't handle extended partitions that don't leave at least a 2 sector gap
Bug #324987 reported by
TJ
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
parted (Ubuntu) |
Triaged
|
Low
|
Phillip Susi |
Bug Description
Parted fails to update the kernel partition table when an extended partition starts on the sector immediately following the EBR instead of leaving two sectors for LILO. This can cause otherwise apparently fine partitions to get "lost" during installation when parted deletes the kernel partition table and tries to recreate it and fails.
Changed in parted: | |
assignee: | nobody → kamion |
Changed in parted (Ubuntu): | |
assignee: | Colin Watson (cjwatson) → nobody |
To post a comment you must log in.
The previous experience was with the Jaunty alpha-3 live-CD.
The daily 0203.1 live-CD (amd64) displays the same behaviour, and in a much more simplified scenario. No use of LVM or encryption, just:
/dev/sda1 Windows Recovery ntfs ~9GB
/dev/sda2 Windows Vista ntfs ~28GB
/dev/sda3 Linux swap ~4GB
/dev/sda4 extended
/dev/sda5 Linux ext3 ~125MB
/dev/sda6 Linux ext3
And during manual partitioning assign sda5 to /boot/, and sda6 to /.
When the partitioning begins it fails silently an returns to the Wizard partitioning page.
Checking /proc/partitions reveals that both sda5 and sda6 are now missing:
Before:
major minor #blocks name
7 0 690608 loop0
8 0 390711384 sda
8 1 9764864 sda1
8 2 28738560 sda2
8 3 4194304 sda3
8 4 1 sda4
8 5 122880 sda5
8 6 347889719 sda6
After:
major minor #blocks name
7 0 690608 loop0
8 0 390711384 sda
8 1 9764864 sda1
8 2 28738560 sda2
8 3 4194304 sda3
8 4 1 sda4