I just installed Tumbleweed using the latest DVD installer image. Everything went smoothly, but on boot up it gets stuck at “A start job is running for /sysroot”.
It stays at this prompt for 4m32s and then the screen goes blank and never returns.
I experienced this issue on my other system when I recently did an update. The 3.19.1 kernel caused this issue, but the booting with an older kernel worked fine.
Has anyone else experienced this bug and is there a workaround?
Thanks.
The only problem that I have had with 3.19 kernels, is that the “nvidia” driver would not build.
Your problem looks like a difficulty in the “initrd”.
Are you doing anything special such as using an LVM or RAID that could cause problems in the “initrd”?
Nothing that I’m aware of. I let the installer setup the partitioning scheme automatically and I’m defninitely not using RAID.
Can you boot in safe mode or to a console ? That way you can add a repository for kernels on the commandline you must type the following if possible
sudo zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ Kernel
zypper ref
sudo zypper in kernel-desktop
This will add a repo with kernel 4.0 you might try if this resolves your issue.
Sorry I haven’t responded as I’ve been a bit busy. So…I ran the machine for a bit on the error message. After letting it run for near 10 minutes, I finally got error message to pop up. There was a lot, but I was able to discern that there were transaction errors with my root Btrfs partition that was locking the boot process and not allowing it to run.
I booted a live usb and used Gparted to check and repair the partition. Upon reboot, the machine started up with no issues. This is the first time I’ve used Btrfs in one of my main machines and I don’t know if this is something that happened because I’m using Tumbleweed, but it gives me apprehension about using it in the future. I’m going to watch it and hopefully it doesn’t happen again.
The strangest thing is that I did a full update and a reboot with no issues. The problem occured on the second reboot after the update.
Sorry for having to say the same about my responsiveness as you had to say. I am glad you solved your problem but my what a weird issue is that. I think I will not touch that Btrfs for a while I am still using ext4.
I think it might have been one of those weird issues that creeps up when running a rolling release. Something changed with a kernel update that altered how the system interacted with Btrfs partitions and the filesystem checks. I think once I ran the check and it was able to remount the partition with the new kernel everything became ok again. I haven’t experienced any such behavior since at least. As you said though, it concerned me enough that I’m sticking with EXT4 in the near term for my installations.
Hello,
today it happend to me. The Laptop updated to kernel 3.19.3 and is unable to mount sysroot after reboot.
Is there a way to rebuild the btrfs (or bootloader related things) from booting another working kernel? The kernel 3.19.0-2 is still booting.
Best regards
Alex
Got it. Booted into the last working kernel and let mkinitrd recreate all bootloader images again. After that I installed again the efi bootloader using grub2-install. Now kernel 3.19.3 is booting.
[FIXED]
Yes, that worked for me on a machine where I had a previous kernel that I could boot into. On the machine in question here, it happened on a fresh install where I only had the one kernel installed and thus couldn’t go to a previous kernel. Good that you got it working.
nothing special with Uefi bootloader just grub2-install mkconfig…?? or you did meniton smth bout mkinitrd. i.e. what exact steps di you take
This happened to me on 4/10. I was able to repair it by loading an older kernel and running mkinitrd. It has not happened since.
Since all my partitions are encrypted, it made things…interesting, as I was unsure what the problem was. I was able to decrypt the boot partition with no issues, but obviousy I could not access the /sysroot partition. I am not sure what actuall went wrong. to be honest. Some are blaming BTRFS, which may be true, but an update did not break the system, It was working fine the day before.
I’ve experienced this problem too. Could you please explain how you used mkinitrd to recreate the bootloader images (I heard mkinitrd was an older command that was no longer used with systemd) and how you re-installed the bootloader with grub2-install.
I ran the command *mkinitrd, *FWIW. I did not have to re-configure grub.
I had this same error booting Tumbleweed (3.19.3) over the weekend, but no amount of fsck repairing was going to fix it. Nor could I go back to a previous kernel, as it was a fresh install!
For the sake of anyone else who also got to this thread through a search engine, the problem was caused a btrfs deadlock fixed in kernel 3.19.5 (fortunately backported to 3.19.4): https://btrfs.wiki.kernel.org/index.php/Gotchas
To fix it, I procured a USB stick with the OpenSUSE rescue CD on it and ran btrfs-zero-log on the affected partition*. I was then able to reboot normally into OpenSUSE (on 3.19.3), and have now upgraded to 3.19.4 (which includes a fix for this issue).
(* as I have full-disk encryption enabled via LVM/LUKS, this was a little trickier than usual, but ended up being a variation of cryptsetup luksOpen /dev/sda1 encrypted_volume and mount /dev/mapper/encrypted_volume /media/hdd to get to the affected partition.)
After the “cryptsetup”, you can use:
# vgchange -a y
to make the LVM volumes visible. Then look in “/dev/mapper” to see the device names for those volumes.