Comment 1 for bug 655950

Revision history for this message
Erick Brunzell (lbsolost) wrote : Re: Maverick ubiquity confusion w/ auto-resize option

Upon more testing with the Ubuntu Desktop i386 [20101007] iso I see there is an actual bug in the ointment.

I chose to auto-resize drive sdb which I'd been using for iso-testing and it had two Ubuntu's on it, each with a new swap, well actually the second would have been using both swap partitions. You know how "auto" installs work, you'll end up with a new swap for each new install, etc.

The graphic that consists of a "slider" to change the partition size showed sdb1 on the left and sdb2 on the right so I thought, "hmmm it's going to create a primary partition for the new install"? That would be odd, but it didn't, it did what I'm used to seeing:

lance@lance-desktop:~$ sudo parted /dev/sdb print
[sudo] password for lance:
Model: ATA WDC WD800JB-00JJ (scsi)
Disk /dev/sdb: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 19.3GB 19.3GB primary ext4
 2 19.3GB 80.0GB 60.7GB extended
 8 19.3GB 37.8GB 18.5GB logical ext4
 9 37.8GB 38.7GB 849MB logical linux-swap(v1)
 6 38.7GB 75.1GB 36.4GB logical ext4
 7 75.1GB 76.7GB 1604MB logical linux-swap(v1)
 5 76.7GB 80.0GB 3305MB logical linux-swap(v1)

That is it created sda8 as "/" and sda9 as swap, both as logical partitions, so it's simply displaying bogus info. How confusing that might be to a total noob I'm unsure.

Just to see how reproducible this was I selected my drive sda which I'd never use auto-resize on anyway:

lance@lance-desktop:~$ sudo parted /dev/sda print
Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 32.3kB 21.5GB 21.5GB primary ext3 boot
 2 21.5GB 42.9GB 21.5GB primary ext3
 3 42.9GB 151GB 108GB primary ext3
 4 151GB 500GB 349GB extended
14 151GB 172GB 21.1GB logical ext4
15 172GB 193GB 21.1GB logical ext4
16 193GB 215GB 21.4GB logical ext4
17 215GB 236GB 21.4GB logical ext4
13 236GB 258GB 22.0GB logical ext4
12 258GB 280GB 21.6GB logical ext3
11 280GB 301GB 21.7GB logical ext3
10 301GB 323GB 21.8GB logical ext3
 5 323GB 378GB 55.1GB logical ext3
 6 378GB 432GB 53.6GB logical ext3
 7 432GB 487GB 54.9GB logical ext3
 8 487GB 498GB 10.7GB logical ext3
 9 498GB 500GB 2517MB logical linux-swap(v1)

Ridiculous I know but I do a lot of testing and VM's do a poor job of testing actual hardware. Anyway, since sda3 is the largest partition, the screen after selecting "auto-resize" showed it was splitting sda3 into sda3 and sda4. Of course that's not possible since sda4 is an extended partition and since I have 3 primaries and an extended already there would be no way to split sda3 and simply "renumber" drives.

Of course I quit the install because I don't really want to start over with that drive even though my data is backed up, so I have no idea what would have really happened.

Next I'm going to try just creating 3, and then 4, empty NTFS partitions on that 80 GB drive to see what "auto-resize" tries to do. I really wish I could get some other folks to try and reproduce this.

I'm kind of thinking that the auto-resize option should just be unavailable if a certain number and/or layout of partitions exist on the selected drive.

I also realize that it's probably not possible to fix this with only a few days until release but I'll try to reproduce this in some more sane "mock-up-scenarios" and maybe someone can come up with something coherent for the release notes.

I would have been testing this earlier but due to bug 640807 I'd only been able to test ubiquity in a VM since about September 16th.