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

Perry Hutchison perryh at pluto.rain.com
Wed Sep 7 06:12:14 UTC 2016


Warren Block <wblock at wonkity.com> wrote:
> On Tue, 6 Sep 2016, 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
>
> The second one makes more sense, as the first '-f x' would/should
> have allocated that space (in an uncommitted operation).  Don't know
> about the first one, unless you have tried it before.

It gave that result the very first time, and a subsequent "gpart show"
produced the same output as before.  I tried the second in case the
reason for the first failing was that (absent -b and -s) it defaulted
to trying to define a partition covering the whole device, failing
because the device was not empty.

> Why bother with '-f x'?  Why not just do the operation immediately?

Paranoia.  IIUC, uncommitted operations work for all purposes
except surviving a reboot, in particular a subsequent "gpart show",
but without writing anything to the stick in the (likely) event that
I did something wrong that would corrupt the stick if committed.
(I do not pretend to understand gpart, and I've been finding its
manpage horribly terse.)


More information about the freebsd-questions mailing list