Bug 18685

Summary: systemd kills console tty1 (nothing ever written to screen)
Product: Mageia Reporter: David Walser <luigiwalser>
Component: RPM PackagesAssignee: Thomas Backlund <tmb>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: Normal CC: cae, ftg, mageia
Version: Cauldron   
Target Milestone: ---   
Hardware: All   
OS: Linux   
See Also: https://bugs.mageia.org/show_bug.cgi?id=18746
Whiteboard:
Source RPM: systemd-230-1.mga6.src.rpm CVE:
Status comment:

Description David Walser 2016-06-11 00:25:50 CEST
Shortly after systemd starts booting, you very briefly see it print something to the screen (including its version number) and then the screen reverts back to the text screen that was left over from the bootloader.

It never switches back, no boot messages are ever printed, and the console tty1 never becomes available.  This is true whether you do init=/bin/bash, boot to single-user mode, or boot to multi-user.target.  The system is unusable in all scenarios.  The only time it's usable is if you're booting to graphical.target, but you still see no boot messages, it just appears frozen until the DM suddenly appears.

This has happened on a fresh install and two systems upgraded from Mageia 5.  All are VMWare VMs.  These are my first Mageia 6 installs, so I don't know if systemd 229 or earlier exhibited this behavior.
Comment 1 David Walser 2016-06-13 15:54:16 CEST
Even in the GUI, switching to tty2 shows the same text from the bootloader, but no tty2 console.
Comment 2 David Walser 2016-06-13 16:04:11 CEST
Probably related:
systemd[1]: Starting Show Plymouth Boot Screen...
plymouth[569]: error: unexpectedly disconnected from boot status daemon
systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: Failed to start Show Plymouth Boot Screen.
systemd[1]: plymouth-start.service: Unit entered failed state.
systemd[1]: plymouth-start.service: Failed with result 'core-dump'.
Comment 3 Colin Guthrie 2016-06-13 16:46:58 CEST
If it happens with init=/bin/bash and systemd is not used in your initrd, then it's likely not a systemd bug.

As you stated, the fact plymouth crashes looks interesting.

See if you can get the core out of plymouth and we can see if it can be patched/fixed. etc.
Comment 4 David Walser 2016-06-13 16:49:02 CEST
Well, even if plymouth crashes, that shouldn't prevent the normal text console from ever being shown.  As for init=/bin/bash, that shouldn't even call plymouth, so I'm not sure what the deal is there.

How can I get the core?
Comment 5 Colin Guthrie 2016-06-13 17:16:54 CEST
True re the /bin/bash plymouth part... Dunno what could be wrong there, but doesn't immediately smell like it's specifically systemd related... hard to say. I presume taking off "splash" and "quiet" from the command line doesn't help?
Comment 6 David Walser 2016-06-13 21:38:38 CEST
Interesting question.  They actually don't have splash on their kernel command lines already.  Adding it doesn't help either.  Removing quiet just makes it print some early boot messages from the kernel until it also clears the screen and reverts it back to what was printed by the bootloader.  So, that segv from plymouth-start was from no "splash".
Comment 7 Charles Edwards 2016-06-13 22:24:00 CEST
I use splash=verbose and have /etc/sysconfig/bootsplash is set SPLASH=no and I boot
to init 3.

Boot and boot progress is on TTY1 and remains visible even after init 3 is reached.
When target multi-user is reached I switch, am switched, to TTY2 with for login prompt.

If I start DM on TTY2 it is run on TTY2 leaving 4 additional TTYs that are usable
TTY3-TTY6

CC: (none) => cae

Comment 8 David Walser 2016-06-16 19:03:20 CEST
I have no tried a virtualbox install, but as not everyone is seeing this issue, it could be specific to VMWare guests.
Comment 9 David Walser 2016-06-17 12:37:32 CEST
Frank said he saw this issue on real hardware (on the discuss ml).

CC: (none) => ftg

Comment 10 Frank Griffin 2016-06-17 14:54:16 CEST
(In reply to David Walser from comment #9)
> Frank said he saw this issue on real hardware (on the discuss ml).

Not quite this problem, though.  I see the systemd version message come up, and nothing else, but that stays on tty1 until the DM starts.  What's missing are all the target and service OK/FAILURE that systemd normally puts out.  I assumed they've been suppressed for release.
Comment 11 David Walser 2016-06-17 14:57:13 CEST
I see the systemd version message come up, then it disappears and it goes back to console output from the bootloader, so not quite the same thing indeed.

However, I see no valid reason the OK/Failed messages would be suppressed on purpose.
Comment 12 Colin Guthrie 2016-06-17 16:25:32 CEST
These OK/failed messages are generally only suppressed internally in systemd if "quiet" is on the command line. Is that the case here?
Comment 13 Colin Guthrie 2016-06-17 16:29:12 CEST
(note that "quiet" should suppress lots of things - e.g. messages from the kernel and, in theory, the systemd version message. Strange that it should be showing now... Wonder if that's coming from somewhere strange... (e.g. initrd where it's somehow not suppressed properly)
Thierry Vignaud 2016-06-23 09:09:05 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18746

Comment 14 David Walser 2016-06-23 15:19:14 CEST
Yes this is the same as Bug 18746.  I hadn't noticed that the 4.4 kernel update in Mageia 5 did the same exact thing to my consoles there.  Now all of my server VMs are broken :o(  This is a disaster.

*** This bug has been marked as a duplicate of bug 18746 ***

Status: NEW => RESOLVED
CC: (none) => mageia
Resolution: (none) => DUPLICATE
Assignee: mageia => tmb

Comment 15 Thomas Backlund 2016-06-23 15:42:55 CEST
just remove any "vga=" stuff to get consoles back for now