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
http://bugzilla.opensuse.org/show_bug.cgi?id=931787 Bug ID: 931787 Summary: dracut stop booting after btrfs rootfilesystem went full Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: diego.ercolani@gmail.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- Created attachment 634966 --> http://bugzilla.opensuse.org/attachment.cgi?id=634966&action=edit 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). 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 -- You are receiving this mail because: You are on the CC list for the bug.