Bug 725917

your statement is untrue

No.  After the upgrade /sbin/init pointed to systemd.

And it broke a formerly working system.

The split provides is in systemd-sysvinit so replacement of sysvinit by systemd on upgrade is expected behavior. Is it intentional so too? :-)

if systemd breaks something, file a bug report. But "Systemd should only be enabled with fresh installs" is INVALID.

If you're unhappy with the subject of the bug report modify it, please.  But do not close valid bug reports.

I don't close valid bug reports, I close INVALID ones.

This bug report already had a valid subject.  Please state next time why you believe this bug report is invalid and how the subject could be improved.

BTW your ignorant and arrogant habit doesn't motivate people to test and use openSUSE further.

Klaas, yours to fix obviously.

Reset bug summary.

and if people do not understand, this is not a bug but a feature. Like it or not is an other story...

Lars, did you replace the systemd-sysvinit package with sysvinit-init or just relinked the /sbin/init symlink?

(In reply to comment #10)
> and if people do not understand, this is not a bug but a feature. Like it or
> not is an other story...

It is a bug.

There are people using sysvinit for good reasons. Having installed many self
written init scripts for different kinds of things.
With such setup it's very likely that you will run into trubble if you just
switch to systemd without testing it.

Getting systemd without being noticed about it makes it even worse.

I'm sorry, I misunderstood the problem. After reading again carefully, I agree with comment #10. Unfortunately it's probably too late to do accept it even if there were good will (which I doubt).

(In reply to comment #13)
> I'm sorry, I misunderstood the problem. After reading again carefully, I agree
> with comment #10.

Reading between your lines I assume you agree with #12 instead of #10 right?

> Unfortunately it's probably too late to do accept it even if
> there were good will (which I doubt).

Coolo's "ignorant and arrogant" behavior (pointed out by himself, see Bug Activity) was not really helpful to speed up things ...

(In reply to comment #14)
> 
> Reading between your lines I assume you agree with #12 instead of #10 right?

Not really. I don't consider it a bug. IMHO it is a design decision. Certainly one which I personally do not like but I would prefer systemd not to be default even for clean install as I don't consider it reliable enough yet. But this decision has been taken and I have to live with it. As long as there is working SysVinit and an easy way to switch to it, I can do that.

As the development of openSUSE 12.1 finished all we can do is to document this as a known issue.  Please check http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1

systemd-sysvinit(In reply to comment #16)
> As the development of openSUSE 12.1 finished all we can do is to document this
> as a known issue.  Please check
> http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1

Does blacklisting systemd-sysvinit package _before_ zypper up also work?
If so then I would prefer to describe this as the safest way to never ever switch to systemd by mistake.

I consider blacklisting - zypper lock or from inside the YaST UI - an approach we should not recommend to our users.

I expect sysvinit to vanish completely in two or three releases as soon as the systemd stack settles more and more.

Guess we suggest to lock systemd-sysvinit.  In two years when the users upgrade their systems they no longer have the motivation to lock the package in mind.

Then libzypp will run into an unresolvable situation.  Therefore I strongly vote against suggesting a lock of the systemd-sysvinit package.

Adding some additional magic to libzypp to handle all this causes extra work too and would be yet another level of indirection causing at the end more and more hassle.

Over all the decision - as much as I don't like it - is the right approach.  We have to focus on one technical solution and make this solution a nicely and smooth working one.  That's what Frederic is working hard on.  It's nor our obligation to help him as much as possible to make systemd smoothly fly with the next release.

From recent discussions on the different openSUSE lists about systemd it looks like the systemd documentation is one major piece which needs our attention in the recent future.

@Ruediger + Klaas: Feel free to close this issue as resolved/worksforme if non of you doesn't have a more elegant solution at hand.

I reopen the report due to an unintentional status change to Status RESOLVED with Resolution FIXED.

How about making systemd-sysvinit and systemd-sysvinit(In reply to comment #18)
> I consider blacklisting - zypper lock or from inside the YaST UI - an approach
> we should not recommend to our users.

On the other hand installing something just to deinstall it is IMO an absolutely
inacceptable workflow which I wouldn't teach anybody.
I'd rather rsync the blacklist across my host pool to be safe.

Maybe there is another way without blacklisting?
What about
zypper in systemd-sysvinit
before
zypper up


> I expect sysvinit to vanish completely in two or three releases as soon as the
> systemd stack settles more and more.

Hope not.

> Over all the decision - as much as I don't like it - is the right approach.  We
> have to focus on one technical solution and make this solution a nicely and
> smooth working one.  That's what Frederic is working hard on.  It's nor our
> obligation to help him as much as possible to make systemd smoothly fly with
> the next release.

Personally I don't have any use case for systemd so I can't really help except
supporting bug reports where systemd breaks sysvinit.

(In reply to comment #18)
> I expect sysvinit to vanish completely in two or three releases as soon as the
> systemd stack settles more and more.
> 
> Guess we suggest to lock systemd-sysvinit.  In two years when the users upgrade
> their systems they no longer have the motivation to lock the package in mind.
> 
> Then libzypp will run into an unresolvable situation.  Therefore I strongly
> vote against suggesting a lock of the systemd-sysvinit package.

I don't see this as a problem. If this ever happens (and I still hope it won't), zypper will tell you it can't do the upgrade because of the lock, so you remove the lock. Or maybe if systemd wins some day and sysvinit is removed completely, there won't be a need for a package named systemd-sysvinit so that the lock won't be a problem at all.

Unfortunately nobody replied on comment#3

Closing this one with resolution wonfix is the wrong resolution.  Due to the documented fix in the wiki I set it to worksforme.

Nevertheless I appreciate an additional comment from Klaas too.

Sry (In reply to comment #22)
> Unfortunately nobody replied on comment#3

Yes, maybe switching from sysvinit to systemd by default was the intention of the packager thus he would expect that bahaviour of course. But others/users do not expect their system to be broken so it's a bug and certainly one of the most annoying ones.


> Closing this one with resolution wonfix is the wrong resolution.  Due to the
> documented fix in the wiki I set it to worksforme.

Sorry, closing the issue at all was my mistake. Haven't even noticed that I closed it.

I don't understand the hell here. I've upgraded 4 computers from 11.4 to 12.1 and no-one has trouble even with raid + lvm encryption and lot of stuff on them.

the question is : @Lars did you get also the sysvinit package installed.
if yes (and it should be) then booting with old initv is simple as adding 
init=/sbin/sysvinit on the boot line. 
End of trouble, and the easier way I known about having a computer booting with init v

if you not get it installed, then I think that Yast2 logs, and zypper dup history file would have help as attachement here.


I know that some init script could trouble systemd, but only if they do thing that are not in the normal action list. Then as a temporary fix, some wrapper need to be created. 

Living with factory daily, I know that things can be fixed, apache2 has not a native systemd service file, and the init.d script works now perfectly with systemd. So bug report, specific to each init script that doesn't work would help to get the best of systemd come in.

And yeap worksforme ... with or without systemd-sysinitv installed.
Next time, spend a bit more time testing when we hit the M2/3 stage.. Really!
;-)

It is bad, no very bad habit to force such a change with an upgrade.  That's what this report is all about.  It's all about the upgrade situation and not about new/ fresh installs.

Either you start the upgrade via booting from DVD/ CD or doing it with zypper nobody warns you what's happening to sysvinit.

The majority of our users will either miss the additional grub option or do not know how to handle additional kernel options.

I still hope the majority will not be hit by this issue.  That you didn't had any with four systems is good.  But from following the different lists we know there are more people annoyed by this change.

http://oss.sgi.com/pipermail/pcp/2011-November/002008.html is partial about how non openSUSE Open Source developers see the move to systemd.

In this case it was a fresh install and no upgrade.

(In reply to comment #4)
> if systemd breaks something, file a bug report. But "Systemd should only be
> enabled with fresh installs" is INVALID.

Upgrading from openSUSE 11.4 to openSUSE 12.1 breaks all existing LSB-compliant System V style init scripts. An example of the consequences of upgrading to 12.1:

# /etc/init.d/some-third-party-open-source-sysv-style-init-script start
redirecting to systemctl

but the service is not started. This breakage is caused by the changes in the aaa_base package (/etc/rc.status) for automatic redirection to systemd (and which can be disabled by setting the variable SYSTEMD_NO_WRAP). Is that information sufficient to reopen this bug or should I file this information in a new bug report ?

Please open a new bugreport (and add a short note with the bug number here).

Done - see also https://bugzilla.novell.com/show_bug.cgi?id=738281.

This bug is still present in 12.2. After zypper dup I've got systemd instead of sysvinit.

Which is perfectly fine as systemd is the default init of 12.2, so doing a "distribution upgrade" you get the new distribution.

If you don't want new defaults for zypper dup, it's your duty to lock the old or new packages - otherwise it's (again) perfectly fine for zypper dup to update to new defaults. *Otherwise* it would be a bug in zypper dup.

I'm not sure this is completely true. I seem to remember "zypper dup" from
12.1 to (pre-release) 12.2 keeping grub as bootloader while new installs
of 12.2 had grub2 as default.

Changing a default does not mean that you can change user's setup if he explicitly configured it. We are not talking about a fresh install but a system upgrade which should not break the system.

it's not breaking the system, it's updating to the new default. 

But if you want the bug, go ahead. I closed them as WONTFIX, if you reopen it's yours.

Nice attitude. This bug was one of the "most annoying bugs" in 12.1. Still not fixed in 12.2 and WONTFIX ever?

Your argumentation why it's ok and wanted to switch to systemd again and again is absolutely non-sense.
Would you also say it's fine to switch from exim to postfix again and again just because postfix is the default MTA since 10 years? Regardless the user has a working exim config but not a postfix one? Why providing exim packages at all?

You know that's stupid to assign this bug to me ... Jump over your own shadow and reopen it by yourself, assign it to somebody who could know why sysvinit will be removed rather than simply upgrading it to the new package name sysvinit-init.

(In reply to comment #36)
> Nice attitude. This bug was one of the "most annoying bugs" in 12.1. Still not
> fixed in 12.2 and WONTFIX ever?

You probably have seen in the 12.2 release notes that sysvinit is deprecated. In 12.3, systemd might be the only available init system (in other words: sysvinit might get removed - see the discussions on the opensuse-factory mailinglist)

I agree that this bug was valid for 12.1 and maybe also for 12.2, but for future versions it will most probably be a WONTFIX.

> Your argumentation why it's ok and wanted to switch to systemd again and again
> is absolutely non-sense.

Assuming the current factory development continues as planned, 12.3 will not contain sysvinit, so the only sane/possible option is to switch to systemd.

> Would you also say it's fine to switch from exim to postfix again and again
> just because postfix is the default MTA since 10 years? Regardless the user has
> a working exim config but not a postfix one? Why providing exim packages at
> all?

You are comparing apples with bananas ;-)
There's a big difference - the exim packages still exist and are maintained. sysvinit is not AFAIK - at least I didn't see anyone stepping up to maintain it in the future.

(In reply to comment #37)
> You are comparing apples with bananas ;-)
> There's a big difference - the exim packages still exist and are maintained.
> sysvinit is not AFAIK - at least I didn't see anyone stepping up to maintain it
> in the future.

I was considering it and I still am because for me, systemd is the worst
thing I have seen in ten years with SuSE distributions, comparable perhaps
only with zmd. But seeing both systemd upstream and its proponents in
OpenSuSE openly planning to make such task as difficult as possible e.g.
by intentionally modifying nonrelated packages in a way that makes them
unusable without systemd, really doesn't help. I understand that it is
their intention to avoid fair contest with other alternatives; What I
don't understand is why the people in charge favor such hostile project.
But this is for a discussion somewhere else - if there actually _was_
a discussion, that is; sadly it seems to have been decided long ago without
asking anyone.

(In reply to comment #37)
> (In reply to comment #36)

> > Would you also say it's fine to switch from exim to postfix again and again
> > just because postfix is the default MTA since 10 years? Regardless the user has
> > a working exim config but not a postfix one? Why providing exim packages at
> > all?
> 
> You are comparing apples with bananas ;-)

Yup he is: if you replace exim with postfix, mail stops working.

If you replace sysvinit with systemd *my entire system*, the thing I get paid to maintain and develop, may stop working.

Could we, maybe, get some professional system administrators on the release configuration team?

I'll tell you people the same thing I tell programming language maintainers:

Your baby?  It's *a tool I use to get work done*.  You rake me over the coals with it, and I'll find tool providers who don't.  It's bad enough we're dumping a perfectly serviceable 20 year old tool in favor of something better; doing it on an upgrade without any documentation is absolutely unacceptable, professionally.

And as for "no one's stepping up to maintain it", well, that's just cause it's not *officially* dropped yet.  KDE3 is 3 orders of magnitude more complex, and that only took a year or so to come back to life after the abortion that is KDE4.

Sometimes, y'know, better *really is* the enemy of good enough.

This won't change for 12.2 (and I'm clearly not the one who could do such a change) and 12.3 will not have sysvinit supported anyway.

closing as WONTFIX

feel free to reassign to libzypp maintainer otherwise.