Attempting to upgrade FC17 to FC19 using fedup
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
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
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..." :-)
If you really have that
I would look around, checking config files (fstab, hosts, etc) and check that the lo interface is up to give you loopback networking.
What exactly should I look for in the config files?
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.
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?
OK, after some googling I looked into the file
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?
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?
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
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 :-).
I looked into /etc/X11/xinit/xinitrc:
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
The file /etc/X11/xinit/Xclients contents are:
So it seems the KDE is the preferred environment but still, why it's not executed?
I also looked at the /etc/X11/xinit
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
and comment out the rest. It would probably run. But I would back up the unhacked version. Otherwise, enjoy grokking their scripts :-P.
Check your systemd settings. You should see something like this: (Note the lines in red highlight, especially the last two.)
You might also try running dracut to regenerate your initial RAM file system. From the running X session.
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:
I checked my systemd settings and I saw that I don't have the file
while I have the files
(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?
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?
I don't have the display-manager.conf file:
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?
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:
to start the "display-manager.service", right?
|All times are GMT -5. The time now is 10:43 AM.|