On Sun, 3 Feb 2013, Tim Kientzle wrote: > On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote: > >> On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: >>> I'm tinkering with a disk image that automatically >>> fills whatever media you put it onto. But I'm having >>> trouble with gpart resize failing. >>> >>> Disk layout: >>> MBR with two slices mmcsd0s1 and mmcsd0s2 >>> bsdlabel with one partition mmcsd0s2a >>> >>> Before I can use growfs, I have two gpart resize operations: >>> >>> 1) gpart resize -i 2 mmcsd0 >>> >>> 2) gpart resize -i 1 mmcsd0s2 >>> >>> Step 1 resizes mmcsd0s2 and always succeeds. >>> >>> Step 2 resizes mmcsd0s2a and always fails >>> with "No space on device." >>> >>> BUT if I reboot between these steps, step #2 >>> always succeeds. >>> >>> I suspect that step #1 is updating the partition >>> information on disk but that step #2 is somehow >>> reading the old size of mmcsd0s2 and thus finding >>> that there is no available space to grow the partition. > > BTW, I've added some debug messages to gpart > and the second resize is failing because the new > computed size is a little smaller than the old size > (maybe because of a different alignment?). But > it's certainly not sizing to the new container size. MBR always forces alignment to imaginary CHS tracks, as if you used -a63 in gpart. But it's not gpart, it's the kernel being really strict about standards. As far as I've been able to tell, there is no way around that short of possibly dd-ing a preconstructed MBR partition table into place.Received on Mon Feb 04 2013 - 04:14:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:34 UTC