Created attachment 634966 [details]
a tar of all the files regarding this issue

I have a system that is using snapper to take periodic snapshots on a btrfs
filesystem configured with volumes.
This btrfs is mapped on a raid1 partition (managed by mdadm as it is able to
raise errors via mail in case of degradation)

I experienced the classic problem with btrfs, as time goes by "df -h" show
empty space while for btrfs the volume go full.

To manage this situation I added another partition to btrfs and reclaimed the
space with "btrfs balance start /", I made a new initrd with "mkinitrd" and
then rebooted.

The dracut process hang (without dropping to an emergency shell) during rootfs
mount asking, on the console appear that dracut is trying to mount the correct
uuid but for some reason don't work.

So, I booted with a rescue disk, removed some snapper generated subvolumes to
"make space" and the removed also the secondary btrfs volume (thinking that
this would recover from the "boot hang") with "btrfs device delete <volume>
<path>".

I regenerated the initrd with mkinitrd and rebooted obtaining the same issue:
the boot process hangs trying to mount rootfs.

So I set the dracut commmandline to drop to a shell during boot pre-mount
stage:
rd.break=pre-mount

This dropped correctly to shell and generated the diagnostic logs that I
attached (rdsosreport-pre-mount.txt).
>From commandline I issued the mount command:
mount /dev/disk/by-uuid/c591f436-cc33-42b1-a272-1fc85386e2cb /sysroot/
without any problem, then control-d and then the dracut droped again to the
emergency shell and generated the other log I attached
(rdsosreport-pre-mount-2.txt).
After I simply issue control-d and then start the boot process  presenting the
banner Opensuse 13.2 but problems didn't solve as this time systemd complain
about the fact that cannot mount (?) the root filesystem (that I mount during
dracut emergency console) and drop me to a emergency login where I find that
the rootfs is correctly mounted and where I started (manually) the network and
the ssh daemon to access from remote (I attache also the dump of the journal
regarding this issue where at line you can see the issue:

May 21 08:42:24 casaregno systemd[1]: Timed out waiting for device
dev-disk-by\x2dlabel-rootfs.device.

Here is the environment:
[/etc/fstab]
...
LABEL=rootfs /                    btrfs       compress        1 1
LABEL=rootfs /usr/local btrfs subvol=usr/local,compress 0 0
LABEL=rootfs /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
#LABEL=rootfs /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
#LABEL=rootfs /home btrfs subvol=home 0 0
LABEL=rootfs /opt btrfs subvol=opt 0 0
LABEL=rootfs /srv btrfs subvol=srv 0 0
LABEL=rootfs /tmp btrfs subvol=tmp 0 0
LABEL=rootfs /var/crash btrfs subvol=var/crash 0 0
#LABEL=rootfs /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
#LABEL=rootfs /var/lib/named btrfs subvol=var/lib/named 0 0
#LABEL=rootfs /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
LABEL=rootfs /var/log btrfs subvol=var/log 0 0
LABEL=rootfs /var/opt btrfs subvol=var/opt 0 0
LABEL=rootfs /var/spool btrfs subvol=var/spool 0 0
LABEL=rootfs /var/tmp btrfs subvol=var/tmp 0 0
LABEL=rootfs /.snapshots btrfs subvol=.snapshots 0 0
...


and the environment:
dracut-037-17.9.1.x86_64
kernel-desktop-devel-3.16.7-21.1.x86_64
kernel-devel-3.16.7-21.1.noarch
kernel-desktop-3.16.7-21.1.x86_64
btrfsmaintenance-0.1-1.1.noarch
btrfsprogs-3.16.2-4.1.x86_64
plymouth-dracut-0.9.0-1.1.x86_64
kernel-source-3.16.7-21.1.noarch
libbtrfs0-3.16.2-4.1.x86_64
kernel-macros-3.16.7-21.1.noarch
kernel-firmware-20141122git-5.1.noarch