[systemd-devel] troubleshooting different behaviour of systemd between f16 and f18

Thierry Parmentelat thierry.parmentelat at inria.fr
Mon Feb 11 04:37:08 PST 2013


Hi
Feel free to redirect me to some other place if needed :)

So, we have a BootCD that is intended for remotely managed machines
In a nutshell, we need to redefine the whole init sequence, and what we had on f12 and f14 boxes was essentially a set of 2 init scripts, one for rough system initialization (pl_sysinit), and one for downloading a stage2 python script (pl_boot), in this order of course

----
I'd done the job of adapting to systemd for f16 at the time; my approach had been as simple as it gets (for legacy reasons we're going to have the 2 scripts around anyway, so optimizing all that in a systemd-specific way is not yet in order unfortunately)
So in the boot image I had only

* created(replaced?) a symlink 
# ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 34 Feb 11 08:12 /etc/systemd/system/default.target -> /etc/systemd/system/pl_boot.target

* and added 2 files
==> /etc/systemd/system/pl_boot.service <==
[Unit]
Description=pl_boot service

[Service]
ExecStart=/etc/init.d/pl_boot
ExecStartPre=/etc/init.d/pl_sysinit
Type=oneshot


==> /etc/systemd/system/pl_boot.target <==
[Unit]
Description=pl_boot BootCD default target
Requires=pl_boot.service

----
This above turned out to work just fine in f16, and I was confident it would work the same in f18, but as a matter of fact it does not, and I'm trying to understand why

The output of a f16 box can be seen here
http://build.onelab.eu/lxc/2013.02.11--lxc16/testlogs/node.qemu.vnode12.pl.sophia.inria.fr.txt

OTOH with f18 we're getting this
http://build.onelab.eu/lxc/2013.02.10--lxc18/testlogs/node.qemu.vnode01.pl.sophia.inria.fr.txt
looks like systemd tries and runs pl_boot without running pl_sysinit first (which I would expect because of the ExecStartPre), so pl_boot gets stuck.


-----
Troubleshooting this is painful because the boot sequence gets suck in the middle and there's no way to enter the node; so the best I can do at this point is to extract the boot image somewhere, but once I chroot in there I essentially can use systemctl only for a very few commands, as others  fail with:
Failed to get D-Bus connection: No connection to service manager.


Regardless, here's what I was able to probe in the 2 images;

--------------- fedora16
[2013.02.11--lxc16] /etc/systemd/system # cat /etc/fedora-release 
Fedora release 16 (Verne)
[2013.02.11--lxc16] /etc/systemd/system # systemctl --version
systemd 37
fedora
+PAM +LIBWRAP +AUDIT +SELINUX +SYSVINIT +LIBCRYPTSETUP
[2013.02.11--lxc16] /etc/systemd/system # systemctl is-enabled pl_boot.service && echo OK
[2013.02.11--lxc16] /etc/systemd/system # 

--------------- fedora18
[2013.02.11--lxc18] /etc/systemd/system # cat /etc/fedora-release 
Fedora release 18 (Spherical Cow)
[2013.02.11--lxc18] /etc/systemd/system # systemctl --version
systemd 197
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
[2013.02.11--lxc18] /etc/systemd/system # systemctl is-enabled pl_boot.service && echo OK
static
OK

---------

Any insight as to what can be happening here would be most welcome 



More information about the systemd-devel mailing list