[debian-hurd-Bugs][311673] partition table is not reloaded after changes
Bugs item #311673, was changed at 2009-05-15 01:04 by Thomas Schwinge
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=411594&aid=311673&group_id=30628
>Status: Closed
Priority: 1
Submitted By: Marc Dequènes (duck)
>Assigned to: Thomas Schwinge (tschwinge-guest)
Summary: partition table is not reloaded after changes
Category: None
Group: None
>Resolution: Duplicate
Initial Comment:
Using parted i was able to create a partition table to a new disk (empty KVM disk), create a ext2 partition, but could not mkfs before reboot. I don't know if this is parted-related or not.
----------------------------------------------------------------------
>Comment By: Thomas Schwinge (tschwinge-guest)
Date: 2009-05-19 19:19
Message:
As this is not really a Debian porting issue, I moved this to upstream: <http://www.gnu.org/software/hurd/open_issues/blkrrpart_ioctl.html>
----------------------------------------------------------------------
Comment By: Thomas Schwinge (tschwinge-guest)
Date: 2009-05-17 22:19
Message:
I already experienced this with fdisk before. With fdisk and friends the problem is that we don't support the BLKRRPART IOCTL, which is used on Linux to tell the kernel to re-read the disk's partition table.
parted can also uses this interface on Linux, but for GNU Hurd, the corresponding function, libparted/arch/gnu.c:gnu_disk_commit, doesn't do anything at all. The infrastructure in GNU Mach is already there, linux/src/drivers/block/ide.c:ide_ioctl<BLKRRPART> and linux/src/drivers/scsi/sd_ioctl.c:sd_ioctl<BLKRRPART>, but the IOCTL needs to be routed from libparted through glibc's Hurd IOCTL interface, through Hurd's libstore, to GNU Mach.
This is not a huge project, and actually one that is suitable for someone who wants to start with hacking the system.
----------------------------------------------------------------------
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=411594&aid=311673&group_id=30628
Reply to: