11:16 p.m.
Hi everyone,
I just upgraded my system from Fedora 16 to Fedora 17 using yum as
described at https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum.
Here are my notes from the experience. I'm not really sure which of
these to file bugs about; any feedback on that score would be appreciated.
The Fedora 16 -> Fedora 17 instructions say that the upgrade requires at
least dracut-013-22.fc16, but "yum update" didn't get me that version,
so I had to download and install it manually from koji. Presumably this
is because it just hadn't been pushed to the yum repo yet and this
problem will rectify itself soon enough.
I could have sworn I typed the "dracut --force --add convertfs" command
properly and that it actually did something, but apparently not, because
when I rebooted afterward I still had my old initramfs. I ran the same
command again after that reboot and then rebooted a second time, and
this time it worked. I guess I must have typed the command wrong or
something, but really, I could have sworn I didn't.
The only *.usrmove~ files created by the conversion were
/usr/sbin/mount.davfs.usrmove~ and /usr/sbin/umount.davfs.usrmove~. I
don't know why these two files in particular were created. I removed
them after the upgrade, after confirming that mount.davfs and
umount.davfs existed.
I had to remove some orphan RPMs to get yum distro-sync to work, but
that's to be expected so I don't think there's any point in enumerating
them here.
After the upgrade, both named.service and dhcpd.service were disabled in
systemd, even though they were both enabled prior to the upgrade.
Perhaps this is because named and dhcpd were switched to systemd in F17?
I imagine other people are going to run into this issue and be irritated
by it. Note that the upgrading with yum page listed above mentions
recording enabled services before the upgrade and restoring them
afterward for the Fedora 15 -> Fedora 16 upgrade, but /not/ for the
Fedora 16 -> Fedora 17 upgrade. If some services are being converted
from initscripts to systemd in F17, they need to be called out on this page.
After the upgrade, dhcpd was complaining, "Multiple interfaces match the
same shared network: eth2 eth2:1". This arose from this configuration
stanza in /etc/dhcp/dhcpd.conf:
shared-network eth2 {
subnet 192.168.0.0 netmask 255.255.255.0 {
option broadcast-address 192.168.0.255;
option subnet-mask 255.255.255.0;
option routers 192.168.0.20;
range 192.168.0.100 192.168.0.110;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
}
}
I have two IP addresses on eth2:
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.20 netmask 255.255.255.0 broadcast
192.168.0.255
inet6 fe80::e291:f5ff:fe20:3441 prefixlen 64 scopeid
0x20<link>
ether e0:91:f5:20:34:41 txqueuelen 1000 (Ethernet)
eth2:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.1 netmask 255.255.255.0 broadcast
192.168.3.255
ether e0:91:f5:20:34:41 txqueuelen 1000 (Ethernet)
The same configuration file worked fine prior to the upgrade. I tried
creating wrapping the "subnet 192.168.3.0" declaration in a separate
"shared-network" declaration, but then it complained "Failed to get HW
address for eth2:1". Finally I just removed the 192.168.3.0 subnet
declaration from the config file entirely, since I don't actually need
dhcpd to be able to issue addresses on that subnet, but I fear that if I
did need to, I wouldn't be able to get it to. There appears to be a
potential regression here.
I had the gnome-shell weather extension
<https://github.com/simon04/gnome-shell-extension-weather> installed
prior to the upgrade. After the upgrade, it made gnome-shell crash until
I deleted it. Even after I recompiled and reinstalled it from the
gnome3.4 branch, it still made gnome-shell crash, so I had to disable it
for the time being. I am disappointed; I like that extension. I've
emailed the author to ask if he knows what's up.
Incidentally, once it's working again I'd really like to see it added to
Fedora as an RPM so I don't have to keep downloading and installing it
from source. It's a great extension. Aside from it, does anybody else
know a good way to get a persistent weather applet of some sort on my
screen?
Prior to the upgrade my window title bars had minimize, maximize, and
close buttons. After the upgrade only the close button remained, and I
had to use gnome-tweak-tool to put back the other buttons, just as I had
long ago to get them in the first place. Is it a bug that this
configuration setting was lost and had to be restored? Is it possible
that gnome-shell reverted to its default settings because it was
crashing or something like that?
Similarly, I had mouse focus configured prior to the upgrade, but after
the upgrade gnome-shell reverted to click focus and I had to tweak it again.
For some bizarre reason the Firefox icon disappeared from my favorites.
I was able to put it back easily enough by launching Firefox and then
right-clicking on it and selecting "Add to Favorites", but I don't think
it should have disappeared in the first place. Bug?
Nautilus was failing to start up after the upgrade. There were errors in
my .xsession-errors which appeared to be related to nautilus-dropbox. I
removed the nautilus-dropbox RPM (which came from dropbox.com) and
logged out and back in and nautilus started working again. Then I
reinstalled the /same/ nautilus-dropbox RPM, and it worked just fine. Weird.
I have a VirtualBox VM launcher icon (type application/x-desktop) on my
desktop. After the upgrade, in addition to the icon displaying its name,
it also displayed its Comment, which was just way too long and made the
text under the icon much too large. I don't like this behavior; I think
icons should display only their names, not their comments. In any case,
the weird thing is that I tried opening the icon's properties, removing
the comment, and closing it, and it didn't work -- the comment remained.
I tried changing the comment to a shorter string and closing it, and
that didn't work either. However, later on, several logins later, when I
tried the same thing, it worked! Bizarre.
When I restart gnome-shell with Alt-F2 r, my desktop "shifts" down and
to the right. Check out this screen shot of the upper left corner of my
screen after a restart:
I suspected this might be due to the fact that I had the dock extension
enabled, but I disabled it and the problem didn't go away. Might it have
something to do with the fact that I have two monitors? Should I file a
bug? Note that if I restart multiple times, it does /not/ shift further
and further; it only shifts as far as shown above.
I noticed in gnome-tweak-tool that I had no shell theme installed. There
are a number of gnome-shell-them-* RPMs, but apparently none of them is
installed by default in the GNOME Desktop Environment yum group. Should
one of them be?
The icon-manager gnome-shell extension can't be enabled in
gnome-tweak-tool. There's a caution icon next to its switch, which is
insensitive. Is this a known problem?
Not relevant to Fedora /per se/, but I had trouble rebuilding my
Thunderbird tree after the upgrade because hg now returns a non-zero
exit status when there are no changes to pull, and the client.py script
in the Thunderbird source tree for updating the tree from the
repositories isn't expecting this. I filed a mozilla bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=741145> about the problem.
A number of config files ended up with *.rpmnew counterparts even though
I had never made any changes to them (and I confirmed this by checking
that the *.rpmnew files were identical to their non-suffixed
counterparts). I suspect this is mostly caused by packages where both
the i686 and x86_64 versions are installed. This is a longstanding
problem with RPM that somebody really should fix one of these days. :-)
Thanks,
jik
