Description of problem: did a yum distro-sync. my default init level was 3. after upgrade systemd had it set to runlevel 5 Version-Release number of selected component (if applicable): How reproducible: only did it once Steps to Reproduce: 1. start with fc14 2. yum distro-sync to 15 3. Actual results: watch Expected results: Additional info:
Did you have systemd-units installed before you did the distro-sync?
nope - this was a default f14 install with just fedora repos.
Interesting, the symlinks appear to confuse matters ... # ll /{etc,lib}/systemd/system/default.target lrwxrwxrwx. 1 root root 36 May 5 13:53 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target lrwxrwxrwx. 1 root root 16 May 5 14:47 /lib/systemd/system/default.target -> graphical.target I see this to when doing a *manual* upgrade (preupgrade didn't seem impacted by this issue). Looking at the %script from systemd-units, this should certainly work. And when I run this by hand, runlevel=5 on my F14->F15 upgraded system. # rpm -q --scripts systemd-units postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Try to read default runlevel from the old inittab if it exists runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null) if [ -z "$runlevel" ] ; then target="/lib/systemd/system/graphical.target" else target="/lib/systemd/system/runlevel$runlevel.target" fi # And symlink what we found to the new-style default.target /bin/ln -sf "$target" /etc/systemd/system/default.target > /dev/null 2>&1 || : Proposing as a release blocker since due to the Beta release criteria [1] ... "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria " The workaround is rather simple, but I'd like some additional feedback on the impact of this bug. I should note that I've upgraded using preupgrade and not encountered this issue. Perhaps there is something specific about the method of upgrade used? [1] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
Discussed in the 2011-05-06 blocker review meeting. Rejected as a blocker and NTH for the following reasons: upgrade via yum is not supported, this does not seem to affect the supported upgrade methods (DVD, preupgrade) and it can be fixed with a post-release update. If more testing shows this bug to affect upgrades done via DVD or preinstall, please re-propose as a blocker.
Sorry for the second comment, hit the return key too early and needed to get the metadata fields.
James or Mohammed - do you have the full upgrade log?
Theory #1: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Try to read default runlevel from the old inittab if it exists runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null) This reads /etc/inittab. Now, if you're on a pure F-15 systemd system, /etc/inittab has no initdefault line. So, if initscripts was updated first in your transaction, and /etc/inittab was replaced with the new version, this script would then fail, and would assume runlevel 3. However, this seems strange, because if you were in runlevel 5 before, then your /etc/inittab would have to have been modified, which means you would have only gotten the newer inittab file as /etc/inittab.rpmnew
bill - i can look for them if you tell me where they are
It would be 'upgrade.log' in /var/log/anaconda, or /root.
(In reply to comment #4) > Discussed in the 2011-05-06 blocker review meeting. Rejected as a blocker and > NTH for the following reasons: upgrade via yum is not supported, this does not > seem to affect the supported upgrade methods (DVD, preupgrade) and it can be > fixed with a post-release update. > > If more testing shows this bug to affect upgrades done via DVD or preinstall, > please re-propose as a blocker. Note, my testing encountered this using DVD and preupgrade methods. Not yum upgrade.
Removing the rejected keywords, since this issue occurs on DVD upgrades. I remember now that preupgrades are not impacted, but I just re-confirmed that DVD upgrades are impacted by this issue.
Created attachment 497915 [details] /root/upgrade.log
Re-proposing for blocker list based in updated information in comment#11
OK, so the upgrade log contains: Upgrading systemd-units-26-1.fc15.x86_64 Note that that says 'Upgrading', not 'Installing'. This means that systemd-units was already installed on the system in Fedora 14. This will happen if any of the following packages are in your Fedora 14 install set, from a dependency check: abrt-0:1.1.13-2.fc14.x86_64 and-units-0:1.2.2-9.fc14.noarch avahi-0:0.6.27-2.fc14.x86_64 dbus-1:1.4.0-1.fc14.x86_64 firstboot-0:1.113-4.fc14.x86_64 gpm-0:1.20.6-11.fc14.x86_64 hdapsd-0:20090401-6.fc14.x86_64 inadyn-mt-units-0:2.18.36-1.fc14.noarch rtkit-0:0.9-1.fc14.x86_64 system-setup-keyboard-0:0.8.6-2.fc14.1.x86_64 systemd-0:10-2.fc14.1.x86_64 udev-0:161-4.fc14.x86_64 So, we go back to the systemd-units package's %post script for Fedora 14, for when it was originally installed. rpm -qp --scripts systemd-units-10-2.fc14.1.x86_64.rpm ... postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Try to read default runlevel from the old inittab if it exists runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null) if [ -z "$runlevel" ] ; then target="/lib/systemd/system/graphical.target" else target="/lib/systemd/system/runlevel$runlevel.target" fi # And symlink what we found to the new-style default.target /bin/ln -sf "$target" /etc/systemd/system/default.target > /dev/null 2>&1 || : ... Now, if this was run during installation of Fedora 14, this scriptlet would happen during package install. At that time, one of the following would happen: - initscripts is not installed yet. runlevel would be blank. --> this means default.target will be linked to graphical.target - initscripts is installed yet. runlevel would be '3'. (anaconda, this point, has not written any customized runlevel.) --> this means default.target will be linked to runlevel3.target I suspect, if you look at your system, your /etc/systemd/system/default.target symlink dates to the *F-14* install, not the F-15 upgrade. This appears to be the case for James's install - Mohammed, is it the case for yours? If so, the only proper fix I can think of is a trigger (or similar) that re-does this on upgrades from Fedora 14. Changing the systemd %post to always run and set the default target will break anyone who uses a different target, including custom ones, on each systemd upgrade, which isn't nice.
While the fact that you can hit this doing an upgrade from DVD, I'm not sure this is a blocker. The closest thing I can see is what James mentioned earlier: "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" However, unless I'm misunderstanding something, the system would boot and function in this state (changing runlevel from 3 to 5). It certainly isn't what the user was expecting but it isn't catastrophic and the workaround is relatively simple. I can't really see holding up release for this as I understand it. -1 blocker, +1 NTH, +1 CommonBugs
My initial F14 installation resulted in a runlevel3 system. I had to manually change the configuration to boot into runlevel5. I'm going to retest my installation ensuring that my installation environment (and selections) install and prepare a @default package installation that boots into runlevel5 by default. I'm willing to be that scenario will be free of this problem, and is the more common installation choice for F14 users. If that holds, I agree with tflink's votes in comment#15. Stay tuned ...
Sorry, accidentally changed the component on this bug. Moving back to distribution.
Good news ... I just completed a graphical F14 install, then a graphical F15 upgrade. The upgraded system starts the graphical.target as expected. I think we know enough about this issue to safely document the workaround for anyone who installed F14 into a text (runlevel3) environment. For an install to configure runlevel5 (or graphical.target), you must [1] ... 1. install a package that provides 'service(graphical-login)' AND ... 2. install 'xorg-x11-server-Xorg' AND ... 3. do a graphical install AND ... 4. not do a VNC install If any of the above are not met, you get a runlevel3 installation. [1] http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=pyanaconda/packages.py;h=aa8dfc7d2107de174b84dc0569ddb0526c815b4b;hb=f15-branch#l277 -1 Blocker, +1 NTH, +1 CommonBugs We have 2 votes to RejectedBlocker this issue. Any other input?
yeah, i'm -1 too, easily workaroundable. it doesn't really hit the criteria either, as the criterion talks about a *default* installation, by which we mean 'graphical'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
three votes, adjusting status. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Given that systemd is new, many users who expect to get the GUI and end up with the command-line terminal might not know how to get their GUI back, or how to find out (without their web browser available). I just used preupgrade to go from F14 (which used runlevel 5 in inittab) to F15 Beta, which ended up at a terminal. I had to go to my second computer to find out how to set systemd to use "runlevel 5", and many users might not even know to google for systemd.
/etc/inittab has comprehensive comments explaining the situation, and systemd respects the old kernel parameters that most people use to control runlevels - just throwing a '3' or a '5' in there does what you'd expect. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thank you :)
say shouldn't /etc/inittab be updated to reflect systemd instead of upstart?
(In reply to comment #24) > say shouldn't /etc/inittab be updated to reflect systemd instead of upstart? It is ... just look at /etc/inittab on a Fedora 15 system (http://fpaste.org/duqe/)
jlaska: well, note that if you upgrade, the new one shows up as inittab.rpmnew ; I re-opened another bug for that one. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
jlaska, right mine doesnt have ithttp://fpaste.org/ROFZ/ nor do i have inittab.rpmnew
(In reply to comment #27) > jlaska, right mine doesnt have ithttp://fpaste.org/ROFZ/ nor do i have > inittab.rpmnew Looking at the fpaste you provided ... the content of that file clearly states that changes to that file are no longer honored. > ADDING OTHER CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM. Note, this bug is not fixed in Fedora 15, as it is only encountered in less common installation scenarios (see comment#16). The procedure to correct this issue is below: $ ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target $ ln -sf graphical.target /lib/systemd/system/default.target
James: no, he's right, that's the wrong inittab. That's the one that came with *upstart*, not the one that comes with systemd. Note that it says changes to the runlevel will be respected, whereas with systemd they are not. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #29) > James: no, he's right, that's the wrong inittab. That's the one that came with > *upstart*, not the one that comes with systemd. Note that it says changes to > the runlevel will be respected, whereas with systemd they are not. Right ... I didn't say it was wrong. My comment was was intended to answer the question posted in comment#24.
jlaska: well, it still doesn't really answer comment #24, because the file did indeed need updating for systemd: the upstart version says that *other* changes to the file will not be honored, but it does say that changes to the default runlevel will be honored. This isn't the case under systemd and changing the default runlevel is the only thing 99% of people ever used inittab for anyway, so in practice, for the most important feature of inittab, the upstart-era comment says exactly the wrong thing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #31) > jlaska: well, it still doesn't really answer comment #24, because the file did > indeed need updating for systemd: the upstart version says that *other* changes > to the file will not be honored, but it does say that changes to the default > runlevel will be honored. This isn't the case under systemd and changing the > default runlevel is the only thing 99% of people ever used inittab for anyway, > so in practice, for the most important feature of inittab, the upstart-era > comment says exactly the wrong thing. Hah! It certainly helps if we are talking about the same thing :) I was looking at the *wrong* fpaste link which showed a *good* upgraded /etc/inittab file. Apologies for the confusion. Also, I hijacked this bug for another similar (but reversed) issue. In my case ... * After anaconda upgrade from F14, the runlevel changes from 5 -> runlevel3.target That problem was diagnosed by notting in comment#14. The root-cause will require a manual work around and I plan to add this to the Common_F15_Bugs page. So, back to the reported problem by Mohammed ... * After distro-sync yum upgrade from F14, the runlevel changes from 3 -> graphical.target Mohammed, can you ... 1. attach /var/log/yum.log to this bug report 2. also, can you attach a list of all current packages installed on your system (rpm -qa > /tmp/rpms.txt) 3. Output from the following command: $ ls -l /{etc,lib}/systemd/system/default.target Thank you!
Created attachment 500148 [details] yum log for april 1* 2011 yum log for april 1* 2011
Created attachment 500149 [details] installed rpms installed rpms
wait a minute - this means that /etc/inittab is no longer used by systemd: ls -l /{etc,lib}/systemd/system/default.target lrwxrwxrwx. 1 root root 36 Apr 8 09:14 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target lrwxrwxrwx 1 root root 16 May 4 19:14 /lib/systemd/system/default.target -> graphical.target
yes. systemd should install a copy of inittab that explains this: it says that nothing you set in that file will do anything any more, and explains the new way to set default runlevels. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #35) > wait a minute - this means that /etc/inittab is no longer used by systemd: > > ls -l /{etc,lib}/systemd/system/default.target > lrwxrwxrwx. 1 root root 36 Apr 8 09:14 /etc/systemd/system/default.target -> > /lib/systemd/system/runlevel5.target > lrwxrwxrwx 1 root root 16 May 4 19:14 /lib/systemd/system/default.target -> > graphical.target Thanks! I think you're experiencing the same issue I reported in comment#18 (but in reverse). Do you have access to the file /var/log/anaconda/anaconda.log? If so, can you also attach that. I suspect that based on how your system was initially installed, the systemd-units package created default target symlinks (see comment#35). Those symlinks aren't used in Fedora 14, but were used when you upgraded to Fedora 15. This would account for your system going from a default runlevel3, to a default graphical.target.
I've documented this issue, and the workaround, as a CommonBug. Feel free to adjust/patch the wording as needed. https://fedoraproject.org/wiki/Common_F15_bugs#upgrade-runlevel
Re: ============================================================================ Note, this bug is not fixed in Fedora 15, as it is only encountered in less common installation scenarios (see comment#16). The procedure to correct this issue is below: $ ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target $ ln -sf graphical.target /lib/systemd/system/default.target =========================================================================== In which directory is the second link to be created ? Thanks !
Probably in the /lib/systemd/system directory as it clearly states?
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping