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:
(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:
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
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.
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
(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.
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.
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?
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).
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)
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.
OK, so I am closing this bug. Reopen if the problem reappears.