Description of problem: systemd-26-1.fc15 only Obsoletes: upstart < 0.6.5-11 but the latest upstart in F14 updates is now upstart-1.2-2.fc14. Version-Release number of selected component (if applicable): systemd-26-1.fc15 How reproducible: Always Steps to Reproduce: 1. Try upgrading from F14 + updates to F15 + updates. Actual results: No migration to systemd because the Obsoletes do not trigger. Expected results: Successful migration to systemd. Additional info: This is going to be a PITA if the upstart maintainer keeps upgrading upstart in F14 while at the same time not wanting an unversioned Obsoletes because he wants to keep upstart as an alternative in F15.
Obsoletes: upstart < 1.2-2.fc15 Obsoletes: upstart-sysvinit < 1.2-2.fc15 should do the right thing there. (It's preferable to: Obsoletes: upstart <= 1.2-2.fc14 Obsoletes: upstart-sysvinit <= 1.2-2.fc14 because the < 1.2-2.fc15 method also allows for 1.2-2.fc14.1, 1.2-2.fc14.2 etc. bugfix builds for F14.) But this will have to be bumped each time upstart gets updated (except for .fc14.1 type bumps) in F14. (Ergo, upstart really should NOT get upgraded in F14, at least not without coordinating with systemd!)
That said, to fix the problem for those people who are upgrading right now, we really need to use: Obsoletes: upstart < 1.2-3 Obsoletes: upstart-sysvinit < 1.2-3 and then those people who really want to stick with upstart (Why are we supporting that at all???) will need an upstart-1.2-3.fc15 builds.
I've just tried it and it upgrade seems work also with upstart-1.2-2.fc14 # rpm -q --provides upstart config(upstart) = 1.2-2.fc14 upstart = 1.2-2.fc14 upstart(x86-64) = 1.2-2.fc14 # yum --releasever=15 distro-sync | tee log # grep systemd log --> Processing Dependency: systemd-sysv for package: cronie-1.4.7-3.fc15.x86_64 --> Processing Dependency: systemd-sysvinit for package: initscripts-9.30-2.fc15.x86_64 ---> Package systemd-units.x86_64 0:26-1.fc15 set to be updated ---> Package systemd.x86_64 0:26-1.fc15 set to be installed ---> Package systemd-sysv.x86_64 0:26-1.fc15 set to be installed systemd-units x86_64 26-1.fc15 fedora 130 k systemd x86_64 26-1.fc15 fedora 556 k systemd-sysv x86_64 26-1.fc15 fedora 12 k
But is Upstart getting removed? If not, does having both systemd and Upstart installed cause any problems?
It pulls in initscripts-legacy, which may a cause a little trouble like bug 704050.
This issue seems not to be related to upstart-1.2-2.fc14 update and also Obsoletes: upstart < 1.2-2.fc1{4,5} wouldn't help here since there is upstart-1.2-2.fc15 already in repositories. # rpm -q upstart upstart-0.6.5-9.fc14.x86_64 # yum --releasever=15 distro-sync ... systemd x86_64 26-1.fc15 fedora 556 k replacing upstart.x86_64 0.6.5-9.fc14 replacing upstart-sysvinit.x86_64 0.6.5-9.fc14 upstart x86_64 1.2-2.fc15 updates 168 8 k replacing upstart-sysvinit.x86_64 0.6.5-9.fc14 As for being #704050 I can remove upstart dependency on /etc/rc.sysinit in F15 for now and let users to install initscripts-legacy manually if they want to use upstart.
> upstart x86_64 1.2-2.fc15 updates 168 8 k > replacing upstart-sysvinit.x86_64 0.6.5-9.fc14 The problem here is that upstart also has an Obsoletes: upstart-sysvinit. If 2 packages both have an Obsoletes: some installed package, yum will pull them in both. You have to remove that Obsoletes from upstart. Then yum will only include: systemd x86_64 26-1.fc15 fedora 556 k replacing upstart.x86_64 0.6.5-9.fc14 replacing upstart-sysvinit.x86_64 0.6.5-9.fc14 in the transaction and remove upstart entirely (even if there's a newer version of upstart in the repository: Obsoletes takes precedence over regular upgrades).
In addition, the unversioned Obsoletes: upstart-sysvinit is also broken for those people who actually want to use Upstart, who won't be able to install that package. You must remove the Obsoletes: upstart-sysvinit from upstart. upstart-sysvinit must be obsoleted only by systemd.
In short, the proper way to fix the mess is: 1. build upstart-1.2-3.fc15 with the "Obsoletes: upstart-sysvinit" removed (entirely!), 2. build a new systemd with the Obsoletes bumped to: Obsoletes: upstart < 1.2-3 Obsoletes: upstart-sysvinit < 1.2-3 3. push the 2 as ONE GROUPED update in Bodhi, 4. get the update out to stable ASAP.
(In reply to comment #8) > In addition, the unversioned Obsoletes: upstart-sysvinit is also broken for > those people who actually want to use Upstart, who won't be able to install > that package. this is intended, upstart-sysvinit is not built since upstart-0.6.5-12.fc15 - bug 635323
OK, but still, the Obsoletes should be carried ONLY by the intended replacement (i.e. in this case systemd), not by two packages, because otherwise yum will drag in both.
By the way, I'd suggest dropping the %package sysvinit clutter from the specfile entirely if you aren't building it, unless you want to use the same specfile for F14, in which case you should be conditionalizing the differences with e.g. %if 0%{?fedora} > 14. (This is not a requirement, but it'd make the specfile more readable and it wouldn't have made me believe that -sysvinit was still being built.)
systemd-26-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/systemd-26-2.fc15
(In reply to comment #9) > In short, the proper way to fix the mess is: > 1. build upstart-1.2-3.fc15 with the "Obsoletes: upstart-sysvinit" removed > (entirely!), > 2. build a new systemd with the Obsoletes bumped to: > Obsoletes: upstart < 1.2-3 > Obsoletes: upstart-sysvinit < 1.2-3 > 3. push the 2 as ONE GROUPED update in Bodhi, > 4. get the update out to stable ASAP. To confuse matters more, 1.2-3 was built nearly two weeks ago[1] but only submitted as an update yesterday [2] so we probably want to s/3/4/ in the above versions. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=243790 [2] https://admin.fedoraproject.org/updates/upstart-1.2-3.fc15
this change will break reboot/shutdown after live upgrade with 'yum --releasever=15 distro-sync' if there is no /etc/rc.d/rc (part of initscripts-legacy) but upstart init is still running you can't change runlevel as there is no script to execute shutdown sequence
upstart-1.2-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/upstart-1.2-4.fc15
> To confuse matters more, 1.2-3 was built nearly two weeks ago[1] but only > submitted as an update yesterday [2] so we probably want to s/3/4/ in the above > versions. > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=243790 > [2] https://admin.fedoraproject.org/updates/upstart-1.2-3.fc15 I've unpushed upstart-1.2-3.fc15 from testing and replaced it with upstart-1.2-4.fc15 build
Package systemd-26-2.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-26-2.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/systemd-26-2.fc15 then log in and leave karma (feedback).
systemd-26-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #15) > this change will break reboot/shutdown after live upgrade with 'yum > --releasever=15 distro-sync' I'm confused -- what change are you referring to? Are you saying that with the release of these updates, it will no longer be possible to "reboot" following a live-upgrade from F14 to F15?
(In reply to comment #20) > I'm confused -- what change are you referring to? > > Are you saying that with the release of these updates, it will no longer be > possible to "reboot" following a live-upgrade from F14 to F15? It won't be possible to "just" reboot. You can temporary install upstart and remove it together with initscripts-legacy after reboot. Or run 'kill 1' which causes re-exec init but then systemd init will try to initialize system regardless of current system status - enabled swaps, running service, syslog, ....
Oh boy what a mess! I thought systemd and upstart were meant to coexist for a while and like many others I did a init=/sbin/upstart. Yum updated to systemd-26-2.fc15 that obsoleted upstart-1.2-2.fc15. Now I am left without init!
(In reply to comment #22) > Oh boy what a mess! > > I thought systemd and upstart were meant to coexist for a while and like many > others I did a init=/sbin/upstart. > > Yum updated to systemd-26-2.fc15 that obsoleted upstart-1.2-2.fc15. Now I am > left without init! fixed it with: yum install --enablerepo=updates-testing upstart Problem is that the latest systemd obsoletes upstart-1.2-2 while the updated upstart is not in stable repo yet.
upstart-1.2-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #21) > It won't be possible to "just" reboot. You can temporary install upstart and > remove it together with initscripts-legacy after reboot. Thanks, that sounds like the safer option. Couple of things I'm still unsure about: 1. If systemd and upstart are installed at the same time, do any special steps need to be taken to ensure systemd is used on the next boot and not upstart? 2. To reboot while in the "systemd installed but upstart running" state, the command to use is /lib/upstart/reboot, correct? I assume the systemd-provided /sbin/reboot only works with systemd running? It would really be helpful if some details on the rebooting issue could be added to the 14->15 section of the YumUpgradeFaq page (https://fedoraproject.org/wiki/YumUpgradeFaq). I would've never known to plan for it had I not stumbled across this Bugzilla entry purely out of curiousity.
> > 1. If systemd and upstart are installed at the same time, do any special steps > need to be taken to ensure systemd is used on the next boot and not upstart? > > 2. To reboot while in the "systemd installed but upstart running" state, the > command to use is /lib/upstart/reboot, correct? I assume the systemd-provided > /sbin/reboot only works with systemd running? > > > It would really be helpful if some details on the rebooting issue could be > added to the 14->15 section of the YumUpgradeFaq page > (https://fedoraproject.org/wiki/YumUpgradeFaq). I would've never known to plan > for it had I not stumbled across this Bugzilla entry purely out of curiousity. When I did a live upgrade about a week ago, both systemd and upstart were upgraded to fc15 version and everything worked fine. The fc15 kernel started systemd on reboot. Later I added kernel option "init=/sbin/upstart" and successfully switched back to upstart. It went wrong a week after the upgrade when the "fixed" systemd obsoleted my upstart and I was left without init. With "Obsoletes: upstart < 1.2-3" in systemd-26-2.fc15, the live upgrade will break again when upstart-1.2-2.fc14 gets updated.
> It would really be helpful if some details on the rebooting issue could be > added to the 14->15 section of the YumUpgradeFaq page > (https://fedoraproject.org/wiki/YumUpgradeFaq). I would've never known to plan > for it had I not stumbled across this Bugzilla entry purely out of curiousity. I'll admit that when I hit this yesterday, I just used the power button… Well, actually, I tried to issue a "reboot" first, it just failed with an error message, then I tried Ctrl+Alt+Del, which locked my keyboard and didn't otherwise do anything. At that point, I wasn't able to do anything other than turning the darn machine off. :-( So the most important hint would be: DO NOT USE Ctrl+Alt+Del if "reboot" fails, it will only mess up things. > When I did a live upgrade about a week ago, both systemd and upstart were > upgraded to fc15 version and everything worked fine. > The fc15 kernel started systemd on reboot. Later I added kernel option > "init=/sbin/upstart" and successfully switched back to upstart. Well, the thing is that you were expected to get migrated to systemd, not stick to upstart. Only people who deliberately install upstart on F15 (something I personally fail to see the use cases for) are supposed to get it, not people who just upgrade from F14.
"sync && reboot -f" should be safe enough.