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:
pgpvOtXoS681C.pgp
Description: OpenPGP Digital Signature