Description of problem: According to the sytemd documentation one can boot into runlevels 1 or 3 using the (grub) boot parameters: systemd.unit=rescue.target (for 1) or systemd.unit=multi-user.target (for 3) Moreover one can change the runlevel of a working machine by: systemctl isolate rescue.target (for 1) systemctl isolate multi-user.target (for 3) or systemctl isolate graphical.target (for 5) I tried them all with following results: Boot into 1: Does in fact boot into 5. Boot into 3: Once it booted to 3, but 2 other times went in fact to 5. Change from 5 to 3: worked ok twice. Change from 3 to 1 or from 5 to 1: did not work. That is to say, it went to 1, but it was impossible to login, because in place of the password prompt every time there appeared the error reading: "Failed to issue method call: Transaction is destructive". Change from 3 to 5: Twice it did not work. Also a third time trying command "init 5" (which is supposed to work as well), did not work either. No runlevel 5 was completed: hardly anything happened at all. This is one completely up to date Cauldron box using systemd for quite a while already and booting or rebooting every time without prblem (except as above).
Blocks: (none) => 2120
s/prblem/problem
@ Dick Is the problem still there in current cauldron (version systemd-37-13.mga2) ? When in grub menu, after choosing F3 and default, do I need to add "systemd.unit=multi-user.target", or is adding "3" enough? In updated cauldron I tried with "3", that gave some systemctl failed messages and then booting stopped.
CC: (none) => dmorganec, marja11
Marja: I will test it again, but I believe yes. '3' is supposed to work, but only to be compatible with sysvinit. The 'systemd...' is as per systemd documentation. See http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions and 'man systemd' --> KERNEL COMMAND LINE m.v.g.
My 'believe' was wrong (I am glad to say), there is improvement: * Changing from 5 to 1 (tried twice): not okay: same error as before. Also, the advertised "type Control-D to continue" is not working. * Changing from 1 to 3: okay now. * Changing from 3 to 5 (tried twice with same result): I get there okay, but I get an error (graphical display with odd font) upon logging into xfce4 with kdm, reading: WARNING CANNOT OPEN CONSOLEKIT SESSION. UNABLE TO OPEN SESSION. FAILED TO CONNECT TO SOCKET /CAR/RUN/DBUS/SYSTEM_BUS_SOCKET. NO SUCH FILE OR DIRECTORY. (All needed directories directly below "/" except /boot are on the same partition). Indeed terminal started from the desktop shows console-kit-daemon is not running. * Booting into 1: okay, works (although after the login prompt appear the words "Started singel service", making the prompt disappear. Can login after: [ Enter ] Login incorrect though. * Booting into 3: I get there okay again, but on the login prompt appears several bootup messages disturbing the entering of the userid. After a couple of [ Enter ] the login prompt is quiet and working. BTW, above is with kernel-desktop-3.1.2-0.rc1 on latest laptop. I hadn't gotten around to installing latest kernel. But Cauldron is otherwise up to date.
I stopped trying to test because I'm not sure I know enough and because atm, the time is missing to learn more. first cc'ing colin
CC: (none) => mageia
and now assigning to maintainer
Assignee: bugsquad => dmorganec
what about this bug with systemd 40 ?
Hardly any improvement, I'm afraid: Booting into 1: Prints quote Welcome to rescue mode. Use "systemctl default" or ^D to activate default mode. Failed to issue method call: Transaction is destructive unquote There is no login prompt. Entering the root password deos not give access to rescue mode (nothing happens). Booting into 3: okay now. Changing from 5 to 1: unchanged from original report. Changing from 3 to 5: seems to work okay (graphical target appears). But consolekit has not started normally. After logging in there appears a warning quote Warning, Cannot open ConsoleKit session: Unable to open session: Failed to connect to /var/run/dbus/system_bus_socket. No such file or directory. unquote and indeed ps shows consolekit-daemon is not running at all.
Source RPM: systemd-37-8.mga2 => systemd-40-2.mga2.src.rpm
can you look at: systemctl status dbus.socket output when going from 3 to 5? But I wonder if this is a bug in systemd itself. As dbus is socket activated in systemd, it should be perfectly possible to start console-kit before dbus itself is actually started provided systemd has already enumerated all the .socket files wanted by the next target and has opened all the sockets... and it seems this isn't happening when switching from 3 to 5 as otherwise systemd itself would have created (and started listening on) the /var/run/dbus/system_bus_socket file... That said, dbus should be started in runlevel3... (it's wanted by multi-user.target) and as such should already be available before switching to 5... so actually this is quite strange. Did you boot direct to 3 then swtich to 5? If so, can you check when booting direct to 3 that dbus is actually running and the system_bus_socket file does is exist and who is actually listening on it? e.g.: [colin@jimmy ~]$ sudo fuser -v /var/run/dbus/system_bus_socket USER PID ACCESS COMMAND /var/run/dbus/system_bus_socket: messagebus 1867 F.... dbus-daemon
Let's see: booting into runlevel 3: systemctl status dbu.socket dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (lib/systemd/system/dbus.socket; static) Active: active (running) since ....[date]; ..min .. s ago CGroup: name=systemd:/system/dbus.socket but: fuser -v /var/run/dbus/system_bus_socket Specified filename /var/run/system_bus_socket does not exist. Chaging to runlevel 5 and logging in: Same warning as before! and now still: systemctl status dbu.socket dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (lib/systemd/system/dbus.socket; static) Active: active (running) since ....[date]; ..min .. s ago CGroup: name=systemd:/system/dbus.socket But consolekit is not running BTW this is on a different Cauldron machine than my last comments: but the results appear to be similar!
Hmm, that's just weird... It's almost like something removes the socket after it's created :s I'll try and reproduce but not sure when I'll get time... hopefully on Wednesday.
This should be resolved in latest initscripts package. Basically the same as was reported in bug #4744 (I thought they were the same bugs, but it did seem kinda "new" when I knew I'd read the report a while ago!) Anyway, like I say should be fixed now.
Status: NEW => RESOLVEDResolution: (none) => FIXEDAssignee: dmorganec => mageiaSource RPM: systemd-40-2.mga2.src.rpm => initscripts