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