You are not logged in.
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?
ArchLinux - make it simple & lightweight
Offline
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?
ArchLinux - make it simple & lightweight
Offline
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.
Offline
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)
Offline
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!
Offline
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.
Offline
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)
Offline
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)
Offline
@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)
Ask, and it shall be given you.
Seek, and ye shall find.
Knock, and it shall be opened unto you.
Offline
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)
ArchLinux - make it simple & lightweight
Offline
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
Offline
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)
Offline
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 ?
Offline
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?
ArchLinux - make it simple & lightweight
Offline
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
Offline
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.
Offline
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)
Offline
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.
Offline
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?
Offline
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!!
XPS 13 DE 2015 + K*5
"Machines are so stupid that if you tell them to do something perfect, they'll do it"
Offline
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...
Offline
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)
XPS 13 DE 2015 + K*5
"Machines are so stupid that if you tell them to do something perfect, they'll do it"
Offline
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.
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.
maybe it needs reporting upstream?
That'd be me.
Offline