Other resizing partition disk gpart: index '5': No space left on device

Hey bsd buddies,

I'm trying to migrate freebsd to a kvm host and got the following issue. The problem I ran into is exactly the same issue which was mentioned in a thread two years ago ..



Error Message
Code:
gpart: index '5': No space left on device as an error.

My setup is just a few hours old and it was the first time I used a image to skip the install .

I installed freebsd a second time , this time with the normal old school way via an iso.

Interestingly , on this install I can't recreate the issue. The resizing just works. But I could figure out a difference , but I don't know what this means.

This is the layout of the image
Code:
sharky@freebsd:~ $ df -hFilesystem         Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs     48G    3.7G     41G     8%    /
devfs              1.0K    1.0K      0B   100%    /dev
/dev/gpt/efiesp     32M    870K     31M     3%    /boot/efi

sharky@freebsd:~ $ gpart show
=>        3  220267669  ada0  GPT  (105G)
          3        127     1  freebsd-boot  (64K)
        130      66584     2  efi  (33M)
      66714    2097152     3  freebsd-swap  (1.0G)
    2163866  104857598     4  freebsd-ufs  (50G)
  107021464  113246208        - free -  (54G)


sharky@freebsd:~ $ sudo  gpart add -t freebsd-zfs ada0
gpart: index '5': No space left on device

sharky@freebsd:~ $ sudo gpart add -t freebsd-zfs -s 50G ada0
gpart: index '5': No space left on device
This is the layout of the image installed via an iso .
Code:
root@freebsd:~ # df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    4.6G    1.9G    2.4G    44%    /
devfs          1.0K    1.0K      0B   100%    /dev

root@freebsd:~ # gpart show
=>      40  10485680  ada0  GPT  (5.0G)
        40      1024     1  freebsd-boot  (512K)
      1064   9958400     2  freebsd-ufs  (4.7G)
   9959464    524288     3  freebsd-swap  (256M)
  10483752      1968        - free -  (984K)

It seems the setup of the image is done in another way , but I don't know how and maybe that is why I need to do other steps which aren't documented in the handbook.

Any response is appriciate !

regards , sebastian
 
I can't try it myself so I'll post "blind". The output of image's gpart show seems very odd, I see few mistakes. Boot partition can't start so early, it's in the GPT's header metadata. That's why it starts at LBA 40 in your second output (rounded up for alignment). Also its size is too small for FreeBSD 13 (even 256k is small for it).
 
I second _martin's assessment; your partition boundaries are way off.

If you run a system like this, you'll probably see some performance degradation because you're not hitting block level boundaries. Bad on an SSD, even worse on a physical HDD. It'll cause additional wear as well.

How did you create your image and its partition table?
 
Thanks for all responses . The freebsd community is awesome :)

_martin Which line seems odd ?

I think you mean this one ?

sharky@freebsd:~ $ gpart show
=> 3 220267669 ada0 GPT (105G)

I need to lookup those vars in a fresh install without my resizing approach.
 
your gpt header has only 1 sector for partitions instead of 32 so only 4 partitions will fit instead of 128
you can nuke the boot and efi partitions and recreate them and allow more space for gpt header
you probably don't need both efi and freebsd-boot
 
_martin Which line seems odd ?

GPT header should be spread on 33 (1+32) sectors (512 ones anyway) so first available should be 34. You should not go lower than that. Then there's the secondary issue of alignment. For FreeBSD 13 with option to be able to boot both legacy and UEFI you need to (basically repeating what covacat said above though):

a) delete partition 1,2 (possible even swap 3)
b) create freebsd-boot to be 512k
c) uefi standard defines minimum size of UEFI partition but I understand the practicality of reducing it to minimum in cloud, so keep it 32M
d) reapply bootcode

gpart automatically starts the partition at the first available LBA, you should not overwrite it (as you did here and specified 3). It's easy to fix it as you have enough space before the actual freebsd-ufs parition ; you could even delete swap temporarily when reconstructing the layout.
 
Back
Top