partitions that overflow disk not handled gracefully

Bug #366282 reported by Steveire on 2009-04-24
This bug affects 6 people
Affects Status Importance Assigned to Milestone
partman-base (Ubuntu)

Bug Description

When I get to the partitioning stage of the install process, the partitioner does not correctly detect my existing partition table.

Instead I get only an option to format the entire disk or manually create a new partition table.

This guy seems to have the same issue:



Steveire (steveire) wrote :
Steveire (steveire) wrote :
Steveire (steveire) wrote :
Colin Watson (cjwatson) wrote :

Please attach the output of the following command:

sudo od -Ax -tx1 -N512 /dev/sda

affects: ubiquity (Ubuntu) → parted (Ubuntu)
Changed in parted (Ubuntu):
status: New → Incomplete
Colin Watson (cjwatson) wrote :

OK, now I need to get the extended boot records in sequence. This may take a few iterations before I have the whole thing. Start with this:

  sudo dd if=/dev/sda bs=512 skip=3979998 count=1 | od -tx1 -Ax

Changed in parted (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Steveire (steveire) wrote :
Colin Watson (cjwatson) wrote :
Download full text (6.0 KiB)

Hmm, I do apologise; I seem to have done some maths completely wrong somewhere along the line there. This is the correct command:

  sudo dd if=/dev/sda bs=512 skip=60275880 count=1 | od -tx1 -Ax

To answer your question on IRC, there's usually one extended boot record per extended partition.

If you're able to follow this kind of thing through for yourself, perhaps it would help if I gave you the tools to do the job yourself. (If you can't follow this, you can ignore the rest of this comment and just follow my instructions above, and we'll do it the slow way.) What I'm doing here is looking for the extended partition record in your master boot record; the result of doing all of this is that I should be able to plug the information into a test file here and run parted on it to (hopefully) simulate your problem. The four partition records in each boot record begin at offset 0x1BE, and occupy 16 bytes each. The fifth byte of each partition record is the partition type, and is either 0x05, 0x0F, or 0x85 for an extended partition. In your case we can see that the first extended partition is described by this partition record, starting at offset 0x1EE:

  00 fe ff ff 0f fe ff ff a8 bc 97 03 da b9 61 0a

The ninth to twelfth bytes identify the first sector of the extended partition; they're least-significant-byte-first, so you can convert to decimal like this:

  $ echo $((0x0397BCA8))

The extended boot records are almost exactly the same for our purposes, except that the sector addresses there are relative to the start of the first extended boot record. This means that in your case you need to add 60275880 to the address you get from each extended boot record.

If a record doesn't end with "55 aa", then you've made a mistake and should go back and recheck your figures.

Here's a full worked example for my disk:

  $ sudo fdisk -l /dev/sda

  Disk /dev/sda: 80.0 GB, 80026361856 bytes
  255 heads, 63 sectors/track, 9729 cylinders
  Units = cylinders of 16065 * 512 = 8225280 bytes
  Disk identifier: 0x10000000

     Device Boot Start End Blocks Id System
  /dev/sda1 1 14 112423+ de Dell Utility
  /dev/sda2 15 276 2097152 7 HPFS/NTFS
  Partition 2 does not end on cylinder boundary.
  /dev/sda3 * 276 2707 19531250 7 HPFS/NTFS
  /dev/sda4 2708 9729 56404215 5 Extended
  /dev/sda5 2708 7571 39070048+ 83 Linux
  /dev/sda6 9437 9729 2353491 82 Linux swap / Solaris
  /dev/sda7 7572 9436 14980581 83 Linux

  Partition table entries are not in disk order
  $ sudo od -Ax -tx1 -N512 /dev/sda
  000000 eb 48 90 d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00
  000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00
  000020 bd be 07 80 7e 00 00 7c 0b 0f 85 10 01 83 c5 10
  000030 e2 f1 cd 18 88 56 00 55 c6 46 11 05 c6 46 03 02
  000040 ff 00 00 20 01 00 00 00 00 02 fa 90 90 f6 c2 80
  000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc
  000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 be 7f 7d
  000070 e8 34 01 f6 c2 80 74 54 b4 41 bb aa 55 cd 13 5a
  000080 52 7...


Steveire (steveire) wrote :

Thanks for the info. Interesting stuff. I've attached the output.

Steveire (steveire) wrote :

Is there anything I can do to push this report along? It's going to become more important for me soon.

Should the status be changed to 'Open'?

Colin Watson (cjwatson) on 2009-06-08
Changed in parted (Ubuntu):
importance: Undecided → High
status: Incomplete → Confirmed
Colin Watson (cjwatson) wrote :

This is because partition 8 on this disk overflows the disk slightly (by about 10KB, if I'm doing my arithmetic correctly), and libparted rejects such things.

I note that the Linux kernel simply truncates partitions like this now:

Perhaps libparted should be able to do the same? I'll contact upstream and ask.

Steveire (steveire) wrote :

Output of fdisk -l:

stephen@wopr:~/Desktop$ sudo fdisk -l /dev/sda
[sudo] password for stephen:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x28000000

   Device Boot Start End Blocks Id System
/dev/sda1 1 15 120456 6 FAT16
/dev/sda2 16 1319 10474376+ 7 HPFS/NTFS
/dev/sda3 * 1321 3752 19531244+ 7 HPFS/NTFS
/dev/sda4 3753 14594 87088365 f W95 Ext'd (LBA)
/dev/sda5 3753 4360 4883728 83 Linux
/dev/sda6 4361 13901 76638048 83 Linux
/dev/sda7 13902 14266 2931812 82 Linux swap / Solaris
/dev/sda8 14267 14594 2620416 c W95 FAT32 (LBA)

Colin Watson (cjwatson) wrote :
summary: - Install partitioner does not detect existing partition table
+ partitions that overflow disk not handled gracefully
Colin Watson (cjwatson) wrote :

A passable simulation of Steveire's disk may be constructed as follows. Save as 'mbr', split up the pieces of and save them as 'ebr1', 'ebr2', 'ebr3', and 'ebr4', and use the revod script in the previous attachment:

  dd if=/dev/zero of=disk bs=1 count=0 seek=120034124288
  revod <mbr | dd of=disk conv=notrunc bs=512 count=1
  revod <ebr1 | dd of=disk conv=notrunc bs=512 count=1 seek=60275880
  revod <ebr2 | dd of=disk conv=notrunc bs=512 count=1 seek=70043400
  revod <ebr3 | dd of=disk conv=notrunc bs=512 count=1 seek=223319565
  revod <ebr4 | dd of=disk conv=notrunc bs=512 count=1 seek=229197717

I get the same problem with the install cd of 9.10. No partitions are detected.

Colin Watson (cjwatson) on 2012-05-17
Changed in parted (Ubuntu):
assignee: Colin Watson (cjwatson) → nobody
Phillip Susi (psusi) on 2012-05-17
Changed in parted (Ubuntu):
assignee: nobody → Phillip Susi (psusi)
status: Confirmed → In Progress

my installation will not go further than 50% when copying files, because i think the setup hasnt detected what a maximum of partitions are, always got a message that i have a faulty disk, and that i can buy some cleanup products in most electronic shops.

Phillip Susi (psusi) wrote :

As far as parted goes, this was fixed some time ago; it now throws an exception notifying the user of the error, and gives them the chance to ignore it so they can print the existing table, and delete the offending partition. It seems however, that parted_server ignores the error ( not even logging it ).

affects: parted (Ubuntu) → partman-base (Ubuntu)
Changed in partman-base (Ubuntu):
assignee: Phillip Susi (psusi) → nobody
status: In Progress → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers