Bug 4702

Summary:	Grub and systemd: Failsafe don't works
Product:	Mageia	Reporter:	Pierre Jarillon <jarillon>
Component:	Installer	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	davidwhodgins, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	systemd	CVE:
Status comment:

Description Pierre Jarillon 2012-02-26 03:12:45 CET

With Grub, the choice of failsafe leads to kdm  (graphical target).

With systemd, runlevels are not used (Mageia 2 beta 1).
How to get the same "runlevel" as init 1  or init 3 with systemd?

Comment 1 Dave Hodgins 2012-02-26 03:45:45 CET

From http://fedoraproject.org/wiki/How_to_debug_Systemd_problems#Boot_into_rescue_mode_or_to_a_emergency_shell

To boot directly into rescue mode add systemd.unit=rescue.target or 1 to the kernel command line. 

To boot directly into emergency shell add systemd.unit=emergency.target or emergency to the kernel command line.

The rescue mode is the same as run level 1 (everything mounted, but
just systemd and /bin/sh running.

In emergency mode only the root filesystem is mounted.

I've just tested both specifying either 1 or 3 in the kernel options,
and both work, although there are some messages on the screen about
things like cups being started, when they are not actually started.

I think the grub/lilo entry for the failsafe boot should add the 1 to
the kernel options.

CC: (none) => davidwhodgins

Comment 2 Manuel Hiebel 2012-02-26 12:12:00 CET

Thierry, do we need to change the drakxtools/installer against that ?

CC: (none) => thierry.vignaud

Comment 3 Thierry Vignaud 2012-02-26 15:40:54 CET

I would have systemd handling the "failsafe" word instead

Assignee: bugsquad => mageia
Source RPM: (none) => systemd

Comment 4 Colin Guthrie 2012-02-26 18:42:04 CET

So failsafe should be a synonym for systemd.unit=rescue.target? (that seems to be what initscripts does if the askrunlevel system does not kick in.

We could in theory use some kind of plymouth interaction to ask which target to load (much like askrunlevel) but I doubt it's worth the effort.

Also regarding cups being started, you should probably be aware that cups is now socket activated. Meaning that the cups binary will not actually be started until something needs it. That is, systemd will listen on the ipp TCP port and on the /var/run/cups/cups.sock unix socket file and only when some other app tries to use either will the binary be started. This is obviously much quicker during the boot phase and not very noticeable (with regards to delays) during run time when cups is first used. It is, of course, by design.

Comment 5 Colin Guthrie 2012-02-26 22:06:24 CET

OK, added a patch for this. It'll be in the next systemd update (won't push right now as will wait for a few more issues, but it will work, I'm confident of that!).

Status: NEW => RESOLVED
Resolution: (none) => FIXED