So, the thing is this. We cannot drop sysvinit until we merge
sabayon-limbo to sabayonlinux.org, which is something that's going to
happen next Monday. However, if we don't do that entropy may try to
upgrade sysvinit to the latest version, which wipes again /sbin/init
(because it would remove syste
"reinstalling systemd-sysv-utils should always bring
back a correct /sbin/init (which is a symlink)."
That is how it got fixed on my end, so confirmed.
Hopefully somebody else can confirm this is fixed.
first --> equo upgrade pulled in systemd revision.
second is -> equo install systemd-sysv-uti
I have found another problem. Basically sysvinit is set to be updated in
spite of the fact that it should be dropped. Fixing it soon.
I don't remember if I purposely changed /usr/lib in the past or it was
set up that way during installation back in October 2011. I'm sure
enough I didn't explicitely installed anaconda though. Is it possible
to see when a package was first installed?
If not, I'd suggest to use equo query installed
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, pieri
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 ->
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
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 :
> Please post full l
Please post full log files, not just snippets. /sbin/init is now owned
by systemd-sysv-utils and is expected to be a symlink to
"../usr/lib/systemd/systemd".
Logs.
--
Fabio Erculiani
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. fr
I will fix it in a bunch of hours. I will create a compat eselect-init that
deals with that case.
*So I manually created the symlink
On Tue, Mar 25, 2014 at 10:43 PM, Joost Ruis wrote:
> @Fabio I noticed your commit here:
>
> https://github.com/Sabayon/sabayon-distro/commit/0d25ba5780aa6366fc1d559f6a99f6d8f8cf8113
>
> To see how it was on my end..
> sabayon / # ls -l /sbin/init
> ls: cann
@Fabio I noticed your commit here:
https://github.com/Sabayon/sabayon-distro/commit/0d25ba5780aa6366fc1d559f6a99f6d8f8cf8113
To see how it was on my end..
sabayon / # ls -l /sbin/init
ls: cannot access /sbin/init: No such file or directory
So I manually did:
sabayon / # ls -l /sbin/init
lrwxrwx
13 matches
Mail list logo
