LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Fedora (http://www.linuxquestions.org/questions/fedora-35/)
-   -   Attempting to upgrade FC17 to FC19 using fedup (http://www.linuxquestions.org/questions/fedora-35/attempting-to-upgrade-fc17-to-fc19-using-fedup-4175478109/)

kaza 09-22-2013 02:17 PM

Attempting to upgrade FC17 to FC19 using fedup
 
Hello,

I'm attempting to upgrade my FC17 (KDE) system to FC19 using fedup.
I'm aware of the potential for problems but since I already did
two backups to tapes, downloaded FC19 DVD install ISO file
and burned it onto a DVD I decided, if I'm going to wipe averything,
why not to try fedup first?

I installed fedup, run "yum update", run as root
"fedup-cli --network 19", the
long process ended without errors in the
/var/log/fedup.log file.

I rebooted, selected from the grub menu the "System
upgrade", waited until the upgrade process ends ("Target
ready for shutdown", I guess it's the end because nothing
changed after that stage. During the long upgrade process
there was a "hotdog" screen saver, I hope I didn't ruin
anything by pressing the up/down/space/enter keys
to return to the textual progress screen).

After rebooting and selecting FC19 grub menu, instead
of the KDE login prompt I've got a console login.
After login I attempted "startkde" and got an error message

Code:

$DISPLAY not set or can't xonnect to x server
and that's where I'm now.
Except the "install from scratch, wipe and re-create
all the partitions, then restore /home from tapes", is there
a simplier solution? Did I missed something simple
that can be solved by editing some file?

I didn't perform the grub reinstall since I already have
grub2, should I've done it?

Any ideas welcomed, including "I told you so..." :-)

TIA,

business_kid 09-23-2013 12:05 PM

If you really have that
Quote:

not set or can't xonnect to x server
google it as someone has a typo in the code, and that leads you very specifically. If it's your typo, ignore that.

I would look around, checking config files (fstab, hosts, etc) and check that the lo interface is up to give you loopback networking.

kaza 09-23-2013 12:32 PM

Quote:

Originally Posted by business_kid (Post 5033258)
If you really have that google it as someone has a typo in the code, and that leads you very specifically. If it's your typo, ignore that.

I would look around, checking config files (fstab, hosts, etc) and check that the lo interface is up to give you loopback networking.

It was my typo, of corse, if was "can't connect".

What exactly should I look for in the config files?

TIA,
kaza.

business_kid 09-23-2013 04:02 PM

to see if you have loopback: ping -c3 127.0.0.1
Have you a video driver loaded?

Generally look for .new or .rpmnew(rpmsave?) files in /etc. You had config files but the packages installed new ones. You don't really know which ones are in place

ls /etc/fstab* finds all fstab versions.

kaza 09-25-2013 11:24 PM

Hi, business_kid,

I did the "ping -c3 127.0.0.1" and it snt/received OK.
As I understand, port 127.0.0.1 is a local host, right?
Does that means the $DISPLAY env. var should
have the value of 127.0.0.1?

There were no /etc/.new or /etc/.rpm* files, what can I deduce
from their absense?
The ls /etc/fstab* didn't show anything new, only my /etc/fstab
file I used with FC17 and few copies of it I created
during the years. Should've the FC19 update process create
a new /etc/fstab?

Doing "df" I saw a new mount point "/run" of the filesystem "tmpfs"
using 980K, is that a leftover of the FC19 update process?
There were no errors in log after the "fedup-cli --network 19"
but I don't know if the post-reboot upgrade process had any
errors. Is there another logfile of that upgrade process
to look into? The directory /run/log is empty and actually
only now I noticed that everything in it has a timestamp
of this morning when I turned the non-functioning PC ON
(I'm posting from another laptop).

How can I check if the video driver is loaded?

TIA,
kaza.

kaza 09-26-2013 12:46 AM

OK, after some googling I looked into the file

/var/log/Xorg.0.log

In it I saw lines of detection of my FireGL V5600 video card
and appropriate drivers installing and modes setting.
The last line of the file is:

Server terminated successfully (0). Closing log file.

So it looks like the display divers are installed OK.

What else can be the reason for booting into a console
instead of starting the KDE?

TIA,
kaza.

kaza 09-26-2013 10:25 AM

OK, partial success:

After starting reading the "Fedora boot sequence" it occured
to me to try "startx" from the console prompt my PC booted with
and my familiar KDE desktop came up almost 100% as it was
(icons of few launchers were replaced by question marks
and the output of "top" doesn't fit into its dedicated
window, maybe I need to play with switches).

So now I know my FC19 system is capable of running KDE,
the remaining question is: in what configuration file
should be the instruction to start KDE?

TIA,
kaza.

business_kid 09-26-2013 01:35 PM

Thatś a $64,000 question. Red Hat is so convoluted in the way it startx X (and Mandrake of old copied it) that when I pestered them for a choice of WM, they wrote a new python script xstart.

Try xinitrc, often (but not always in
/etc/X11/xinit/xinitrc

Thereś also an xinitrc.d lying about there somewhere. Slackware spoil us with an xinitrc for each WM (xinitrc.xfce, xinitrc.kde, etc) and xinitrc is a symlink :-).

kaza 09-27-2013 09:59 AM

Hi, business_kid,

I looked into /etc/X11/xinit/xinitrc:

Code:

#!/bin/sh
# Copyright (C) 1999 - 2005 Red Hat, Inc. All rights reserved. This
# copyrighted material is made available to anyone wishing to use, modify,
# copy, or redistribute it subject to the terms and conditions of the
# GNU General Public License version 2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
# Authors:
#        Mike A. Harris <mharris@redhat.com>

# Mandatorily source xinitrc-common, which is common code shared between the
# Xsession and xinitrc scripts which has been factored out to avoid duplication
. /etc/X11/xinit/xinitrc-common

# The user may have their own clients they want to run.  If they don't,
# fall back to system defaults.
if [ -f $HOME/.Xclients ]; then
    exec $CK_XINIT_SESSION $SSH_AGENT $HOME/.Xclients || \
    exec $CK_XINIT_SESSION $SSH_AGENT $HOME/.Xclients
elif [ -f /etc/X11/xinit/Xclients ]; then
    exec $CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients || \
    exec $CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients
else
    # Failsafe settings.  Although we should never get here
    # (we provide fallbacks in Xclients as well) it can't hurt.
    [ -x /usr/bin/xsetroot ] && /usr/bin/xsetroot -solid '#222E45'
    [ -x /usr/bin/xclock ] && /usr/bin/xclock -geometry 100x100-5+5 &
    [ -x /usr/bin/xterm ] && xterm -geometry 80x50-50+150 &
    [ -x /usr/bin/twm ] && /usr/bin/twm
fi

Since I don't have

$HOME/.Xclients

but have

/etc/X11/xinit/Xclients

it looks like that's what is getting executed.
(The env. vars seems to be set in /etc/X11/xinit/xinitrc-common).
BTW, why the command

exec $CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients

is repeated twice? Is it expected to return zero value on the
first run?

The file /etc/X11/xinit/Xclients contents are:

Code:

#!/bin/bash
# Copyright (C) 1999 - 2004 Red Hat, Inc. All rights reserved. This
# copyrighted material is made available to anyone wishing to use, modify,
# copy, or redistribute it subject to the terms and conditions of the
# GNU General Public License version 2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

GSESSION="$(type -p gnome-session)"
STARTKDE="$(type -p startkde)"

# check to see if the user has a preferred desktop
PREFERRED=
if [ -f /etc/sysconfig/desktop ]; then
    . /etc/sysconfig/desktop
    if [ "$DESKTOP" = "GNOME" ]; then
        PREFERRED="$GSESSION"
    elif [ "$DESKTOP" = "KDE" ]; then
        PREFERRED="$STARTKDE"
    fi
fi

if [ -n "$PREFERRED" ]; then
    exec "$PREFERRED"
fi

# now if we can reach here, either no desktop file was present,
# or the desktop requested is not installed.

if [ -n "$GSESSION" ]; then
    # by default, we run GNOME.
    exec "$GSESSION"
elif [ -n "$STARTKDE" ]; then
    # if GNOME isn't installed, try KDE.
    exec "$STARTKDE"
fi

# We should also support /etc/X11/xinit/Xclients.d scripts
XCLIENTS_D=/etc/X11/xinit/Xclients.d
if [ "$#" -eq 1 ] && [ -x "$XCLIENTS_D/Xclients.$1.sh" ]; then
    exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"
fi

# Failsafe.

# these files are left sitting around by TheNextLevel.
rm -f $HOME/Xrootenv.0

# Argh! Nothing good is installed. Fall back to twm
{
    # gosh, neither fvwm95 nor fvwm2 is available;
    # fall back to failsafe settings
    [ -x /usr/bin/xsetroot ] && /usr/bin/xsetroot -solid '#222E45'

    if [ -x /usr/bin/xclock ] ; then
        /usr/bin/xclock -geometry 100x100-5+5 &
    fi
    if [ -x /usr/bin/xterm ] ; then
        /usr/bin/xterm -geometry 80x50-50+150 &
    fi
    if [ -x /usr/bin/firefox -a -f /usr/share/doc/HTML/index.html ]; then
        /usr/bin/firefox /usr/share/doc/HTML/index.html &
    fi
    if [ -x /usr/bin/twm ] ; then
        exec /usr/bin/twm
    fi
}

The contents of /etc/sysconfig/desktop are:

[codde]
DESKTOP="KDE"
DISPLAYMANAGER="KDM"
[/code]

So it seems the KDE is the preferred environment but still, why it's not executed?

I also looked at the /etc/X11/xinit

Code:

<root localhost>.../>ls /etc/X11/xinit
total 32
-rwxr-xr-x. 1 root root 2030 Feb 19  2013 Xclients
drwxr-xr-x. 2 root root 4096 Feb 19  2013 Xclients.d
-rwxr-xr-x. 1 root root 1486 Feb 19  2013 xinitrc
-rw-r--r--. 1 root root 2008 Feb 19  2013 xinitrc-common
drwxr-xr-x. 2 root root 4096 Sep 22 07:23 xinitrc.d
drwxr-xr-x. 2 root root 4096 Sep 22 07:30 xinput.d
-rw-r--r--. 1 root root  354 Jul 26 18:49 xinputrc
-rwxr-xr-x. 1 root root 3547 Feb 19  2013 Xsession

Sep 22 is when I run "fedup", I think.

Code:

<root localhost>.../>ls /etc/X11/xinit/xinitrc.d
total 16
-rwxr-xr-x. 1 root root  558 Jun 18 01:23 00-start-message-bus.sh
-rwxr-xr-x. 1 root root 3969 Jun 11 08:47 50-xinput.sh
-rwxr-xr-x. 1 root root  543 Feb 19  2013 localuser.sh
-rwxr-xr-x. 1 root root  537 Jun 27 23:39 xdg-user-dirs.sh

Contents of /etc/X11/xinit/Xsession

Code:

#!/bin/bash
# Copyright (C) 1999 - 2004 Red Hat, Inc. All rights reserved. This
# copyrighted material is made available to anyone wishing to use, modify,
# copy, or redistribute it subject to the terms and conditions of the
# GNU General Public License version 2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

# redirect errors to a file in user's home directory if we can
if [ -z "$GDMSESSION" ]; then
    # GDM redirect output itself in a smarter fashion
    errfile="$HOME/.xsession-errors"
    if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null ); then
        chmod 600 "$errfile"
        [ -x /sbin/restorecon ] && /sbin/restorecon $errfile
        exec > "$errfile" 2>&1
    else
        errfile=$(mktemp -q /tmp/xses-$USER.XXXXXX)
        if [ $? -eq 0 ]; then
            exec > "$errfile" 2>&1
        fi
    fi
fi

SWITCHDESKPATH=/usr/share/switchdesk

# Mandatorily source xinitrc-common, which is common code shared between the
# Xsession and xinitrc scripts which has been factored out to avoid duplication
. /etc/X11/xinit/xinitrc-common

# This Xsession.d implementation, is intended to obsolte and replace the
# various mechanisms present in the 'case' statement which follows, and to
# eventually be able to easily remove all hard coded window manager specific
# content from this script.  See bug #142260 for additional explanation and
# details.  All window manager rpm packages and desktop environment
# packages should be modified to provide the Xsession.d/Xsession.$wm scripts
# to start themselves up.  In the future, the legacy switchdesk mechanisms
# and hard coded window managers and desktop environments will be removed from
# this script.
XCLIENTS_D=/etc/X11/xinit/Xclients.d
if [ "$#" -eq 1 ] && [ -x "$XCLIENTS_D/Xclients.$1.sh" ]; then
    exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"
else
# now, we see if xdm/gdm/kdm has asked for a specific environment
case $# in
1)
    if [ -x "$SWITCHDESKPATH/Xclients.$1" ]; then
      exec -l $SHELL -c "$SWITCHDESKPATH/Xclients.$1";
    fi;

    case "$1" in
        failsafe)
            exec -l $SHELL -c "xterm -geometry 80x24-0-0"
            ;;
        gnome|gnome-session)
            # lack of SSH_AGENT is intentional, see #441123.  though
            # the whole thing should really happen in xinitrc.d anyway.
            exec -l $SHELL -c gnome-session
            exec /bin/sh -c "exec -l $SHELL -c \"gnome-session\""
            ;;
        kde|kde1|kde2)
            exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"startkde\""
            ;;
        twm)
        # fall back to twm
            exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"twm\""
            ;;
        *)
      # GDM provies either a command line as the first argument or
      # provides 'failsafe', 'default' or 'custom'.  KDM will do the
      # same at some point
            if [ "$1" != "default" -a "$1" != "custom" ]; then
                exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"$1\""
            fi
            ;;
    esac
esac
fi

# otherwise, take default action
if [ -x "$HOME/.xsession" ]; then
    exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT $HOME/.xsession"
elif [ -x "$HOME/.Xclients" ]; then
    exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT $HOME/.Xclients"
elif [ -x /etc/X11/xinit/Xclients ]; then
    exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT /etc/X11/xinit/Xclients"
else
    # should never get here; failsafe fallback
    exec -l $SHELL -c "xsm"
fi

Indeed, convoluted... :-(


TIA,

business_kid 09-27-2013 10:08 AM

Hi. My Fedora system seems a bit different. Iḿ not really able to chase this around with you. You will find one script references another, and another, and they reference another 4 each :-/. Just after this bit
Code:

# Mandatorily source xinitrc-common, which is common code shared between the
# Xsession and xinitrc scripts which has been factored out to avoid duplication
. /etc/X11/xinit/xinitrc-common

you could stick something like

exec /usr/bin/startkde

and comment out the rest. It would probably run. But I would back up the unhacked version. Otherwise, enjoy grokking their scripts :-P.

PTrenholme 09-27-2013 11:48 AM

Check your systemd settings. You should see something like this: (Note the lines in red highlight, especially the last two.)
Code:

$ locate systemd | grep multi-user
/etc/systemd/system/multi-user.target.wants
/etc/systemd/system/multi-user.target.wants/NetworkManager.service
/etc/systemd/system/multi-user.target.wants/abrt-ccpp.service
/etc/systemd/system/multi-user.target.wants/abrt-oops.service
/etc/systemd/system/multi-user.target.wants/abrt-vmcore.service
/etc/systemd/system/multi-user.target.wants/abrt-xorg.service
/etc/systemd/system/multi-user.target.wants/abrtd.service
/etc/systemd/system/multi-user.target.wants/acpid.service
/etc/systemd/system/multi-user.target.wants/arp-ethers.service
/etc/systemd/system/multi-user.target.wants/atd.service
/etc/systemd/system/multi-user.target.wants/auditd.service
/etc/systemd/system/multi-user.target.wants/avahi-daemon.service
/etc/systemd/system/multi-user.target.wants/chronyd.service
/etc/systemd/system/multi-user.target.wants/crond.service
/etc/systemd/system/multi-user.target.wants/cups.path
/etc/systemd/system/multi-user.target.wants/gpm.service
/etc/systemd/system/multi-user.target.wants/irqbalance.service
/etc/systemd/system/multi-user.target.wants/ksm.service
/etc/systemd/system/multi-user.target.wants/ksmtuned.service
/etc/systemd/system/multi-user.target.wants/libvirtd.service
/etc/systemd/system/multi-user.target.wants/lm_sensors.service
/etc/systemd/system/multi-user.target.wants/mcelog.service
/etc/systemd/system/multi-user.target.wants/mdmonitor.service
/etc/systemd/system/multi-user.target.wants/nfs-idmap.service
/etc/systemd/system/multi-user.target.wants/rc-local.service
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/etc/systemd/system/multi-user.target.wants/rpcbind.service
/etc/systemd/system/multi-user.target.wants/rsyslog.service
/etc/systemd/system/multi-user.target.wants/sendmail.service
/etc/systemd/system/multi-user.target.wants/sm-client.service
/etc/systemd/system/multi-user.target.wants/smartd.service
/etc/systemd/system/multi-user.target.wants/sshd.service
/etc/systemd/system/multi-user.target.wants/xinetd.service
/usr/lib/systemd/system/multi-user.target
/usr/lib/systemd/system/multi-user.target.wants
/usr/lib/systemd/system/multi-user.target.wants/dbus.service
/usr/lib/systemd/system/multi-user.target.wants/getty.target
/usr/lib/systemd/system/multi-user.target.wants/plymouth-quit-wait.service
/usr/lib/systemd/system/multi-user.target.wants/plymouth-quit.service
/usr/lib/systemd/system/multi-user.target.wants/systemd-ask-password-wall.path
/usr/lib/systemd/system/multi-user.target.wants/systemd-logind.service
/usr/lib/systemd/system/multi-user.target.wants/systemd-user-sessions.service

<edit 1>
You might also try running dracut to regenerate your initial RAM file system. From the running X session.
</edit>

<edit 2>
I just ran fedup to update from F-19 to F-20, and, when the screen with the "f" and bar was displayed, I didn't touch it. (Read a book: Modesitt's "Imager's Intrigue" :)) After an hour or so, the system was "automagicaly" rebooted, with the new system as the first menu choice.

Perhaps you boo-booed interrupting that screen.:scratch:
</edit>

kaza 09-27-2013 10:51 PM

Hi PTrenholme,

I checked my systemd settings and I saw that I don't have the file

/etc/systemd/system/multi-user.target.wants/xinetd.service

while I have the files

Code:

<root localhost>.../>ls /usr/lib/systemd/system/multi-user.target.wants
total 28
-rw-r--r--. 1 root root 345 Jun 18 01:23 dbus.service
-rw-r--r--. 1 root root 460 Sep 18 19:59 getty.target
-rw-r--r--. 1 root root 235 Mar 26  2013 plymouth-quit.service
-rw-r--r--. 1 root root 244 Mar 26  2013 plymouth-quit-wait.service
-rw-r--r--. 1 root root 574 Sep 18 19:59 systemd-ask-password-wall.path
-rw-r--r--. 1 root root 860 Sep 18 19:59 systemd-logind.service
-rw-r--r--. 1 root root 558 Sep 18 19:59 systemd-user-sessions.service

I also saw that the directory /etc/xinetd.d had been created
(with the timestamp of approximately when I've run "fedup") but it's empty.


What can I deduce from it (if anything)?
If it shouldv'e been created (and filled), is there a way
to re-create it?

During the long fedup run (or at the "upgrade" stage after the reboot)
I saw a "hotdog" image which looked like a screensaver - when I pressed
a <space> or <Enter> it disappeared and the lines of actions performed
were shown. Can it be that pressing some key during this process
messed up something?

TIA,

PTrenholme 09-28-2013 12:25 PM

Well, you somehow failed to get your Internet services properly set up :scratch: but, my bad :redface:, that doesn't explain why the login service was not started.

Do you have an /etc/systemd/system/display-manager.conf file?
Code:

$ cat /etc/systemd/system/display-manager.service
[Unit]
Description=The KDE login manager
Conflicts=getty@tty1.service
After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service
Conflicts=plymouth-quit.service

[Service]
ExecStart=/usr/bin/kdm vt1
Restart=always
IgnoreSIGPIPE=no

[Install]
Alias=display-manager.service

For what it's worth, here's what I have on this system for the Internet services (See man xinetd):
Code:

$ ls /etc/xinetd.d/
chargen-dgram  daytime-dgram  discard-dgram  echo-dgram  tcpmux-server  time-stream
chargen-stream  daytime-stream  discard-stream  echo-stream  time-dgram

$ sudo cat /etc/xinetd.conf
#
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.

defaults
{
# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#
#      enabled        =
#      disabled        =

# Define general logging characteristics.
        log_type        = SYSLOG daemon info
        log_on_failure  = HOST
        log_on_success  = PID HOST DURATION EXIT

# Define access restriction defaults
#
#      no_access      =
#      only_from      =
#      max_load        = 0
        cps            = 50 10
        instances      = 50
        per_source      = 10

# Address and networking defaults
#
#      bind            =
#      mdns            = yes
        v6only          = no

# setup environmental attributes
#
#      passenv        =
        groups          = yes
        umask          = 002

# Generally, banners are not used. This sets up their global defaults
#
#      banner          =
#      banner_fail    =
#      banner_success  =
}

includedir /etc/xinetd.d


kaza 09-28-2013 03:37 PM

Hi PTrenholme,

I don't have the display-manager.conf file:

Code:

<root localhost.localdomain>.../root>ls  /etc/systemd/system/display-manager.conf
ls: cannot access /etc/systemd/system/display-manager.conf: No such file or directory

<root localhost.localdomain>.../root>\ls -l /etc/systemd/system
total 40
drwxr-xr-x. 2 root root 4096 Jun  6  2012 basic.target.wants
drwxr-xr-x. 2 root root 4096 Jun  6  2012 bluetooth.target.wants
lrwxrwxrwx. 1 root root  41 Jun  6  2012 dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service
lrwxrwxrwx. 1 root root  44 Jun  6  2012 dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx. 1 root root  46 Jun  6  2012 dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root  36 Jun  6  2012 default.target -> /lib/systemd/system/runlevel5.target
drwxr-xr-x. 2 root root 4096 Jun  6  2012 default.target.wants
drwxr-xr-x. 2 root root 4096 Jun  6  2012 getty.target.wants
drwxr-xr-x. 2 root root 4096 Sep 22 07:02 multi-user.target.wants
drwxr-xr-x. 2 root root 4096 Sep 22 07:02 nfs.target.wants
drwxr-xr-x. 2 root root 4096 Jun  6  2012 printer.target.wants
drwxr-xr-x. 2 root root 4096 Sep 22 07:29 sockets.target.wants
drwxr-xr-x. 2 root root 4096 Sep 18 14:47 sysinit.target.wants
lrwxrwxrwx. 1 root root  39 Jun  6  2012 syslog.service -> /usr/lib/systemd/system/rsyslog.service
drwxr-xr-x. 2 root root 4096 Sep 22 07:05 system-update.target.wants

From reading of various docs about Fedora boot sequence I understand that in
the past various configuration files were used while now instead of them
there are directories named *.target which contain groups of new type
configuration files. Pity none of these dirs/files names hints to being
related to display manager...

At least it looks like the runlevel is ok (5).

Does anyone sees somefile missing from my ls output?
Any other ideas?

TIA,
kaza.

kaza 09-28-2013 04:11 PM

Hi again PTrenholme,

Looking again I noticed that although you gave a path of an old type
config file but the "cat" output is of the new type *.service file.

I created /etc/systemd/system/display-manager.service file
with the contents from your "cat" output but from reading
the docs and from the contents of that file It seems to me that I also have
the "systemd-user-sessions.service" file missing (at least), based on the line:

Code:

After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service
I've read "man systemd.unit" and if I understand correctly, I need
systemd-user-sessions.service
getty@tty1.service
plymouth-quit.service

to start the "display-manager.service", right?

TIA,


All times are GMT -5. The time now is 01:33 PM.