fun with extending btrfs

My root partition (btrfs, /dev/nvme0n1p5) is running out of space:

#btrfs filesystem show
Label: none  uuid: bb58fb8f-a794-4e30-a863-c578fd1b52ad
        Total devices 1 FS bytes used 32.10GiB
        devid    1 size 40.45GiB used 39.65GiB path /dev/nvme0n1p5

Label: none  uuid: a4a69c17-1731-4c09-a940-83fdfb8ac4d7
        Total devices 1 FS bytes used 13.34GiB
        devid    1 size 40.00GiB used 15.29GiB path /dev/mapper/system--nvme-root_factory

So i decided to extend it with :

#btrfs device add /dev/system-nvme/root_extent /

It responded with :

Performing full device TRIM (20.00GiB) ...

and no error message

Then I rebooted the system . And now the 13.2 installation failed to boot with:

A start job is running  for dev-disk-by\x2duuid-bb58fb87\x2daa794\xd24e30\x2da863\x2dc578f...device 

There is also a Tumbleweed installation on that PC. I booted that and

# btrfs filesystem show
Label: none  uuid: a4a69c17-1731-4c09-a940-83fdfb8ac4d7
        Total devices 1 FS bytes used 13.26GiB
        devid    1 size 40.00GiB used 15.29GiB path /dev/mapper/system--nvme-root_factory

Label: none  uuid: bb58fb8f-a794-4e30-a863-c578fd1b52ad
        Total devices 2 FS bytes used 32.09GiB
        devid    1 size 40.45GiB used 39.90GiB path /dev/nvme0n1p5
        devid    2 size 20.00GiB used 0.00B path /dev/mapper/system--nvme-root_extent

ssems to look fine
Then I mounted the failed btrfs without problems:

mount -t btrfs /dev/nvme0n1p5 /mnt

and after removing the additional device with

# btrfs device delete /dev/mapper/system--nvme-root_extent /mnt
# btrfs filesystem show
Label: none  uuid: a4a69c17-1731-4c09-a940-83fdfb8ac4d7
        Total devices 1 FS bytes used 13.34GiB
        devid    1 size 40.00GiB used 15.29GiB path /dev/mapper/system--nvme-root_factory

Label: none  uuid: bb58fb8f-a794-4e30-a863-c578fd1b52ad
        Total devices 1 FS bytes used 32.09GiB
        devid    1 size 40.45GiB used 39.65GiB path /dev/nvme0n1p5

booting into 13.2 works again

Did I something wrong or did I find a bug ?

Perhaps the UUID changed. It is not uncommon for the UUID to change when modifying a partition So check the /etc/fstab on the 13.2 root and compare to the actual UUIDs now

No, the UUID did not change. You can see that in the posted “btrfs filesystem show” output.

There is pretty nasty bug with multi-device btrfs on device-mapper. The bug is claimed to be fixed; do you have the latest patches installed?

https://bugzilla.suse.com/show_bug.cgi?id=912170

It seems that the repos have a problem with the “latest patches”:
zypper in btrfsprogs-4.5.3-13.1
Repository-Daten werden geladen…
Installierte Pakete werden gelesen…
Paket ‘btrfsprogs-4.5.3-13.1’ nicht gefunden.
Paketabhängigkeiten werden aufgelöst…

But there is http://ftp.uni-erlangen.de/mirrors/opensuse/update/13.2/x86_64/btrfsprogs-4.5.3-13.1.x86_64.rpm. So I could download and install it manually and will try now.

Unfortunately the updated btrfsprogs don’t change anything. Same boot error as before.

Did you also rebuild initrd? It also needs updated udev rules.

The installation triggered an update of initrd when I run it , to be safe I’ve started manually a mkinitrd and then checked the initrd with lsinitrd. And there is no 64-btrfs-dm.rules included in initrd. And mkinitrd.log doesn’t tell that 64-btrfs-dm.rules is skipped.
Might it be that dracut configuration needs an update,too ?

I forgot - does 13.2 use legacy mkinitrd or dracut?

mkinitrd is a script , which runs dracut.
There is 64-btrfs.rules included in initrd but not 64-btrfs-dm.rules.

Then add file to dracut by creating /etc/dracut.conf.d/test.conf with content

**install_items+=**" /usr/lib/udev/rules.d/64-btrfs-dm.rules "

Now lsinitrd shows that 64-btrfs-dm.rules is included


Image: /boot/initrd-4.6.1-3.g3988263-default: 8,4M
========================================================================
Version: dracut-037-68.1

Arguments: --logfile --force

dracut modules:
bash
warpclock
i18n
ifcfg
btrfs
dm
kernel-modules
lvm
resume
rootfs-block
terminfo
udev-rules
haveged
systemd
usrmount
base
fs-lib
shutdown
suse
========================================================================
...some lines snipped due to forum limits...]

drwxr-xr-x   1 root     root            0 Jun  8 20:07 usr/lib/udev/rules.d
-r--r--r--   1 root     root         7106 May 12 16:05 usr/lib/udev/rules.d/10-dm.rules
-r--r--r--   1 root     root         2450 May 12 16:05 usr/lib/udev/rules.d/11-dm-lvm.rules
-r--r--r--   1 root     root         2165 May 12 16:05 usr/lib/udev/rules.d/13-dm-disk.rules
-rw-r--r--   1 root     root         2985 Jun  1 14:33 usr/lib/udev/rules.d/50-udev-default.rules
-rw-r--r--   1 root     root         3971 Jan  8 14:08 usr/lib/udev/rules.d/55-scsi-sg3_id.rules
-rw-r--r--   1 root     root         2885 Jan  8 14:08 usr/lib/udev/rules.d/58-scsi-sg3_symlink.rules
-rw-r--r--   1 root     root         6797 Jun  1 14:33 usr/lib/udev/rules.d/60-persistent-storage.rules
-rw-r--r--   1 root     root          387 May 18 13:04 usr/lib/udev/rules.d/64-btrfs-dm.rules
-rw-r--r--   1 root     root          554 Jun  1 14:33 usr/lib/udev/rules.d/64-btrfs.rules
-r--r--r--   1 root     root         4416 May 12 16:05 usr/lib/udev/rules.d/69-dm-lvm-metad.rules
-rw-r--r--   1 root     root         2591 Jun  1 14:33 usr/lib/udev/rules.d/70-uaccess.rules
-rw-r--r--   1 root     root         2360 Jun  1 14:33 usr/lib/udev/rules.d/71-seat.rules
-rw-r--r--   1 root     root          596 Jun  1 14:33 usr/lib/udev/rules.d/73-seat-late.rules
-rw-r--r--   1 root     root          452 Jun  1 14:33 usr/lib/udev/rules.d/75-net-description.rules
-rw-r--r--   1 root     root          618 Jun  1 14:33 usr/lib/udev/rules.d/80-drivers.rules
-rw-r--r--   1 root     root          292 Jun  1 14:33 usr/lib/udev/rules.d/80-net-setup-link.rules
-r--r--r--   1 root     root          479 May 12 16:05 usr/lib/udev/rules.d/95-dm-notify.rules
-rw-r--r--   1 root     root          155 Jun  1 14:33 usr/lib/udev/rules.d/95-udev-late.rules
-rw-r--r--   1 root     root         4168 Jun  1 14:33 usr/lib/udev/rules.d/99-systemd.rules


But there is still the same error when rebooting with added volume.

How can I debug that further ?

When this happens you should be dropped into (initrd) shell. Could you provide output of “journalctl -b” and “udevadm info --export-db” at this point? Just to be sure we are dealing with the same problem?

… btrfsprogs changes are cosmetic and do not matter at all. The real bug is in 64-btrfs.rules that is part of systemd and this file did not change. For testing - please replace the following lines

ENV{DM_NAME}=="", IMPORT{builtin}="btrfs ready $devnode"
ENV{DM_NAME}=="?*", IMPORT{builtin}="btrfs ready /dev/mapper/$env{DM_NAME}"

with

IMPORT{builtin}="btrfs ready $devnode"

and rebuild initrd. If this works, reopen bug report.

Well, the failing start job has no time limit. So even after waiting 15 minutes I wasn’t dropped into initrd shell. It is still running after a CTRL-ALT-DEL , when the other stuff is shutdown. To restart the system then , you have to use the power switch.

… btrfsprogs changes are cosmetic and do not matter at all. The real bug is in 64-btrfs.rules that is part of systemd and this file did not change. For testing - please replace the following lines

ENV{DM_NAME}=="", IMPORT{builtin}="btrfs ready $devnode"
ENV{DM_NAME}=="?*", IMPORT{builtin}="btrfs ready /dev/mapper/$env{DM_NAME}"

with

IMPORT{builtin}="btrfs ready $devnode"

and rebuild initrd. If this works, reopen bug report.

I tried that fix, but it didn’t change anything. So it is probably another problem

Now I’ve tried to extend my Tumbleweed root partition with the same procedure. And booting then also fails. This time with error message and dropping me into a initrd shell :
BTRFS: failed to read chunktree on dm0
BTRFS: open ctree failed.

Since not many even try this maybe the tools are broken and need to repost on bugzilla

Well, provide logs I asked for. It is impossible to claim anything without having factual information.

Since there is no initrd shell I can’t provide logs from 13.2. I will provide logs from Tumbleweed in a bugreport because logfiles a too big. But this will have to wait until tomorrow.

opened https://bugzilla.opensuse.org/show_bug.cgi?id=984516