[Parted-maintainers] Bug#549331: Problem reloading extended partitions

Anthony L. Awtrey tony at awtrey.com
Sat Oct 3 19:17:03 UTC 2009


I've traced the issue down to this...

In the lenny package partman base-128lenny1, in the parted_server.c 
there is a function command_commit() that in turn calls 
ped_disk_commit() from libparted.

In the lenny package parted 1.8.8.git.2008.03.24, in libparted/disk.c 
the function ped_disk_commit() calls both ped_disk_commit_to_dev() to 
write the partition to the disk and ped_disk_commit_to_os() to make the 
kernel load the modified partition table.

The partition table is being written correctly to the disk. When running 
fdisk -l against the device node, the partitioning matches what partman 
has tried to do, but the kernel (via /dev and /proc/partitions) still 
has an orphan logical partition (/dev/sda5) defined.


The error occurs when the ped_disk_commit_to_os() function fails to read 
the updated partition information correctly. There is a comment above 
the function that indicates that the BLKRRPART ioctl was previously used 
in ancient Linux versions to reread the whole partition table.

So to try out a theory, I built another custom debian-installer which 
included a udeb version of this package:

  http://gitorious.org/blkrrpart

It is a very simple utility that calls the BLKRRPART ioctl and can run 
in the limited d-i environment. I then recreated the error and noted 
that as expected the orphan logical partition /dev/sda5 remains. I ran 
the blkrrpart utility, and *poof* the kernel sees the new partition 
table without a reboot.


Digging in further, it appears the ped_disk_commit_to_os() ends up 
calling libparted/arch/linux.c function linux_disk_commit() which in 
turn calls _disk_sync_part_table() which in turn calls 
_blkpg_add_partition() and I see my error string "Error informing the 
kernel about modifications..." when the _blkpg_part_command() function 
fails.

Okay, so now why don't all the partitions get removed properly? I see in 
the _disk_sync_part_table() function a for iterator that should 
technically remove all partitions using _blkpg_remove_partition() ...

Ahhhh! Could the ped_disk_get_last_partition_num() function be returning 
my *current* last partition (after it's been modified) and not the last 
actual partition defined for the disk?

Digging deeper...

T





More information about the Parted-maintainers mailing list