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?
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
Thierry, do we need to change the drakxtools/installer against that ?
CC: (none) => thierry.vignaud
I would have systemd handling the "failsafe" word instead
Assignee: bugsquad => mageiaSource RPM: (none) => systemd
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.
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 => RESOLVEDResolution: (none) => FIXED