systemd: Yet Another Init Replacement

eworm · 2011-04-18 09:12:19

For some days the boot delay is back, this time with another cause I think.

2011-04-18T10:54:36.963098+02:00 io kernel: [  197.885383] <28>systemd[1]: Job dev-bt-boot.device/start timed out.
2011-04-18T10:54:36.963100+02:00 io kernel: [  197.885452] <28>systemd[1]: Job dev-vg-home.device/start timed out.
2011-04-18T10:54:36.963102+02:00 io kernel: [  198.009575] <28>systemd[1]: Job dev-vg-swap.device/start timed out.

The volume group "bt" only contains my boot partition, the volume group "vg" contains home, swap and root. "vg" is located on a luks encrypted partition, "bt" is not. /boot and /home are not mounted after boot, swap is not activated. Any ideas?

eworm · 2011-04-19 14:42:17

eworm wrote:

For some days the boot delay is back, this time with another cause I think.
2011-04-18T10:54:36.963098+02:00 io kernel: [  197.885383] <28>systemd[1]: Job dev-bt-boot.device/start timed out.
2011-04-18T10:54:36.963100+02:00 io kernel: [  197.885452] <28>systemd[1]: Job dev-vg-home.device/start timed out.
2011-04-18T10:54:36.963102+02:00 io kernel: [  198.009575] <28>systemd[1]: Job dev-vg-swap.device/start timed out.
The volume group "bt" only contains my boot partition, the volume group "vg" contains home, swap and root. "vg" is located on a luks encrypted partition, "bt" is not. /boot and /home are not mounted after boot, swap is not activated. Any ideas?

Ok, I think I got a step forward. starting dev-*.device starts a process:

/bin/systemd-tty-ask-password-agent --watch

This seems to wait for input and times out after some time. I wonder why...

The luks encrypted device is already opened by the initrd. Why does systemd think it needs to open it again? Or what else does it ask for? How can I avoid this problem?

mar04 · 2011-04-19 23:45:50

simongmzlj wrote:

DIDI2002 wrote:
systemd doesn't shut my system down, e.g. 'halt', 'systemd shutdown' and 'systemd reboot' only return my to my VTs. On the other hand, 'systemctl isolate shutdown.target' works fine.
I can't really reproduce it, "sudo reboot" works sometimes, but sometimes I have to tap ctrl+alt+del to trigger a reboot.
Any idea what could be wrong?
+1 exact same issue.

Same here. Other than that it works great.

misc · 2011-04-20 00:12:34

Sweet: If I remove my USB HDD (1 btrfs partition) systemd will completely halt the boot process when it would be time to mount. init just gave a "mount point not available" warning (or something like that) and ignored it. However, booting does resume after the drive is connected. That'll get me into a pretty pickle if I don't take it everywhere with me, tough.

NB: The "native mount" option has no effect on this. My current fstab can be viewed here.

Last edited by misc (2011-04-20 00:24:21)

tvale · 2011-04-20 00:37:25

I just switched to systemd on both my desktop and laptop and everything works out of the box! Big thanks and keep up the good work!

falconindy · 2011-04-20 01:46:21

misc wrote:

Sweet: If I remove my USB HDD (1 btrfs partition) systemd will completely halt the boot process when it would be time to mount. init just gave a "mount point not available" warning (or something like that) and ignored it. However, booting does resume after the drive is connected. That'll get me into a pretty pickle if I don't take it everywhere with me, tough.
NB: The "native mount" option has no effect on this. My current fstab can be viewed here.

Not sure what you mean by 'native mount'. Add comment=systemd.automount to the USB drive and it should only be mounted on first access when the device is actually available.

misc · 2011-04-20 09:56:36

falconindy wrote:

Not sure what you mean by 'native mount'. Add comment=systemd.automount to the USB drive and it should only be mounted on first access when the device is actually available.

I mean the option as described in the wiki. Anyway, now the system indeed starts normally, thanks – but nothing can access the device when connected afterwards or the folder its mount point is in (/media). Apparently some system call does not respond and hence leaves the applications freezing.

eta: Same happens if the drive is connected from the beginning.

Last edited by misc (2011-04-20 10:23:14)

falconindy · 2011-04-20 10:15:14

SwapAuto and MountAuto are enabled by default.

misc · 2011-04-20 16:02:53

Lennart @ 0pointer.de informed me that unlike the Arch boot scripts systemd honors (here: requires) the "nofail" mount option. I've also left a note on the faulty comment=systemd.automount behavior.

eta: One of the reasons might be that according to htop mount options entirely different from those in fstab are used for the automount point, incl. one that is only valid for ntfs-3g.

Apparently one mustn't use an ordinary umount on these points or they'll break… does somebody know how one unmounts these systemd points then instead?

Last edited by misc (2011-04-20 21:15:00)

igndenok · 2011-04-20 16:13:14

hdhoang wrote:

@Evanlec, I wrote a pdnsd.service here <https://github.com/hdhoang/systemd-arch … sd.service>. Falconindy hasn't pulled it into the official repo yet, so s-a-u(-git) doesn't have it.

Can I request for named/named-chroot (BIND) units ?!
No trouble after install it~~, except for named (network unreachable) take some time before can browsing~~, and excellent work for maintaner

Edit: After looking closely it's error because I disabled ipv6 module, so there's no problem.

Last edited by igndenok (2011-04-20 16:29:50)

eworm · 2011-04-20 19:36:52

For anybody how has problems with block devices: udev-167-1 has its db in /run, but mkinitcpio from [core] does not handle /run at all... So udev looses its db which brings major breakage to systemd. However the fix is simple: Update to mkinitcpio-0.6.10-1 from [testing] and rebuild your initrd.

Everything working fine again. Thanks!

Last edited by eworm (2011-04-20 19:37:48)

Kn3cHt · 2011-04-21 08:25:53

fflarex wrote:

Fixed it. My passwords in /etc/crypttab were interpreted as paths to key files. I'm not sure if this is a bug or not, but it certainly doesn't support all the features of crypttab that Arch does. I also had to remove Arch-specific handling of encrypted swap.

What did you do? I have the opposit problem, my keyfiles are interpreted as passwords instead of keyfiles.

My entries look like this:

home            /dev/disk/by-uuid/58f8b264-6641-4115-9991-5a26322186a1 /etc/keys/home.key
media_hdd       /dev/disk/by-uuid/d79e6b63-e1ba-4201-83bf-f71cb6290d05 /etc/keys/media.key

falconindy · 2011-04-21 10:25:13

systemd's cryptsetup assumes the standard /etc/crypttab format (which arch does not use), and which does not specify a keyfile. From the source...

src/cryptsetup-generator.c

if ((k = sscanf(l, "%ms %ms %ms %ms", &name, &device, &password, &options)) < 2 || k > 4) {

...which means that name and device are required, password and options (comma separated) are optional. If we go look up what options are supported, src/cryptsetup.c tells us its:

noauto
cipher=
size=
hash=
tries=
readonly
verify
luks
plain
swap
tmp
timeout=

And then there's some options that debian furthere uses which systemd doesn't support:

offset=
skip=
precheck=
check=
checkargs=
noearly=
loud=
keyscript=

What this boils down to is:
1) keyfiles aren't (currently?) supported.
2) If you thought your password was being read as a keyfile, you were either mistaken or it wasn't systemd reading it.

Last edited by falconindy (2011-04-21 11:52:57)

lymphatik · 2011-04-21 12:08:32

eworm wrote:

For anybody how has problems with block devices: udev-167-1 has its db in /run, but mkinitcpio from [core] does not handle /run at all... So udev looses its db which brings major breakage to systemd. However the fix is simple: Update to mkinitcpio-0.6.10-1 from [testing] and rebuild your initrd.
Everything working fine again. Thanks!

I still get a unable to read superblock with systemd and mkinitcpio 0.6.11 and of course after a mkinitcpio -p kernel26. Anyway to fix this problem ?

eworm · 2011-04-21 12:17:11

lymphatik wrote:

I still get a unable to read superblock with systemd and mkinitcpio 0.6.11 and of course after a mkinitcpio -p kernel26. Anyway to fix this problem ?

Sounds like a broken partition layout to me... Is this related to systemd? Does your system boot as expected with SysV Init?

falconindy · 2011-04-21 12:29:05

Sounds more like a broken initcpio. If you don't even get to the point where your root is mounted, this is far from being tied to systemd.

lymphatik · 2011-04-21 12:40:42

Well I was able to boot with sysinit without issue. However after a ntfs repair done under windows everything is back to normal with systemd.

Sorry for the inconvenience. and great job on porting systemd to arch

fflarex · 2011-04-21 15:42:44

falconindy wrote:

If you thought your password was being read as a keyfile, you were either mistaken or it wasn't systemd reading it.

This doesn't seem right to me. What else would use crypttab other than init? I tried putting my passwords right in there; it just wouldn't work until I moved them to separate files.

falconindy · 2011-04-21 17:14:31

Hmmm, seems I've got it backwards. You can only set a filepath for a password. If you omit the password, you'll get prompted to enter your password instead by one of the various ask-password agents.

Last edited by falconindy (2011-04-21 17:14:51)

Kn3cHt · 2011-04-22 02:22:32

Somehow i am unable to get systemd working properly, it just does not accept my passwords (plain text in a file) or keyfiles (random files) it always tells me they are wrong.

ba · 2011-04-22 06:18:56

An issue with environment/daemon configuration files.

I'm not sure why this happens, but on my system I get a failure to start "dcron.service" using the dcron.service file from systemd-arch-units 20110411-1. The issue seems to be expansion of the ${CROND_ARGS} env variable.

Changing

EnvironmentFile=/etc/conf.d/crond
ExecStart=/usr/sbin/crond ${CROND_ARGS}

(which is what is supplied in the package)
to

ExecStart=/usr/sbin/crond -S -l info

makes the daemon start up fine.

The failure occurs after a completely unmodified install of the systemd-arch-units package. I've checked, double-checked and triple-checked that the /etc/conf.d/crond file does contain the correct variable. Just for reference it looks like this (also unmodified relative to the systemd-arch-units package):

#
# Parameters to be passed to crond
#
CROND_ARGS="-S -l info"

This seems pretty weird because according to the systemd.service(5) ExecStart documentation and the systemd.exec(5) EnvironmentFile this should work perfectly. However, in practise it fails because the ${CROND_ARGS} doesn't get expanded when systemd calls the dcron executable. (The command line according to systemctl status dcron.service was "/usr/sbin/crond ${CROND_ARGS}".)

This isn't a huge deal for me since I have the workaround, but maybe it needs reporting upstream?

dieghen89 · 2011-04-22 08:48:45

Hi guys! I'm testing systemd v25 but i have some problems...When i try to boot into kde with kdm.service, i get a consolekit error...So i've enabled the console-kit-daemon.service but when i try to start it, he says that dbus isn't loaded (dbus.socket)...

I can't find the dbus.service (as i googled), both in systemd and systemd-arch-units...How can i solve? Thanks!!

Wey · 2011-04-22 09:33:14

Hello dieghen,
find -name "dbus.service" tells me

./sys/fs/cgroup/cpu/system/dbus.service
./sys/fs/cgroup/systemd/system/dbus.service
./run/systemd/generator/arch-daemons.target.wants/dbus.service
./lib/systemd/system/multi-user.target.wants/dbus.service
./lib/systemd/system/dbus.service
./var/run/systemd/generator/arch-daemons.target.wants/dbus.service

And pacmans -Qo says, /lib/systemd/system/dbus.service is owned by dbus-core 1.4.1-1.

Though, dbus-core is listed as an depency for systemd, so this doesn't make much sense to me.
Did you install initscripts-systemd as well?

Hope i could help...

dieghen89 · 2011-04-22 10:01:38

Hi wey! ty for your fast reply

It's strange, i've already used find and locate but i can't find that file...But if I:

y -Ql dbus-core | grep dbus.service
dbus-core /lib/systemd/system/dbus.service
dbus-core /lib/systemd/system/multi-user.target.wants/dbus.service

-.-

So systemd if i give systemctl enable dbus.service, he doesn't find this file...Now i try to give the full path...

p.s. i don't use the systemd-initscripts, i'm using the init= in the grub cmdline...

EDIT: i've found the mistake...I don't know how, but the files in /lib/systemd the owned dbus-core wasn't present...After i reinstall the package all works fine

Last edited by dieghen89 (2011-04-22 10:16:45)

falconindy · 2011-04-22 10:21:36

dieghen89 wrote:

p.s. i don't use the systemd-initscripts, i'm using the init= in the grub cmdline...

These two things are entirely independent of each other. While initscripts-systemd isn't as crucial as it used to be, I'd still recommend you install it. Also, pacman -Ql only lists the contents of a package, with no regard for whether or not those files exist. Have you checked to make sure those files really exist? Regardless, something is funky -- without dbus, I'm surprised systemd even boots as far as you say it does.

ba wrote:

The issue seems to be expansion of the ${CROND_ARGS} env variable.

Indeed. You can change it to $CROND_ARGS instead. This is already fixed in git.

ba wrote:

maybe it needs reporting upstream?

That'd be me.

Arch Linux

#401 2011-04-18 09:12:19

Re: systemd: Yet Another Init Replacement

#402 2011-04-19 14:42:17

Re: systemd: Yet Another Init Replacement

#403 2011-04-19 23:45:50

Re: systemd: Yet Another Init Replacement

#404 2011-04-20 00:12:34

Re: systemd: Yet Another Init Replacement

#405 2011-04-20 00:37:25

Re: systemd: Yet Another Init Replacement

#406 2011-04-20 01:46:21

Re: systemd: Yet Another Init Replacement

#407 2011-04-20 09:56:36

Re: systemd: Yet Another Init Replacement

#408 2011-04-20 10:15:14

Re: systemd: Yet Another Init Replacement

#409 2011-04-20 16:02:53

Re: systemd: Yet Another Init Replacement

#410 2011-04-20 16:13:14

Re: systemd: Yet Another Init Replacement

#411 2011-04-20 19:36:52

Re: systemd: Yet Another Init Replacement

#412 2011-04-21 08:25:53

Re: systemd: Yet Another Init Replacement

#413 2011-04-21 10:25:13

Re: systemd: Yet Another Init Replacement

#414 2011-04-21 12:08:32

Re: systemd: Yet Another Init Replacement

#415 2011-04-21 12:17:11

Re: systemd: Yet Another Init Replacement

#416 2011-04-21 12:29:05

Re: systemd: Yet Another Init Replacement

#417 2011-04-21 12:40:42

Re: systemd: Yet Another Init Replacement

#418 2011-04-21 15:42:44

Re: systemd: Yet Another Init Replacement

#419 2011-04-21 17:14:31

Re: systemd: Yet Another Init Replacement

#420 2011-04-22 02:22:32

Re: systemd: Yet Another Init Replacement

#421 2011-04-22 06:18:56

Re: systemd: Yet Another Init Replacement

#422 2011-04-22 08:48:45

Re: systemd: Yet Another Init Replacement

#423 2011-04-22 09:33:14

Re: systemd: Yet Another Init Replacement

#424 2011-04-22 10:01:38

Re: systemd: Yet Another Init Replacement

#425 2011-04-22 10:21:36

Re: systemd: Yet Another Init Replacement

Board footer