Bug 698654 - fc14 to fc15 upgrade changes default init level
fc14 to fc15 upgrade changes default init level
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
15
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
RejectedBlocker AcceptedNTH https://f...
: CommonBugs
Depends On:
Blocks: F15-accepted/F15FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2011-04-21 09:29 EDT by Mohammed Arafa
Modified: 2014-03-16 23:27 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 13:29:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/root/upgrade.log (55.02 KB, text/plain)
2011-05-09 16:49 EDT, James Laska
no flags Details
yum log for april 1* 2011 (140.57 KB, text/plain)
2011-05-20 19:01 EDT, Mohammed Arafa
no flags Details
installed rpms (61.65 KB, text/plain)
2011-05-20 19:02 EDT, Mohammed Arafa
no flags Details

  None (edit)
Description Mohammed Arafa 2011-04-21 09:29:36 EDT
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:
Comment 1 Bill Nottingham 2011-04-25 14:42:14 EDT
Did you have systemd-units installed before you did the distro-sync?
Comment 2 Mohammed Arafa 2011-04-25 18:31:31 EDT
nope - this was a default f14 install with just fedora repos.
Comment 3 James Laska 2011-05-05 16:56:48 EDT
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
Comment 4 Tim Flink 2011-05-06 13:42:14 EDT
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.
Comment 5 Tim Flink 2011-05-06 13:45:00 EDT
Sorry for the second comment, hit the return key too early and needed to get the metadata fields.
Comment 6 Bill Nottingham 2011-05-06 14:05:41 EDT
James or Mohammed - do you have the full upgrade log?
Comment 7 Bill Nottingham 2011-05-06 15:53:14 EDT
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
Comment 8 Mohammed Arafa 2011-05-06 17:39:50 EDT
bill - i can look for them if you tell me where they are
Comment 9 Bill Nottingham 2011-05-09 10:44:51 EDT
It would be 'upgrade.log' in /var/log/anaconda, or /root.
Comment 10 James Laska 2011-05-09 13:42:47 EDT
(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.
Comment 11 James Laska 2011-05-09 16:48:21 EDT
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.
Comment 12 James Laska 2011-05-09 16:49:36 EDT
Created attachment 497915 [details]
/root/upgrade.log
Comment 13 James Laska 2011-05-09 17:01:05 EDT
Re-proposing for blocker list based in updated information in comment#11
Comment 14 Bill Nottingham 2011-05-09 17:07:00 EDT
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.
Comment 15 Tim Flink 2011-05-09 19:26:43 EDT
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
Comment 16 James Laska 2011-05-09 19:43:58 EDT
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 ...
Comment 17 James Laska 2011-05-09 20:38:46 EDT
Sorry, accidentally changed the component on this bug.  Moving back to distribution.
Comment 18 James Laska 2011-05-10 10:27:16 EDT
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?
Comment 19 Adam Williamson 2011-05-10 11:05:38 EDT
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
Comment 20 Adam Williamson 2011-05-10 11:10:40 EDT
three votes, adjusting status.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Richard Schwarting 2011-05-17 01:57:58 EDT
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.
Comment 22 Adam Williamson 2011-05-17 02:19:00 EDT
/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
Comment 23 Richard Schwarting 2011-05-17 02:43:22 EDT
Thank you :)
Comment 24 Mohammed Arafa 2011-05-18 19:36:10 EDT
say shouldn't /etc/inittab be updated to reflect systemd instead of upstart?
Comment 25 James Laska 2011-05-19 09:28:16 EDT
(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/)
Comment 26 Adam Williamson 2011-05-19 11:58:06 EDT
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
Comment 27 Mohammed Arafa 2011-05-19 18:17:34 EDT
jlaska, right mine doesnt have ithttp://fpaste.org/ROFZ/  nor do i have inittab.rpmnew
Comment 28 James Laska 2011-05-20 11:24:24 EDT
(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
Comment 29 Adam Williamson 2011-05-20 11:59:31 EDT
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
Comment 30 James Laska 2011-05-20 12:34:54 EDT
(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.
Comment 31 Adam Williamson 2011-05-20 12:48:30 EDT
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
Comment 32 James Laska 2011-05-20 13:09:19 EDT
(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!
Comment 33 Mohammed Arafa 2011-05-20 19:01:21 EDT
Created attachment 500148 [details]
yum log for april 1* 2011

yum log for april 1* 2011
Comment 34 Mohammed Arafa 2011-05-20 19:02:09 EDT
Created attachment 500149 [details]
installed rpms

installed rpms
Comment 35 Mohammed Arafa 2011-05-20 19:03:07 EDT
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
Comment 36 Adam Williamson 2011-05-20 21:03:55 EDT
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
Comment 37 James Laska 2011-05-24 08:10:32 EDT
(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.
Comment 38 James Laska 2011-05-24 09:21:41 EDT
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
Comment 39 Linuxguy123 2011-08-24 14:57:10 EDT
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 !
Comment 40 David Woodhouse 2011-08-24 16:25:53 EDT
Probably in the /lib/systemd/system directory as it clearly states?
Comment 41 Fedora End Of Life 2012-08-07 13:29:28 EDT
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

Note You need to log in before you can comment on or make changes to this bug.