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.
Offline
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