#989310 partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument

Package:
util-linux
Source:
util-linux
Description:
miscellaneous system utilities
Submitter:
Thorsten Glaser
Date:
2021-06-03 13:36:03 UTC
Severity:
normal
#989310#5
Date:
2021-05-31 19:04:33 UTC
From:
To:
I’m trying to use partx instead of kpartx to make partitions
available to the system, but it completely fails:

tglase@tglase:~ $ sudo partx -a -v - /dev/vg-tglase/ufs
partition: none, disk: /dev/vg-tglase/ufs, lower: 0, upper: 0
/dev/vg-tglase/ufs: partition table type 'dos' detected
range recount: max partno=4, lower=0, upper=0
partx: /dev/vg-tglase/ufs: adding partition #4 failed: Invalid argument
partx: /dev/vg-tglase/ufs: error adding partition 4

Doing this with kpartx works…

tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs
add map vg--tglase-ufs4 (253:9): 0 67108832 linear 253:8 32

… but kpartx fails in the second step, making the slices from
the BSD disklabel available…

tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs4
device-mapper: reload ioctl on vg--tglase-ufs4p1 (253:10) failed: Invalid argument
create/reload failed on vg--tglase-ufs4p1
device-mapper: reload ioctl on vg--tglase-ufs4p2 (253:10) failed: Invalid argument
create/reload failed on vg--tglase-ufs4p2
device-mapper: reload ioctl on vg--tglase-ufs4p3 (253:10) failed: Invalid argument
create/reload failed on vg--tglase-ufs4p3
device-mapper: reload ioctl on vg--tglase-ufs4p4 (253:10) failed: Invalid argument
create/reload failed on vg--tglase-ufs4p4

… whereas partx at least recognises the disklabel:

tglase@tglase:~ $ sudo partx --show - /dev/mapper/vg--tglase-ufs4
NR   START      END  SECTORS  SIZE NAME UUID
 1 2097152 67108863 65011712   31G
 2      32  2097151  2097120 1024M
 3       0       31       32   16K

So I’m stuck.

#989310#10
Date:
2021-05-31 19:19:06 UTC
From:
To:
Dixi quod…
                                        whole-disc:^^^^^^^^^^^^^^
                                         bsd-disklabel-partition:^

I found a workaround… it does require manually figuring out
which of the “NR” maps to which slice, then losetup(8)ing
that — this is a bit tricky (START is relative to the entire
disc, not the partition) and ugly (losetup only uses bytes,
Kibibytes, etc. but not sectors as offset):

sudo losetup -f -o $((2097152/2))K --sizelimit $((65011712/2))K /dev/mapper/vg--tglase-ufs
               START=>^^^^^^^            SECTORS=>^^^^^^^^       whole-disc:^^^^^^^^^^^^^^
                     2sec=1K:^^^^^                2sec=1K:^^^^^

Then, “sudo losetup -a” to figure out which loop device
“won”, afterwards use that, for example, with ufsutils
(= 8.2-4) installed, I can do…

sudo ffsinfo /dev/loop0 | less
sudo fsck.ufs -fy /dev/loop0

… and even…

sudo mount -t ufs -o ufstype=44bsd /dev/loop0 /mnt
ls /mnt
sudo umount /mnt

… and at the end, don’t forget to:

sudo losetup -d /dev/loop0
sudo kpartx -d -v /dev/mapper/vg--tglase-ufs


JFYI, in case this pops up with someone else. A working solution,
involving partx, partprobe, kpartx or something, would still be
welcome.

bye,
//mirabilos

#989310#15
Date:
2021-06-03 11:33:02 UTC
From:
To:
* Thorsten Glaser <tg@mirbsd.de> [210531 21:09]:
[..]

Right. Thanks for the report, however could I ask you to directly
report this to upstream? I don't think this is a Debian peculiarity
and I cannot think of anything useful that I could add to an
upstream bug report.

Thanks!
Chris

#989310#20
Date:
2021-06-03 13:30:16 UTC
From:
To:
Hi Chris,

could you please do that? I have no relationship with upstream and
no desire to register in just another bugtracker, and I’m not even
sure which component is even part of the problem.

Thanks,
//mirabilos