Bug 903169 - switching from "rescue" mode back to "default" causes breakage (of VTs in particular)
Summary: switching from "rescue" mode back to "default" causes breakage (of VTs in par...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-23 11:08 UTC by Alan Jenkins
Modified: 2015-10-20 14:17 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-20 14:17:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alan Jenkins 2013-01-23 11:08:52 UTC
Description of problem:

I found that switching between "rescue" and "default" (graphical) targets on a KDE install killed all my text consoles (Ctrl+Alt+F2 etc).

Presumably a problem with starting the getty/login process.  There are a couple of other symptoms too, though they may be more apparent on F17 than F18.


Version-Release number of selected component (if applicable):

systemd-197.1-fc18.1-x86_64
systemd-44-23.fc17.x86_64


How reproducible:

Seems 100% deterministic.  I've tried it many times now.


Steps to Reproduce:

1. Install Fedora :).

 - I have Fedora 18 from netinstall on a VM, with the KDE desktop package group.
 - I also have Fedora 17 on both baremetal and VM, installed from the KDE LiveCD.  These steps apply equally to my F17 installs.

2. Start up the computer.
 => KDE login manager appears

3. Ctrl+Alt+F2 (switch to VT2) and log in as root.  (Or a user that can use sudo to run systemctl.   Results are the same either way).

4. "systemctl rescue".
 => rescue mode shell appears

5. "systemctl default", as the message suggests, to switch out of rescue mode.
 => KDE login manager appears again

6. Ctrl+Alt+F2, i.e. try to switch to VT2 again


Actual results:

Can't switch to VT2 (or any other).  Screen may flicker for a bit (F17 in VM, though not F18), but sticks on the KDE login manager.


Expected results:

VT2 should still be functional after switching to and from rescue mode.


Additional info:

If rescue mode is exited with Ctrl+D instead of "systemctl rescue", that doesn't seem to cause the same problem.  NOTE ctrl+alt+f2 may *appear* to not work.  But once you start trying other VTs, they'll work - including a text console on VT1 - what's happened is that X has switched to running on VT2.

"chvt 3" didn't bring up a text console either, so I guess it's not just a keyboard-handling problem.


On the F18 Vm, I logged into KDE and checked "systemctl", but it didn't show any failed units (other than rngd and isdn, which are always shown as failed).  "journalctl" doesn't seem useful either.  The red lines are all expected errors like rngd.  And I don't see anything relevant in the lines coloured as high-intensity white.


The above steps also cause a problem with handling of ctrl+alt+del.  On F17, I noticed that ctrl+alt+del was no longer caught by the login manager, or by the KDE session.  Instead of a confirmation popup appearing, systemd rebooted without confirmation.

On F18 VM, ctrl+alt+del seems to work properly in the KDE login manager.  Weirdly, I did notice it not asking for confirmation when used inside a KDE session (i.e. after logging in).  I've only tried that once though.


On baremetal F17 only, I also noticed a problem with kexec.  If you follow the steps above, then log into KDE, "kexec -l" followed by "reboot" would cause an internal error in systemd's "shutdown" command.  This happens after systemd returned control to the initrd, at about the point you'd expect the new kernel to be loaded.  You need to remove the "rhgb" boot option, or you'll only see the graphical screen and won't be able to see the error messages.  But this problem doesn't seem to happen in either the F18 VM or F17 VM.

Comment 1 Fedora End Of Life 2013-12-21 10:44:24 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 2 Jan Kurik 2015-07-15 14:52:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 3 Jan Synacek 2015-10-20 14:17:03 UTC
This is no longer reproducible (I'm testing with the latest F23 and KDE).

# rpm -q systemd
systemd-222-7.fc23.x86_64


Note You need to log in before you can comment on or make changes to this bug.