Ubuntu
ubiquity package

Partitions detection is wrong using manual partitioning

Bug #506971 reported by Dave Martin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: ubiquity

ubiquity seems to get existing partition types mixed up when detecting the partition table during manual partitioning. See the attached window dump for what I see. In particular it's detecting a swap partition (82) as fs and an fs partition (83) as swap.

This was observed on http://cdimages.ubuntu.com/ports/daily-live/20100112.2/lucid-desktop-armel+imx51.img

lucid development branch
ubiquity version: 2.1.9
Architecture: armel

Tags: armel
Revision history for this message
Dave Martin (dave-martin-arm) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :

ubiquity doesn't pay a great deal of attention to the type fields in the partition table, but it does pay attention to the partition contents, which tend to be more meaningful these days. Could you please verify what's actually in the partitions in question?

Revision history for this message
Colin Watson (cjwatson) wrote :

Also try 'parted -s /dev/mmcblk0 print'.

Revision history for this message
Dave Martin (dave-martin-arm) wrote :

> ubiquity doesn't pay a great deal of attention to the type
> fields in the partition table, but it does pay attention to
> the partition contents, which tend to be more meaningful
> these days. Could you please verify what's actually in the
> partitions in question?

Unfortunately I had to overwrite that SD card in the meantime.

The reason why the partitions didn't match their content was because I generally pre-partition my SD card in a precise way to make space for boot images; ubiquity doesn't provide the precision I want and can't itself install boot images to the target medium on imx51 (armel). This pre-partitioning results in ubiquity seeing partitions which are uninitialised and so their contents may not match the type fields in the partition table; indeed it is a mistake to interpret the contents of an unitialised partition, but ubiquity has no way to know this.

Of course, the partition types can be overriden now that the bug which was preventing partition creation was fixed.

So maybe there is no bug; it's more a case of the intended behaviour not being what I expect.

If I experience the bug again, I'll try your parted command to see what that generates.

Revision history for this message
Tobin Davis (gruemaster) wrote :

Marked as invalid. Reopen if future images experience this behavior.

Changed in ubiquity (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.