[DragonFlyBSD - Bug #3422] (New) gpt(8): expand leaves backup GPT stranded after a single run (regression)

[sigttou]

Issue #3422 has been reported by sigttou.

----------------------------------------
Bug #3422: gpt(8): expand leaves backup GPT stranded after a single run (regression)
http://bugs.dragonflybsd.org/issues/3422

* Author: sigttou
* Status: New
* Priority: Normal
* Category: Userland
* Target version: 6.6
* Start date: 2026-09-23
----------------------------------------
On current master, a single "gpt expand" on a grown device relocates the
primary GPT but not the secondary (backup) GPT, leaving the primary header
pointing at a non-existent secondary.  A second run then creates it.

Regression from the expand rewrite f4b4c056f1 (2025-09-01); 6.4-RELEASE and
the old code relocate the secondary correctly in one run.

Reproduce (vnode(4) disk grown in place):

<pre>
truncate -s 64M d.img
vnconfig vn0 d.img
gpt create vn0
gpt add -s 40960 vn0
truncate -s 128M d.img
vnconfig -u vn0; vnconfig vn0 d.img
</pre>

<pre>
/sbin/gpt expand vn0
/sbin/gpt show vn0
</pre>

Observed (master 5e4ae0baf5):

<pre>
vn0: expand entry 0 ending 43007 => 260095
vn0: expand GPT by 131072 sectors
Disk vn0: 128MB (262144 512-byte sectors)
   Start  Sectors    Size  Index  Contents
       0       1    512B      -  PMBR
       1       1    512B      -  Pri GPT header
       2      32  16.0KB      -  Pri GPT table
      34    2014  1007KB      -  Unused
    2048  258048   126MB      0  GPT part - DragonFly Label64
  260096    2048  1024KB      -  Unused     <-- no Sec GPT table/header
</pre>

Running "gpt expand vn0" a second time prints:

<pre>
gpt expand: vn0: no secondary GPT header; creating
gpt expand: vn0: no secondary GPT table; creating
vn0: entry 0 size unchanged
vn0: disk size unchanged
</pre>

and only then does "gpt show" list the secondary (262111 / 262143).

Raw on-disk check (parsing the GPT headers) for 64 MB -> 128 MB, one run:

<pre>
                  primary.alt   secondary @ alt
master            262143        no valid "EFI PART" (zeros)
6.4-RELEASE       262143        valid (self=262143, table=262111)
</pre>

Root cause: in expand(), the secondary entries found by
map_find(MAP_TYPE_GPT_SEC_HDR/TBL) are still at the old (pre-growth)
location, because gpt_open() located them via the primary header's stale
hdr_lba_alt.  They are non-NULL, so the "create at last" branch is skipped
and the old header is updated in place.  The primary's hdr_lba_alt was set
to the new "last" regardless, hence the mismatch.  A second run works
because gpt_open() then fails to find a secondary at the new alt, so
map_find() returns NULL and the create branch finally runs.

The rewrite commit itself describes the change: "Use map_find()+map_add()
instead of mkmap() to deal with the secondary GPT table."  6.4's mkmap()
version always created the secondary at the new end, which is correct on a
grown device.

Attached: gpt-expand-secondary-fix.patch - recreate the secondary header and
table at the new end whenever they are not already in place (reuse them only
if already at "last"/"last - blocks", so repeated runs stay quiet).

---Files--------------------------------
gpt-expand-secondary-fix.patch (1.42 KB)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account