| Summary: | systemd kills console tty1 (nothing ever written to screen) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | RPM Packages | Assignee: | 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
Even in the GUI, switching to tty2 shows the same text from the bootloader, but no tty2 console. 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'. 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. 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? 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? 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". 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 I have no tried a virtualbox install, but as not everyone is seeing this issue, it could be specific to VMWare guests. Frank said he saw this issue on real hardware (on the discuss ml). CC:
(none) =>
ftg (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. 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. These OK/failed messages are generally only suppressed internally in systemd if "quiet" is on the command line. Is that the case here? (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 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 just remove any "vga=" stuff to get consoles back for now |