
Am Dienstag, 2. April 2019, 22:16:50 schrieb Axel Braun:
Markos found out that it works for him when removes the "nofail" option from the fstab entry for /home (and use "defaults" instead), maybe this would help here too?
When I remove the nofail option I end up in a rescue session.
If that is the case, the mount must have failed before IMHO and the failure was only ignored because of the "nofail" option. Although I suppose you would have had different problems then... Maybe you made a mistake when modifying the fstab entry? Just to be sure: if "nofail" is the only mount option, you must replace it with "defaults", otherwise it should be enough to just omit it. Oh, and I forgot to mention that you might have to run mkinitrd too after the change, some things are mounted before / is available.
Otherwise, this should work too I suppose:
When I umount /home and mount it manually via systemctl start home.mount again the state is fixed and I can log in anymore.
(taken from the second bug report, you need to do that *before* logging in of course)
Sure. But seems not to be the silver bullet yet.
Of course not. It was rather meant as a workaround to get a working desktop session until the bug is fixed. Also, if that works it certainly "proves" that you actually have the same (underlying) problem.
And it leaves the question open why it suddenly fails.
Indeed. Or why it did not fail before... Especially as the problem started with earlier already for other people. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org