Other gpart: index '3': No space left on device

O

obsigna

Profile disabled
On AWS-EC2 I got running FreeBSD 12.1-RELEASE-p10. Just recently, I wanted to add a real swap partition to the virtual drive, and therefore I increased the volume size from 20 to 21 GB. This worked out well, and I executed gpart recover, in order the partition scheme reflects the new size of the virtual drive:
Code: 
# gpart show
=>       3  44040181  ada0  GPT  (21G)
         3       125     1  freebsd-boot  (63K)
       128  41942904     2  freebsd-ufs  (20G)
  41943032   2097152        - free -  (1.0G)

Up to this point, everything looks quite right, doesn’t it?

Only when I want to add the swap partition:
Code: 
# gpart add -t freebsd-swap ada0
gpart: index '3': No space left on device
No matter what -b and -s options I use on the command line, I see always the same result. There is even no space left on the device for a partition of 1M, and neither for a properly sized freebsd-ufs one. This is a complete surprise. I used gpart(8) quite a lot in the past and I never had a problem like this.

How can I resolve this?
 
Elazar said:
41943032 2097152
Shouldn't the right value be higher than the left one?
Click to expand...
No. The left column shows the base in terms of counts of 512k blocks, while the second column shows the size which is either assigned or available.
 
Yes it look strange,
this is from the man page of gpart

kern.geom.part.auto_resize: 1
This variable controls automatic resize behavior of gpart GEOM
class. When this variable is enable and new size of provider is
detected, the schema metadata is resized but all changes are not
saved to disk, until gpart commit is run to confirm changes.
This behavior is also reported with diagnostic message:
GEOM_PART: (provider) was automatically resized. Use `gpart
commit (provider)` to save changes or `gpart undo (provider)` to
revert them.
Click to expand...
 
We are in the same situation: AWS-EC2, upgraded to FreeBSD 12.1-RELEASE-p10, and our attempts to add a partition to 3 VMs fail with the same error:
Code: 
>gpart show
=>       3  83886069  ada0  GPT  (40G)
         3        32     1  freebsd-boot  (16K)
        35  62914557     2  freebsd-ufs  (30G)
  62914592  20971480        - free -  (10G)

gpart add -t freebsd-swap -l toolsswap ada0
gpart: index '3': No space left on device

sysctl kern.geom.part.auto_resize
kern.geom.part.auto_resize: 1

Before the upgrade we were able to use gpart add -s 4G -t freebsd-swap -l toolsswap ada0 to create a 4GB partition for swap. As a workaround for the swap partition, after taking a snapshot of the volume, we grew the filesystem and created a swap file following the handbook section 11.12.2 on swapfiles.
Code: 
>gpart resize -i 2 -s 39G ada0
ada0p2 resized
>growfs /dev/gpt/rootfs
 
Hmm, that utility seems to fail (run as root):
Code: 
>camcontrol readcap ada0
camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
cam_lookup_pass: No such file or directory
cam_lookup_pass: either the pass driver isn't in your kernel
cam_lookup_pass: or ada0 doesn't exist

This thread contains the same error message, but that thread sounds like it is without the EC2 virtualization layer. Is there another utility that can show the last block of "ada0"? Here is gpart list ada0
Code: 
>gpart list ada0
Geom name: ada0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 83886071
first: 3
entries: 2
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 16384 (16K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1536
   Mode: r0w0e0
   efimedia: HD(1,GPT,8735f4dd-410a-11e5-ba8f-002590ec5bf2,0x3,0x20)
   rawuuid: 8735f4dd-410a-11e5-ba8f-002590ec5bf2
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: bootfs
   length: 16384
   offset: 1536
   type: freebsd-boot
   index: 1
   end: 34
   start: 3
2. Name: ada0p2
   Mediasize: 37580963840 (35G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 17920
   Mode: r1w1e2
   efimedia: HD(2,GPT,8735f4e4-410a-11e5-ba8f-002590ec5bf2,0x23,0x4600000)
   rawuuid: 8735f4e4-410a-11e5-ba8f-002590ec5bf2
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: rootfs
   length: 37580963840
   offset: 17920
   type: freebsd-ufs
   index: 2
   end: 73400354
   start: 35
Consumers:
1. Name: ada0
   Mediasize: 42949672960 (40G)
   Sectorsize: 512
   Mode: r1w1e3

Is the last: label indicating the last block, 83886071?
 
Generic, we spun these VMs up from Colin's AWS AMIs (v10, v11, or v12), depending on how old the instance is, (The kernel patches are applied with pkg). Perhaps I should try spinning up a temporary instance on the v12 AMI to see if it is reproducible on a fresh install.
 
You must log in or register to reply here.
Back
Top