I can reproduce the same issue too: send_to_daemon: 0xf62050 g->state = 3, n = 40 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f00c, buf_rtn = 0x7ffffbb4f000 blockdev --getbsz /dev/vda proc 60 (blockdev_getbsz) took 0.01 seconds 4096 send_to_daemon: 0xf62050 g->state = 3, n = 44 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f01c, buf_rtn = 0x7ffffbb4f010 blockdev --setbsz 2048 /dev/vda proc 61 (blockdev_setbsz) took 0.01 seconds send_to_daemon: 0xf62050 g->state = 3, n = 40 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f00c, buf_rtn = 0x7ffffbb4f000 blockdev --getbsz /dev/vda proc 60 (blockdev_getbsz) took 0.01 seconds 4096 I checked the source of blockdev, and it is using the BLKBSZSET ioctl. As far as I can tell if the ioctl returns an error then blockdev should return an error too (and hence the error should go all the way out to guestfish). So it appears that the Linux kernel is not returning an error. http://lxr.linux.no/#linux+v2.6.35/fs/block_dev.c#L73 The other possibility is that the blockdev --getbsz call is not returning the block size we just set, but that resolves to this call inside the kernel: http://lxr.linux.no/#linux+v2.6.35/include/linux/blkdev.h#L1196 As far as I can see this really ought to work. Perhaps we need to perform some other operation between the two calls, like a udev settle or some sort of rereading block devices ioctl. If this worries you, please file a BZ. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora