On Monday, May 30, 2011 04:11:26 n2xssvv.g02gfr12930 wrote:
>
> To anyone trying to upgrade from Fedora 14 to Fedora 15, DON'T EVEN
> TRY!!! I've just tried and have had numerous problems, finally
> resulting in being unable to boot up any kernel version at all,
> using inittab mode 1,3, or 5. In view of this it appears I will have
> to reinstall Fedora 14.
While, in one instance, I had problems, I wouldn't recommend not even
trying. F15 is a stable good release for me on two machines.
Here's my experience on two systems:
At work, I did the preupgrade thing and it was a big yawn. All went
well and everything Just Works(tm).
At home, I used the DVD to upgrade. I had several problems, but I was
able to recover from all of them:
1. I was not asked to include the updates repository during the
update process. Now I will have to do an update after first boot.
2. This is apparently a general problem not really related to the
specific upgrade. I noticed that the upgrade process was slow. The
disk just churned forever. After booting for the first time, I ran
yum erase on my debuginfos so that the subsequent yum update would not
pull those in. This erase command took way too long.
I think the rpm database gets into a state that needs attention. This
fixed it:
sudo rm -f /var/lib/rpm/__db.001 /var/lib/rpm/__db.002 \
/var/lib/rpm/__db.003 /var/lib/rpm/__db.004
sudo rpm --rebuilddb
After that, yum operations sped up an order of magnitude.
3. The first boot ended at multiuser.target instead of
graphical.target. (That's init level 3 instead of level 5 in
oldspeak.) I have never touched the inittab on either machine. They
were both set to boot into the graphical login.
When I entered the command
sudo systemctl isolate graphical.target
kdm came up and allowed a normal desktop login.
Hmmm. I compared my machine at work to the home machine and it had
the correct graphical.target file linked in /etc/systemd/system . So
I had to do this to correct the problem:
sudo rm /etc/systemd/system/default.target
sudo ln -s /lib/systemd/system/runlevel5.target \
/etc/systemd/system/default.target
I don't know why this happened with the DVD upgrade and not with the
preupgrade upgrade.
4. I then did a yum update and waited a few hours while over 500
packages were downloaded and updated/installed. This was almost 1GB
of downloads. Most packages did not have delta rpms.
5. I run KDE and after logging in and starting Kmail, it refused to
start, complaining about akonadi not being available:
Test 5: ERROR
...
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
<repeated many times>
Test 10: ERROR
...
Akonadi control process not registered at D-Bus.
Test 15: ERROR
...
No resource agents found.
(Wow, this is a fragile piece in kdepim.)
The fix for this ended up being:
sudo yum --enablerepo=kde-testing update
Only Kmail users will experience this one and once the fixed
packages are in updates, it won't happen at all.
6. There was no system log after the upgrade. That one was fixed
with this:
sudo systemctl enable rsyslog.service
Now the home system is operating as expected and all looks good.
Based on my reading over the past several weeks, I think others have
already encountered most of this stuff.
Summary
-------
Serious system problems were 3 and 6 above. These were surprises.
Both were trivial to recover from. The rest was irritating only.
Thank you for another excellent Fedora release.
--
Garry Williams
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
