I did an update yesterday and now the boot gets stuck on this screen.
http://i.imgur.com/eFUxUrX.jpg?1
I can’t even Ctrl+alt+F2
Advanced boot with another kernel also gets stuck here.
Does disk fail mounting??
LVM+encrypted drive. But the encryption screen has passed fine.
p.s. The screen repeated the initial lines a few times after I used esc back and forth. The last line was “Started dracut pre-mount hook”.
Looks like its related to this. I’m having the same issue.
https://bugzilla.opensuse.org/show_bug.cgi?id=971023
I thought LEAP was suppose to be stable 
Thank you for the link ！
Funny I encountered both phenomenom on my two machines, both with encrypted drive.
On my other machine I also had the problem of “no desktop after login credentials input” after an update. I thought they were not related.
So I decided to give up linux on the other machine and reinstall TW instead of leap 42.1 on this machine.
IMO, these things are not stable but opnesuse opt for them as the default installation:
Plasma5, btrfs, lvm.
Encyrpted drive just brings more trouble.
How are you liking TW? How stable do you find it?
I have a portable drive that has TW installed for a very long time. It was first installed about three years ago, but was used from time to time. Now I have started using it again at work. I’d say it is very solid with default suse setup (three years ago).
My suggestion is avoid using btrfs or even LVM partition. Drive encryption in suse/leap is apparently broken at the moment to me (two systems died of it in less than a month).
Hi,
i’m the reporter of the bug you cited. It’s incredible that a big problem like this has not been detected before (how many people are actually using Leap ?!?!?)
Unfortunately i think nobody is working on the bug at the moment, if you are interested in the resolution, please sign in into bugzilla,“vote” for the bug and give your feedback. I think (hope) this can help us to catch the attention of the developers on this (in my opinion) critical bug
I ran into this last night, but only on one computer. My file server without a GUI updated just fine. My main desktop, however, wouldn’t boot.
This is how I fixed it. The problem is the /boot/grub2/grub.cfg file isn’t set quite right. The main problem is the root partition’s UUID isn’t set at all. There is a secondary problem where the resume partition is set wrong. The problem line in grub.cfg looks something like this:
linux vmlinuz-4.1.20-11-default root=UUID= resume=/dev/sdb2 splash=silent quiet showopts
What I did was to boot with the installation DVD and go through to the point just after the installer asks for my partition password. Once it does that, all devices are set so we can look at them. Drop into console with Ctrl-Alt-F2. We need to determine the UUID of root. Look in /dev/mapper and /dev/disk/by-uuid to find out what this is. I use an encrypted LVM for root, and I know it’s name, so it’s easy to find. The UUID is a long hex string, such as:
3f07e22b-fb69-4906-85f6-de7b0b0ce6a2
The symlink /dev/myvg/root will point to something like /dev/dm-3. Find out which symlink in /dev/disk/by-uuid also points to /dev/dm-3. You now have the UUID.
Then, if you don’t know your resume partition (usually swap), you’ll need to mount your root somewhere and look at /etc/fstab and possibly /etc/crypttab to get that. I knew mine. Possibly, if you don’t know and can’t find out what that is, change the bit to “noresume”, though I can’t verify that works. Try it anyway.
Put that UUID into place and fix the resume partition. My correct line looks like this:
linux vmlinuz-4.1.20-11-default root=UUID=3f07e22b-fb69-4906-85f6-de7b0b0ce6a2 resume=/dev/mapper/cr_swap splash=silent quiet showopts
There will be a second place this shows up, so fix that one as well.
Once I fixed the UUID, boot happened normally.
I suspect the real bug is in the script /etc/grub.d/10_linux which actually generates the bits of grub.cfg, but I don’t know enough to say how to fix that.
Hi Dogora,
following your suggestion i booted with the rescue disk and I mounted both boot and root partition. Then i had a look into grub.cfg. the root uuid was the right one so nothing to change here. “resume” partition was wrong so i tried at first to correct it and, secondly i substituted “resume=…” with “noresume”. I both case the machine still can’t boot. Please note that, in my case, only swap, tmp and another data partition were encrypted. root partition was a plain logical volume.
Now i’m going to do a test with a minimal text only installation to see if i can confirm the different behavior you have observed.
Thank you for your feedback
Hmmm… In my case, the error was obvious and easy - the missing UUID. I’d be tempted to try the partition name instead (/dev/sda2 or such) as your root isn’t encrypted or anything. The UUID is easy to mess up. Or, maybe the right entry from /dev/disk/by-id.
Maybe you need to recreate the initrd, not that I have any idea about how to do that with an unbootable system. I get that idea from the bug report referenced in the bug report in this thread (#971995).
Or, bug 971023 talks about problems with encrypted /tmp and incorrect permissions. Sadly, no workaround is posted that I can see.
I did a further test without any graphical environment and i haven’t had any problem. so i can confirm the problem is affecting ONLY gui installation, text only installation seems to boot fine after patching.
I’ve just posted an update to the bug
https://bugzilla.novell.com/show_bug.cgi?id=971023
Still can’t figure out how a bug like this can remain unnoticed and unresolved for so much time!
Several possibilities come to mind. Do you ever log to a GUI as root? That can inadvertently change ownership in a users directory to root and stop GUI login
Do you have autologin set best to not do that since it hides problems.
Out of space on the root partition due to snapper snapshots can stop the GUI from starting
Video driver problem or not being updated with a kernel update can do it too.
I suggest this is a difficult problem to reproduce and may well be hardware related. That is why it has not been fixed. Not all people are seeing this
Hi, thank you for your reply.
I answer to you in the same order:
As a general consideration i have to say that Opensuse, since 13.1, is afflicted by severe bug related to storage management with complex (raid+lvm) partitioning layout. My personal opinion is that this sector is not tested enough and developers have not enough time to dedicate to those kind of problem.
Just to be clear (sorry, english is not my native language), i’m perfectly conscious that opensuse is an opensource project with very few founds an with a lot of brave volunteers working on it, i don’t want to do a negative criticism but a constructive one.