Jaunty "largest continuous free space" graphic is still incorrect
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ubiquity (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: ubiquity
In the latest Jaunty beta, as with the Intrepid release, when the installer gets to step 4 of 7 (partitioning) the graphic for installing in the "largest continuous free space" is totally incorrect.
Because a friend and prospective Ubuntu user alerted me to this problem, I had to see for myself. I created a sda with a couple of 100GB Windows partitions on it and 440GB free space intending to install Ubuntu there. When the installer gets to the partitioning page (step 4 of 7) I see a colorful BEFORE graphic showing my 2 Win partitions and the free space. And since the default partition scheme is to use the whole disk for Ubuntu it show the AFTER graphic as blue signifying 100% of the drive will be used for the Ubuntu install. So far, so good.
But since I only want to install Ubuntu in the free space, I choose the next option which is to install in the largest continuous free space. But instead of the AFTER graphic changing to reflect my new choice, it stays the same as before - it tells me that the entire drive will be used for the Ubuntu installation!
Wow, no wonder my friend was confused!
Now in my test install I just plowed ahead even though I was pretty sure that the partition graphic was in error. Sure enough, Ubuntu installed just fine in the free space as I had instructed it to. It was the graphic that was totally in error.
Think of the experienced Windows user who has gone ahead and created some free space on his own just for his new Ubuntu installation only to believe that his Windows partitions will be overwritten. As bad as this is for new users this bug has been around since before Intrepid!!!!!!! See bug 289663 for more. I just can't understand how a bug that might turn off new users can be allowed to remain unresolved for so long.
| Colin Watson (cjwatson) wrote | #1 |
Thanks for your report, but I think the existence of bug 289663 is quite enough. Deliberately filing duplicate bugs doesn't really help to draw our attention to a problem - on the contrary, it means that we have to spend time marking duplicates rather than fixing bugs, and it's harder for us to find problems in the pile. I'll mark this as a duplicate and see if we can get something done about bug 289663 (since I also spotted it in carried-over release notes from 8.10.)