You are not logged in.
Hi!
With latest systemd + filesystem, i was no more able to boot.
Systemd fails to start initrd-switch-root.service; downgrading (lib)systemd(-sysvcompat) only is not enough, I had to downgrade filesystem too, to be able to boot.
There is probably a problem with the /etc/os-release move (i guess). I tried symlinking /usr/lib/os-release to /etc-osrelease (*after i downgraded to systemd 214*, so i had only filesystem 2014.07) and it failed anyway.
And obviously emergency shell did not show up (don't ask me the reason why...) even if OnFailure says it calls emergency.target...
Last edited by nierro (2014-07-06 07:43:36)
Offline
Try regenerating your initramfs after upgrading, I have a feeling it's due to the systemd mkinitcpio hook interacting with the systemd/filesystem upgrade in some way (and running mkinitcpio -P from a bootable flash drive fixed the same issue for me).
Offline
Will wait for some developer/packager to confirm
I guess this thing should be echoed to the user after upgrading then!
Thanks by the way!
Offline
Yeah, I booted into the iso and then just manually symlinked /etc/os-release.
I have been following the [systemd-devel] and reading about all the changes necessary for the "factory reset" capabilities. So I figured it probably had something to do with moving things to /usr. So from the live media, I mounted all my partitions and then tried to boot it with systemd-nspawn. It told me it couldn't proceed because /etc/os-release was no present. So I symlinked that and then rebuilt the initramfs for good measure.
There is a tmpfiles.d snippet that should be able to symlink this for you automagically, but considering the machine can't get past teh switch_root, it makes sense that this is not created.
Has anyone filed an actual bug for this yet?
Offline
No, I have not seen a bug report about it.
Online
Thanks Wrangler. I'll get on that.
Edit: https://bugs.archlinux.org/task/41097
Last edited by WonderWoofy (2014-07-05 04:48:10)
Offline
@wonderwoofy: thanks!
I had no time yesterday to fill the bug report...and i was unsure if it was my configuration issue or a bug in the package.
EDIT: rebuilding initramfs with mkinitcpio did the trick for me as well!
Last edited by nierro (2014-07-05 07:55:39)
Offline
OK systemd 215-2 should fix this issue.
I'll consider this as solved.
Thanks everyone!
Offline
Just ran into this:
[2014-07-18 21:51] [PACMAN] upgraded systemd (214-2 -> 215-4)
[2014-07-18 21:52] [PACMAN] upgraded filesystem (2014.06-2 -> 2014.07-1)
However, I'm using a custom systemd setup to mount several partitions. I.e. root contains only /etc and some directory's like /lib /var etc etc. On top of those, the other filesystems are mounted.
EDIT: I'm not using [testing]. I fixed it by doing /sysroot/etc/os-release from a shell.
Last edited by Rexilion (2014-07-18 20:08:26)
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline
Hi!
This seems not be fixed for any non default kernel! At least a one successful boot with the default kernel (of Archlinux) is required or maybe the mentioned recreation of the mkinitcpip with a custom-kernel also fixes this. So in other words:
Everyone who doesn't use the Archlinux-Kernel needs to be instructed to rebuild the mkinitcpio for the custom kernel or a reboot with the kernel supplied by Archlinux.
// update
Probably this fix for systemd 215-2 trigger the creation "to late" i.e. not during the upgrade itself?
[2014-07-20 18:12] [PACMAN] upgraded systemd (214-2 -> 215-4) # the upgrade through pacman
...
lrwxrwxrwx 1 root root 21 Jul 20 18:36 /etc/os-release -> ../usr/lib/os-release # time of my first successfull reboot
Last edited by hoschi (2014-07-20 17:24:43)
Offline
I was not using a custom kernel on that machine. Only a systemd based init, that's all.
fs/super.c : "Self-destruct in 5 seconds. Have a nice day...\n",
Offline