problems with GPT (and maybe dkctl wedges) on LVM volumes

["Greg A. Woods" <woods%planix.ca@localhost>]

So with -current if you present a LVM volume to a domU and then use
sysinst to install on it (and I think IFF you choose "extended
partitioning") you end up with a GPT partitioned VLM volume that the
XEN_DOMU kernel sees as follows:

[   2.0010567] xbd0 at xenbus0 id 0: Xen Virtual Block Device Interface
[   2.0090574] xbd0: 20480 MB, 512 bytes/sect x 41943040 sectors
[   2.0090574] xbd0: backend features 0x1<CACHE-FLUSH>
[   2.0100607] dk0 at xbd0: "nbtest-root", 41942943 blocks at 64, type: ffs

From the running dom0 the GPT partition table for this device looks like
this:

# gpt show -a /dev/rxbd0  
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34        30         Unused
        64  41942943      1  GPT part - NetBSD FFSv1/FFSv2
                                 Type: ffs
                                 TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
                                 GUID: da2147be-1fe7-4bb3-a1fc-e601c92301fe
                                 Size: 20480 M
                                 Label: nbtest-root
                                 Attributes: biosboot
  41943007        32         Sec GPT table
  41943039         1         Sec GPT header



However attempts to access the filesystem from the dom0 fail (after
seeming to get most of the way to finding the whole primary table):

# gpt -vvv show -a /dev/mapper/rvg0-nbtest.0
/dev/mapper/rvg0-nbtest.0: mediasize=41943040; sectorsize=512; blocks=81920
/dev/mapper/rvg0-nbtest.0: PMBR at sector 0
/dev/mapper/rvg0-nbtest.0: Pri GPT at sector 1
/dev/mapper/rvg0-nbtest.0: GPT partition: type=ffs, start=64, size=41942943
gpt: /dev/mapper/rvg0-nbtest.0: map entry doesn't fit media: new start + new size < start + size
(22 + 13fde < 40 + 27fff9f)


This may or may not be related to PR# 54900.

There's also mention of a possibly related issue in this thread:

    http://mail-index.netbsd.org/netbsd-users/2020/07/19/msg025551.html

However in my case it looks like gpt(8) when run in the dom0 is having
problems skipping past the "Unused" part.  (suggested because 0x22 == 34d)



Also it seems dkctl doesn't work as I had expected it would on LVM
partitions, even though it can apparently find a viable partition:

# dkctl /dev/mapper/rvg0-nbtest.0 getwedgeinfo
vg0-nbtest.0 at vg0-nbtest.0: vg0-nbtest.0
vg0-nbtest.0: 41943040 blocks at 0, type: ffs

# dkctl /dev/mapper/rvg0-nbtest.0 makewedges
dkctl: /dev/mapper/rvg0-nbtest.0: makewedges: Inappropriate ioctl for device

# dkctl /dev/mapper/rvg0-nbtest.0 addwedge nbtest-root 64 41942943 ffs
dkctl: /dev/mapper/rvg0-nbtest.0: addwedge: Inappropriate ioctl for device


So it looks like I'm back to using plain MBR for domUs again, at least
for my next round of Xen server rebuilds.

-- 
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgpGTCSXowVrI.pgp
Description: OpenPGP Digital Signature