Comment # 20 on bug 1169783 from IT wrx

(In reply to Cliff Zhao from comment #19)
> (In reply to Thomas Zimmermann from comment #18)
> > FTR: This bug also happens on new installs.
> 
> Okay Thomas, thank you so much for the confirmation. I will switch back to
> this issue when I finished the openSUSE:Leap gap problem.

Forgive my ignorance, but isn't the openSUSE:Leap gap problem more of a longer
term improvement/feature/project? while this *bug* breaks booting(!) for
installs using encrypted filesystems. It seems to me, this would be more
urgent. 

Also, as an end user who is largely ignorant in regards to openQA, i would
expect openQA to catch something that breaks booting, so i wonder why it
doesn't.  If there is something needed, maybe that can be highlighted, so
people can know what needs to be done. 

I've used arch linux for years (prior to my recent ongoing move to TW) and it
hasn't broken my ability to boot the OS, and TW is supposed to be stabilized. 
Maybe plymouth could fail gracefully into text mode, instead of just hanging
the whole booting process? I think i purposely didn't install plymouth on arch
machines, b/c of problems with it in the past. Maybe i'll try removing all the
plymouth packages in my TW and see if that lets me enter my luks passphrases
without any trouble. I don't *need* my luks password entry themed anyways...
Also, plymouth has 0.9.x version numbers. Maybe they mean it, and distros just
aren't taking it seriously? Maybe the TW installer should just not install
plymouth, unless/until it's fully tested and supported under all supported
config conditions (disk encryption, etc).

BTW, my TW never went into any rescue mode. I'm guessing, b/c plymouth worked
for my root drive partitions, but not an aux drive that was in fstab without
"nofail" option.