I will fix it in a bunch of hours. I will create a compat eselect-init that
deals with that case.
Same's here. I had to specify init=/usr/lib64/systemd/systemd though to
boot the system.
After my last upgrade today my systems fails to boot unless I instruct to
load init=/usr/lib/systemd/systemd directly from the command line.
To me it seems it is a symlink that went /dev/null here.
A snip.
Attached is an entropy.log snippet relative to yesterday.
I find interesting that:
$ ls -al /lib
lrwxrwxrwx 1 root root 5 12 ott 2011 lib - lib64
I mean, why did I need to specify lib64 if the symlink is in place?
2014-03-26 10:27 GMT+00:00 Fabio Erculiani lx...@sabayon.org:
I should have fixed the issue in the repositories. There are now new
systemd (from sabayon-distro instead of systemd-love overlay) and
systemd-sysv-utils (this one blocks eselect-init).
--
Fabio Erculiani
still no luck.
eselect-init was already removed by last update.
my grub menu entry has init=/linuxrc but the error message says it
cannot find valid init at /sbin/init
After equo install systemd-sysvinit-utils-208 I get:
# ls -al /sbin/init
lrwxrwxrwx 1 root root 24 26 mar 13.43 /sbin/init -
The fix was not supposed to solve the problem of already broken
systems. However, reinstalling systemd-sysv-utils should always bring
back a correct /sbin/init (which is a symlink). /usr/lib has always
been a symlink to lib64 (and /lib is a symlink to lib64).
On Wed, Mar 26, 2014 at 6:20 PM,
