Bug 689090 - Booting into rescue mode hangs up
Summary: Booting into rescue mode hangs up
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-19 09:21 UTC by Joachim Backes
Modified: 2011-04-06 14:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-06 14:15:56 UTC


Attachments (Terms of Use)

Description Joachim Backes 2011-03-19 09:21:54 UTC
Description of problem:
For booting into the rescue mode I added the kernel parameter "systemd.unit=rescue.target" to grub boot line. The system boots, but it hangs up after the line "System Rescue Shell" appears on the boot screen.

Version-Release number of selected component (if applicable):
systemd-20-1.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1.Add "systemd.unit=rescue.target" to grub boot line and boot
2.
3.
  
Actual results:
The last msg on the boot screen is "Starting Rescue Shell", then nothing more happens. No relevant info in /var/log/messages found.

Expected results:
Running rescue shell

Additional info:

Comment 1 Joachim Backes 2011-03-19 09:26:38 UTC
(In reply to comment #0)
> Description of problem:
> For booting into the rescue mode I added the kernel parameter
> "systemd.unit=rescue.target" to grub boot line. The system boots, but it hangs
> up after the line "System Rescue Shell" appears on the boot screen.

Sorry, I meant "Starting Rescue Shell", not "System Rescue Shell".

> 
> Version-Release number of selected component (if applicable):
> systemd-20-1.fc15.x86_64
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1.Add "systemd.unit=rescue.target" to grub boot line and boot
> 2.
> 3.
> 
> Actual results:
> The last msg on the boot screen is "Starting Rescue Shell", then nothing more
> happens. No relevant info in /var/log/messages found.
> 
> Expected results:
> Running rescue shell
> 
> Additional info:

Comment 2 Joachim Backes 2011-03-19 13:54:35 UTC
What I see on tty0 screen top in this state is the normal system prompt on tty's (in blue color), but without prompt for account, followed by the normal boot messages.

My CPU:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
CPU socket(s):         1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 15
Stepping:              6
CPU MHz:               1861.496
BogoMIPS:              3722.50
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              2048K
NUMA node0 CPU(s):     0,1

Model: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz

Comment 3 tuxor 2011-03-19 14:45:46 UTC
I'm sorry, but I was not able to reproduce this running Fedora 15 x86_64 and the latest updates (same version of systemd as you stated above). I'm also using an Intel(R) Core(TM)2 CPU (different model).

Because of the bug I'm undergoing at the moment (https://bugzilla.redhat.com/show_bug.cgi?id=689093), I thought, your problem might be related to SELinux, as well. But I tried it with SELinux "enforcing" and "disabled" and never ran int, what you describe here.

I think, more information will be necessary, to find the reason for this behaviour. Unfortunately I'm not quite familiar with systemd and the Rescue Shell, so I can't say, which config/log-files might be helpful.

Comment 4 Dennis Gilmore 2011-03-21 08:47:46 UTC
on a sparc64 box with systemd-20 i get 

Starting Console System Startup Logging...
Starting LSB: reset the system activity logs...
Starting LSB: Moves the generated persistent udev rules to /etc/udev/rules.d...
Starting LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
Starting Rescue Shell...

box is headless the shell should have started on the serial console im attached to

Comment 5 Joachim Backes 2011-03-21 09:20:03 UTC
(In reply to comment #3)
> I'm sorry, but I was not able to reproduce this running Fedora 15 x86_64 and
> the latest updates (same version of systemd as you stated above). I'm also
> using an Intel(R) Core(TM)2 CPU (different model).
> 
> Because of the bug I'm undergoing at the moment
> (https://bugzilla.redhat.com/show_bug.cgi?id=689093), I thought, your problem
> might be related to SELinux, as well. But I tried it with SELinux "enforcing"
> and "disabled" and never ran int, what you describe here.

On my box: selinux=disabled

> 
> I think, more information will be necessary, to find the reason for this
> behaviour. Unfortunately I'm not quite familiar with systemd and the Rescue
> Shell, so I can't say, which config/log-files might be helpful.

Comment 6 Adam Williamson 2011-03-25 18:44:57 UTC
Discussed at the 2011-03-25 blocker review meeting. We agreed that unless this is shown to affect installer / live images, it is not a blocker, as the relevant criterion speaks only about the installer's rescue mode:

"The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations "

More testing is needed to determine the exact impact of this bug. If it does affect the installer, it should be re-assessed as a blocker.

Comment 7 Lennart Poettering 2011-03-29 00:08:49 UTC
Maybe you already have a prompt but it is obfuscated by the other output? can you type something?

What happens if you wait for 3min?

Comment 8 Joachim Backes 2011-03-29 06:56:24 UTC
Removing RHGB and QUIET from the grub boot line, the last message after a lot of boot messages and after "Starting rescue shell" is:

... systemd[1]: Startup finished in ...ms ...us ...

No command prompt, even after waiting more than 3 minutes. If I enter the Return key in the boot tty, the screen is scrolled up for 1 line (no output).

Comment 9 Lennart Poettering 2011-04-06 01:41:29 UTC
Hmm, anyway you can login, maybe via ssh and get me a "ps xawuf", a "systemctl list-units" and a "systemctl list-jobs" output of this?

Does "emergency" on the kernel cmdline give you a working shell?

Can you boot with "systemd.log_level=debug systemd.log_target=kmsg" and get me last log output this generated before it got stuck? (photo is fine)

Please test this with the current F15 version (23)

Comment 10 Joachim Backes 2011-04-06 06:20:37 UTC
Booting with systemd.units=rescue.target now boots into a shell prompt. This is with

systemd-22-1.fc15.x86_64
systemd-units-22-1.fc15.x86_64

So I got rid from the problems I mentioned in the DEscription section of this BZ.

Comment 11 Michal Schmidt 2011-04-06 14:15:56 UTC
OK, so I am closing this bug. Reopen if the problem reappears.


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