Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 Sep 2016 22:54:24 -0700
From:      perryh@pluto.rain.com (Perry Hutchison)
To:        smithi@nimnet.asn.au
Cc:        wblock@wonkity.com, freebsd-questions@freebsd.org
Subject:   Re: "gpart add" falsely claiming "No space left on device"
Message-ID:  <57cfab90.qRHpzKSiF/A9Stt1%perryh@pluto.rain.com>
In-Reply-To: <20160907000551.F91459@sola.nimnet.asn.au>
References:  <mailman.109.1473163202.26682.freebsd-questions@freebsd.org> <20160907000551.F91459@sola.nimnet.asn.au>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Ian Smith <smithi@nimnet.asn.au> wrote:
> In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
> On Tue, 06 Sep 2016 00:21:08 -0700 perryh@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)
>  > 
>  > but "gpart add" refuses to add a second freebsd-ufs partition in
>  > that supposedly-free space:
>  > 
>  > # gpart add -t freebsd-ufs -l pkgs -f x da2
>  > gpart: index '4': No space left on device
>  > 
>  > # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
>  > gpart: index '4': No space left on device
>  > 
>  > All of these partitions are unmounted.
>  > 
>  > What am I doing wrong?
>
> Hi Perry,
>
> 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 :)

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

> root@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@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, 
> here as da0a, rather than something sane like da0s1a, where you could 
> merrily add more (MBR) partitions and use boot0cfg to choose between 
> them - as PC-BSD has been doing for years - or with GPT, at least extra 
> data partition/s as you want here, useful in itself.

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).

> It's actually a bodgy image; here's what fdisk makes of that 1G stick:
>
> root@x200:~ # fdisk /dev/da0
> ******* Working on device /dev/da0 *******
> parameters extracted from in-core disklabel are:
> cylinders=973 heads=255 sectors/track=63 (16065 blks/cyl)
>
> parameters to be used for BIOS calculations are:
> cylinders=973 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:
> <UNUSED>
> The data for partition 2 is:
> <UNUSED>
> The data for partition 3 is:
> <UNUSED>
> The data for partition 4 is:
> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
>     start 0, size 50000 (24 Meg), flag 80 (active)
>         beg: cyl 0/ head 0/ sector 1;
>         end: cyl 1023/ head 254/ sector 63
>
> Most of which is nonsense, except that it does start at sector 0, while 
> imcorporating an MBR and a BSD disklabel, and of course size is bogus.

# 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)

parameters to be used for BIOS calculations 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
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

which I take to be the protective MBR of the GPT scheme.



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?57cfab90.qRHpzKSiF/A9Stt1%perryh>