x86, Kernel 2.6.8-16, (qemu 0.6.1+20050407): BLKRRPART fails on non-logical partitions
I'm experimenting with the creation (from scratch) of initrd images, for
the purpose of preparing bare-metal-recovery boot devices.
Things are going pretty well, however, I have come a little unstuck with
the partition-editing tools (for the x86 platform) used against the
kernel version 2.6.8-16.
Thus far, my testing has been under the qemu environment with a
virtualised disk (I'd like to perfect as much of the practice as
possible before looking at a sacrificial box).
The problem is this: all the partitioning tools: fdisk, parted, etc,
that I've tried, require a "reboot" before the new partition layout is
picked up.
I believe that the partition changes _are_ being persisted to disk
(because on rebooting the virtual machine, the new partition layout
becomes visible) - however, I'm not sure if this behaviour is "broken as
expected" or if I'm missing something obvious.
(I'm using devfs, fwiw.)
The BLKRRPART ioctl (eg, hdparm -z /dev/hda) fails to pick up changes to
the partition table when those changes involve physical or extended
partition types. Given a pre-existing extended partition, I'm able to
create and manipulate logical partitions within it: the BLKRRPART ioctl
picks up those changes appropriately, as I'd expect.
So: has anyone else seen this behaviour? Is this a known issue? Apart
from introducing a reboot into my recovery process, is there an
alternative way to force a re-read of the partition table? Is this just
a qemu artifact?
Thanks in advance for any assistance,
jan
PS. I'd appreciate a CC: on any responses.
Reply to: