I have asked this question first in the scientific linux forum, but since CentOS7 and Scientific Linux 7 are rather similar this could be of interest to CentOS7 users.

I have a HP ZBook 14, with ATI Radeon graphics card and LUKS encrypted hard drive. This computer in under Scientific Linux with GNOME 3 and has worked without issue since January. This morning, after asking for the decryption password of the drive, the computer froze to a black screen, showing only a mouse pointer instead of the banner.
Switching to a console, a message 'A start job is running for Wait for Plymouth Boot screen to quit (13min/no limit)' showed up.
I was able to reboot the computer in rescue mode, and change the target from graphical to multi-user for systemd. The computer boots in text mode (runlevel 3 in System V terminology) and X can be started with startx.

If possible, I would like to restore full graphical login.
What is the role of pymouthd ? Does it simply show a banner ? Can it be eliminated from the boot sequence without trouble ? Or do I need to use an alternative login manager to gdm ?

I have found links reporting similar issues in Oracle Linux and CentOS but no solution.

https://unix.stackexchange.com/quest...-plymouth-boot
https://unix.stackexchange.com/quest...-gnome-upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1205610
https://support.oracle.com/knowledge...2433775_1.html

My guess is that some process is holding up the boot process and that plymouth is hiding the problem with its graphical screen shown during the bootstrap. Check for a "boot.log" file under /var/log. There's probably a message in that file telling you what boot step is holding up the boot process until it finally times out. IMHO, 13 minutes seems a little excessive.

It's my understanding that plymouth is just eye-candy for those who do not want to see bootstrap messages when Linux starts. (I happen to like the messages.) You can likely disable it using a configuration tool on RedHat/CentOS/Scientific. You should be able to eliminate the graphical startup stuff using a grub boot command line setting. If memory serves, that was the reason I added "quiet splash=verbose". You could try one or the other (or both) option by editing the grub entry's command line before letting Linux boot. Which ever one gets rid of the graphical display can then be incorporated into your grub command line by default using the grub config tools on your system. (I'm an openSUSE user and tweaking the grub parameters can easily be done using YaST/YaST2 so I'm not up to date on the current RH/CentOS/etc. management tools. Sorry.)

BTW: I'm surprised to see anyone still using Scientific Linux. I seem to recall reading (a couple of years ago) that the team at Fermilab that sponsored/supported it was getting out of the distribution maintenance game. Apparently I either misread that or they've changed course. Cool either way. I considered it for use at home a while back as it includes by default many of the tools I use.

HTH...

I have already tried to disable plymouth by editing the grub command line adding plymouth.enable=0, but
plymouth was still launched at startup, and hanged as if I had done nothing. I may have a better chance by editing the grub config file now that I can again boot the computer. I have looked at boot.log, but
did not find anything useful there. The problem is that I had to boot in rescue mode first, and the boot.log is the one generated at that moment. If older boot.log files are kept on the system, maybe there will be a hint of what is causing plymouth to freeze. The only thing I recall is some message during the boot process complaining about firmware and another about VCE.

Concerning Scientific Linux, the situation is that CERN was first to decide to make their Scientific Linux version a CentOS spin (Linux CERN 7) instead of doing the maintenance themselves.
Then, Fermilab followed suit and similarly decided that instead of SL8 there would be a CentOS 8 spin. But SL7 is still receiving upgrades. Of course, when it reaches EOL, only CentOS 8 will remain.

Why are you running a server focused OS on a laptop?
You can always us KVM to run Scientific Linux in as a vm guest.


Regarding CERN decision: https://listserv.fnal.gov/scripts/wa...E;11d6001.1904