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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
