"gpart add" falsely claiming "No space left on device"

[Ian Smith]

On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
 > Ian Smith <smithi at nimnet.asn.au> wrote:
 > > In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
 > > On Tue, 06 Sep 2016 00:21:08 -0700 perryh at pluto.rain.com (Perry Hutchison)
 > > wrote:
 > >  > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
 > >  > used "gpart recover" to resize the partition table to the media.
 > >  > After that "gpart show" reports:
 > >  > 
 > >  > # gpart show da2
 > >  > =>      3  7811067  da2  GPT  (3.7G)
 > >  >         3       32    1  freebsd-boot  (16K)
 > >  >        35  1348832    2  freebsd-ufs  (659M)
 > >  >   1348867     2048    3  freebsd-swap  (1.0M)
 > >  >   1350915  6460155       - free -  (3.1G)
[..]

 > > How did you 'copy' the memstick.img to the flash drive?
 > 
 > # dd if=FreeBSD-10.3-RELEASE-i386-memstick.img of=/dev/da2 bs=71b
 > 
 > Why bs=71b?  71*512 is the largest factor of the image size that
 > is a multiple of 512 and less than 126*512, so this way there is
 > no partial dd block at the end.  (Old-timers will remember why
 > some of us don't like to exceed bs=126b with dd :)

I only go back to '98 on FreeBSD; never heard of that .. I'll resist my 
curiosity.  I used to use bs=10240 as earlier recommended, now just:
	# dd if=FreeBSD-10.3-RELEASE-amd64-memstick.img \
	of=/dev/da0 bs=1m conv=sync

 > BTW it did boot (I only tried single-user mode) and worked well
 > enough to resize itself with "gpart recover".

Um, do you mean you ran gpart recover on the stick you'd booted off?

 > > root at x200:~ # ll /dev/da*
 > > crw-rw----  1 root  operator  0x8c Sep  6 19:12 /dev/da0
 > > crw-rw----  1 root  operator  0x8d Sep  6 19:12 /dev/da0a
 > >
 > > root at x200:~ # gpart show da0
 > > =>      0  1974272  da0  BSD  (964M)
 > >         0  1523248    1  freebsd-ufs  (743M)
 > >   1523248   451024       - free -  (220M)
 > 
 > # ll /dev/da*
 > crw-r-----  1 root  operator    0, 116 Aug 31 20:05 /dev/da0
 > crw-r-----  1 root  operator    0, 117 Aug 31 20:05 /dev/da0s1
 > crw-r-----  1 root  operator    0, 118 Aug 31 20:05 /dev/da0s2
 > crw-r-----  1 root  operator    0, 119 Aug 31 20:05 /dev/da0s3
 > crw-r-----  1 root  operator    0,  87 Sep  5 18:03 /dev/da1
 > crw-r-----  1 root  operator    0,  88 Sep  5 18:03 /dev/da1a
 > crw-r-----  1 root  operator    0, 112 Sep  5 18:21 /dev/da2
 > crw-r-----  1 root  operator    0, 114 Sep  5 18:21 /dev/da2p1
 > crw-r-----  1 root  operator    0, 115 Sep  5 18:21 /dev/da2p2
 > crw-r-----  1 root  operator    0, 120 Sep  5 18:21 /dev/da2p3
 > 
 > da0 is an actual SCSI disk, partitioned the old way (MBR), and
 > containing a different OS.
 > da1 is an 8.1 memstick, "partitioned" the way 8.x memsticks were done.
 > da2 is the 10.3 memstick, which appears to be GPT.
 > 
 > > That's a 10.3 memstick.img dd'd to a 1G stick.  For some bizarre reason, 
 > > maybe 10? years on, these are still being made as pseudo-floppy images, 
[..]

 > Seems my 10.3 memstick.img is different than yours :(
 > Mine is FreeBSD-10.3-RELEASE-i386-memstick.img.xz of
 > 3/24/2016, downloaded from ftp14.us.freebsd.org on 5/1/2016
 > (and decompressed before being dd'd to the stick , of course).

I found this so bizarre that I had to download it to see for myself.  I 
first wondered if your 'gpart recover' had somehow mangled it to turn it 
into GPT .. but I'd tried gpart recover on the da0 above and it just 
said 'da0 recovering is not needed' - which was reassuring :)

So I checked the sha256 of the memstick.img.xz, unxz'd <cough> it then 
checked the sha256 of the memstick.img, all good, mdconfig'd it to see:

t23# gpart show md0
=>      3  1350912  md0  GPT  (660M)
        3       32    1  freebsd-boot  (16K)
       35  1348832    2  freebsd-ufs  (659M)
  1348867     2048    3  freebsd-swap  (1.0M)

Sure enough, the 10.3 i386 memstick.img is GPT, while the amd64 one is 
BSD as ever.  gpart recover on that said 'md0 recovering is not needed'.

But according to ..
[big cut]

 > # fdisk /dev/da2
 > ******* Working on device /dev/da2 *******
 > parameters extracted from in-core disklabel are:
 > cylinders=486 heads=255 sectors/track=63 (16065 blks/cyl)
[..]
 > Media sector size is 512
 > Warning: BIOS sector numbering starts with sector 1
 > Information from DOS bootblock is:
 > The data for partition 1 is:
 > sysid 238 (0xee),(EFI GPT)
 >     start 1, size 7811071 (3813 Meg), flag 0
 >         beg: cyl 0/ head 0/ sector 2;
 >         end: cyl 1023/ head 255/ sector 63
 > 
 > which I take to be the protective MBR of the GPT scheme.

Not only that, but I notice 'EFI GPT', also from fdisk md0 here:
sysid 238 (0xee),(EFI GPT)
    start 1, size 1350917 (659 Meg), flag 0

Whereas with the amd64 release there's a whole extra set of images 
labelled -uefi- such as: FreeBSD-10.3-RELEASE-amd64-uefi-memstick.img

I'm entirely [U]EFI ignorant, but it seems strange that the i386 images 
appear to incorporate that, while amd64 uefi images are kept separate?

Can anyone explain why any of this is so?  (looking at you, Warren :)

cheers, Ian

PS there are very significant differences in gpart(8) from (I diff'd)
8.2, 9.3 and 10.3, so best base discussion on the 10.3 version I guess:

https://www.freebsd.org/cgi/man.cgi?query=gpart&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE