[SOLVED] kernel 5.15.139 breaks partx -a

BenCollver · 11-25-2023, 10:56 PM

I am running Slackware64 15.0 and i updated to kernel 5.15.139 on November 22nd. Today i tried to mount a qemu guest filesystem using the method described below [1]. It failed at "partx -a" with the following output.

partx: /dev/loop0: error adding partition 1

Strace excerpt below [2].

Booting the old kernel 5.15.117 resolved this problem for me.

[1] Presenting guest images as raw image files with FUSE
https://www.qemu.org/2021/08/22/fuse-blkexport/

[2]
openat(AT_FDCWD, "/mnt/fuse/freedos-1.3.fuse", O_RDWR|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/loop0", O_RDWR|O_CLOEXEC) = 4
ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, lo
_flags=0, lo_file_name="/mnt/fuse/freedos-1.3.fuse", ...}}) = 0
close(3) = 0
openat(AT_FDCWD, "/dev/loop0", O_RDONLY) = 3
fadvise64(3, 0, 0, POSIX_FADV_RANDOM) = 0
newfstatat(3, "", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x7, 0), ...}, AT_EMPTY
_PATH) = 0
ioctl(3, BLKGETSIZE64, [8589934592]) = 0
...
lseek(3, 0, SEEK_SET) = 0
read(3, "...", 1024) = 1024
ioctl(3, BLKSSZGET, [512]) = 0
ioctl(3, BLKPG, {op=BLKPG_ADD_PARTITION, flags=0, datalen=152, data={start=32256, length=8587160064, pno=1, devname="", volname=""}}) = -1 EINVAL (Invalid argument)

business_kid · 11-26-2023, 11:07 AM

AFAIK, 5.15.117 is the latest update for slackware-15.0 on glibc-2.33. 5.15.139 would probably have come from current, which started incrementing glibc. They're now on glibc-2.38. A later glibc would definitely break things. Stay on 5.15.117.

BenCollver · 11-26-2023, 05:51 PM

For the record, i got 5.15.139 through slackpkg.

https://mirrors.slackware.com/slackw...inux-5.15.139/

marav · 11-26-2023, 06:31 PM

partx (from util-linux) and kpartx (from multipath-tools) are different programs

You can't use partx the same way as kpartx

Here is a quick-made slackbuild that does the job
kpartx:
https://gitlab.com/maravtdm/slackbui...ultipath-tools

Code:

blackstar :: » qemu-img create -f raw foo.img 20G
Formatting 'foo.img', fmt=raw size=21474836480
blackstar :: » parted -s foo.img \
    'mklabel msdos' \
    'mkpart primary ext4 2048s 100%'
blackstar :: » qemu-img convert -p -f raw -O qcow2 foo.img foo.qcow2 && rm foo.img
    (100.00/100%)
blackstar :: » file foo.qcow2 
foo.qcow2: QEMU QCOW Image (v3), 21474836480 bytes (v3), 21474836480 bytes
blackstar :: » sudo kpartx -l foo.qcow2
blackstar :: » qemu-storage-daemon \
    --blockdev node-name=prot-node,driver=file,filename=foo.qcow2 \
    --blockdev node-name=fmt-node,driver=qcow2,file=prot-node \
    --export \
    type=fuse,id=exp0,node-name=fmt-node,mountpoint=foo.qcow2,writable=on \
    &
[1] 3474
blackstar :: » file foo.qcow2
foo.qcow2: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x10,0,1), end-CHS (0x3ff,3,32), startsector 2048, 41940992 sectors
blackstar :: » sudo kpartx -av foo.qcow2
add map loop0p1 (253:0): 0 41940992 linear 7:0 2048

marav · 11-26-2023, 06:39 PM

Hum...
My bad, a slackbuild already exists on SBo

https://slackbuilds.org/repository/1...arch=multipath

BenCollver · 11-26-2023, 07:20 PM

So far as i know, i am not using multipath. I am curious what makes partx the wrong tool for the job?

marav · 11-26-2023, 07:40 PM

Quote:

Originally Posted by BenCollver

So far as i know, i am not using multipath. I am curious what makes partx the wrong tool for the job?

Based on the tutorial you referenced, they use kpartx, and it works
You use partx, and obviously it doesn't work

kpartx is a binary from multipath-tools
Feel free to use it or not

BenCollver · 11-26-2023, 08:32 PM

partx worked for me for 2 years until i updated to kernel 5.15.139

BenCollver · 11-26-2023, 08:58 PM

I installed multipath-tools, booted Linux kernel 5.15.139, and verified that this process works fine for me with kpartx. Now i have two workarounds.

1) Revert to kernel 5.15.117 as business_kid suggested.
2) Use kpartx instead of partx as marav suggested.

I am curious why these workarounds work.

BenCollver · 11-26-2023, 10:08 PM

Studying the strace output, i notice that:

* partx uses the BLKPG_ADD_PARTITION ioctl on /dev/loop0
* kpartx uses the DM_DEV_CREATE ioctl on /dev/mapper/control

My guess is that partx was broken in the following commit in kernel 5.15.132

https://lore.kernel.org/all/20230831075900.1725842-1-lilingfeng@huaweicloud.com/

Partx was the wrong tool for the job because the BLKPG_ADD_PARTITION ioctl was not supposed to be valid on a loop block device. It was a happy accident that it worked for me until my last kernel upgrade.