[SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

jernst · 2016-11-05 01:01:59

I create a disk image with two partitions. I use kpartx to get loop devices for them. I format one with ext4 and the other with btrfs. Only the ext4 partition has a UUID that the kernel can see, even if I manually assign one to the btrfs partition with mkfs.btrfs ... --uuid.

This has various consequences, including that only the ext4 partition shows up in /dev/disk/by-uuid, and that grub-mkconfig puts the loop device into grub.cfg instead of the UUID, making the disk image useless. Killing the loop devices and recreating them gets the kernel to see the btrfs partition. Between all of them ... who is at fault? Or is it a conspiracy?

Slow version:

> dd if=/dev/zero of=test.img bs=1M count=2k
> fdisk test.img
# create DOS partition label (o)
# create two primary partitions right after each other, 100M each (n p ...)
> kpartx -a -s -v test.img
add map loop0p1 (254:0): 0 204800 linear /dev/loop0 2048
add map loop0p2 (254:1): 0 204800 linear /dev/loop0 206848
> mkfs.ext4 /dev/mapper/loop0p1
> lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,UUID /dev/loop0
NAME        SIZE TYPE MOUNTPOINT FSTYPE UUID
loop0         2G loop                   
├─loop0p2   100M part                   
└─loop0p1   100M part               ext4    49fab72e-0c8b-466b-a3ca-d1bfe56475f0    
> mkfs.btrfs /dev/mapper/loop0p2 --uuid 11111111-2222-3333-4444-555555555555
> lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,UUID /dev/loop0
NAME        SIZE TYPE MOUNTPOINT FSTYPE UUID
loop0         2G loop                   
├─loop0p2   100M part                   
└─loop0p1   100M part               ext4    49fab72e-0c8b-466b-a3ca-d1bfe56475f0

Ahem? What happened to the second partition?

> kpartx -d test.img
> kpartx -a -s -v test.img
add map loop0p1 (254:0): 0 204800 linear /dev/loop0 2048
add map loop0p2 (254:1): 0 204800 linear /dev/loop0 206848
> lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,UUID /dev/loop0
NAME        SIZE TYPE MOUNTPOINT FSTYPE UUID
loop0         2G loop                   
├─loop0p2   100M part               btrfs   11111111-2222-3333-4444-555555555555
└─loop0p1   100M part               ext4    49fab72e-0c8b-466b-a3ca-d1bfe56475f0

This does not look right to me, and given how much time I spent on this, starting with non-functional boot images that used to be generated correctly, it better not be right!

Any ideas who might be at fault here, and, even better, where to file a bug on this?

Last edited by jernst (2016-11-06 22:42:11)

R00KIE · 2016-11-05 01:34:33

Works fine here if I do all the steps manually using losetup, fdisk and mkfs.{ext4,btrfs}.

jernst · 2016-11-05 02:58:21

I didn't use losetup, but kpartx. How did you set up the loopback devices exactly?

Last edited by jernst (2016-11-05 02:58:33)

R00KIE · 2016-11-05 14:07:29

jernst wrote:

I didn't use losetup, but kpartx. How did you set up the loopback devices exactly?

losetup /dev/loopX /path/to/image/file

djgera · 2016-11-05 14:51:11

losetup --find --partscan --show <file>

jernst · 2016-11-06 22:41:47

Works with losetup. Seems kpartx is at fault then all by itself, no conspiracy ... Thanks for the help!

Arch Linux

#1 2016-11-05 01:01:59

[SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

#2 2016-11-05 01:34:33

Re: [SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

#3 2016-11-05 02:58:21

Re: [SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

#4 2016-11-05 14:07:29

Re: [SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

#5 2016-11-05 14:51:11

Re: [SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

#6 2016-11-06 22:41:47

Re: [SOLVED] A device mapper / kernel / btrfs / kpartx conspiracy?

Board footer