Description of problem: After an apparently successful upgrade from fc6 to f7, the control-center package was not installed/upgraded. Control-center was installed in fc6 before the upgrade, so the fc6 control-center files were still on the filesystem and still available in the gnome menu. Choosing the Desktop Background menu item caused a Bug Buddy crash, for example. Installing the f7 version of control-center solved the problem. Version-Release number of selected component (if applicable): FC6 fully updated, then using Fedora-7-i386 DVD final release to upgrade. control-center.i386 1:2.18.0-18.fc7 was installed to solve problem. How reproducible: Not sure. Probably always. Steps to Reproduce: 1. Have FC6 i386 installed, fully updated, control-center installed, on an IBM Thinkpad T43. 2. Upgrade to F7 using Fedora-7-i386 DVD (media verified ok) 3. Create a new user to avoid stale gnome profile data 4. Log in to gnome session 5. Select menu System->Preferences->Look and Feel->Desktop Background 6. Notice Bug Buddy crash 7. Open Terminal, run gnome-background-properties 8. See this error: (gnome-background-properties:2664): libglade-WARNING **: could not find glade file '/usr/share/applications/gnome-background-properties.glade' (gnome-background-properties:2664): libglade-CRITICAL **: glade_xml_get_widget: assertion `self != NULL' failed ...etc... Actual results: See steps 6 and 8 above Expected results: See Desktop Wallpaper change dialog Additional info: # rpm -q control-center package control-center is not installed # yum install control-center ... --> Running transaction check ---> Package control-center.i386 1:2.18.0-18.fc7 set to be updated --> Processing Dependency: libgnomekbd.so.1 for package: control-center --> Processing Dependency: libgnomekbdui.so.1 for package: control-center --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package libgnomekbd.i386 0:2.18.0-1.fc7 set to be updated ... Notice libgnomekbd also installed as dependency. After installing control-center.i386 1:2.18.0-18.fc7, the Desktop Background app works as expected.
Could you please attach the upgrade logs (which should have been added to your /root)? We'd then see why it wasn't upgraded.
Here's the relevant part. Full attachment next. Upgrading control-center - 1:2.18.0-18.fc7.i386 I/O warning : failed to load external entity "/etc/gconf/schemas/control-center.schemas" Failed to open `/etc/gconf/schemas/control-center.schemas': No such file or directory error: unpacking of archive failed on file /etc/gconf/schemas/apps_gnome_settings_daemon_default_editor.sc hemas: cpio: lsetfilecon
Created attachment 156093 [details] Upgrade log from fc6-f7 upgrade
There are lots of these types of errors in the upgrade log. What would cause this? I should have had plenty of disk space available. It looks limited to /etc/security/console.apps and /etc/gconf/schemas. # bzcat upgrade.log.bz2 | grep ^error error: unpacking of archive failed on file /etc/security/console.apps/system-config-printer: cpio: lsetfilecon error: unpacking of archive failed on file /etc/security/console.apps/serviceconf: cpio: lsetfilecon error: unpacking of archive failed on file /etc/security/console.apps/setup: cpio: lsetfilecon error: unpacking of archive failed on file /etc/gconf/schemas/desktop_gnome_file_sharing.schemas: cpio: lsetfilecon ... etc 49 lines total ...
Maybe an unclean file system, I'm not sure. Reassigning to anaconda, as it seems related.
What's the output of ls -lRZ /etc/gconf/schemas /etc/security/console.apps
Created attachment 156123 [details] ls -lRZ /etc/gconf/schemas /etc/security/console.apps Maybe some unlabeled files? I had selinux disabled via "selinux=0" on the kernel boot line in fc6. Now in f7, the kernel boot line is removed, and selinux is disabled via /etc/selinux/config: $ cat /etc/selinux/config | grep ^SELINUX= SELINUX=disabled
Did you boot the installer with 'selinux=0'? And had you changed /etc/selinux/config prior to starting the upgrade? If no to both, then we were probably doing the upgrade as though selinux had been enabled and then getting very unhappy due to the labeling problems. Dan -- is there any way we can detect this?
import selinux if selinux.is_selinux_enabled() < 1: Will tell you if selinux is disabled.
No, I didn't boot the installer with selinux=0. Yes, afaik /etc/selinux/config was set to disabled before the upgrade. As an aside, isn't it a bit odd to do an os install under selinux? Are we expecting security protection while installing the os? I can say that this problem manifests itself in odd problems. For example, gnome-panel was also not upgraded and all of the panel applets refused to start giving errors such as: "OAFIID:GNOME_ClockApplet libpanel-applet-2.so.0: cannot open shared object file: No such file or directory"
(In reply to comment #9) > Will tell you if selinux is disabled. Sure, that will tell me about _now_. But it won't let me find out that someone has been booting their install with selinux=0 forever but didn't boot anaconda with it. Pain lies this way... (In reply to comment #10) > As an aside, isn't it a bit odd to do an os install under selinux? Are we > expecting security protection while installing the os? We have to have SELinux enabled (though in permissive) when doing the upgrade so that we can set file contexts on things being installed. I'm not quite sure why we'd be getting EPERM with lsetfilecon() in this case, though :-/
Maybe anaconda could look at the existing grub.conf for selinux=0, or optionally scan/relabel the filesystem looking for unlabeled files before install? Have we determined that unlabeled files caused this problem?
If there is a /.autorelabel file you could do a getfilecon on it. If it does not have a file context it is a good indicatory selinux=0.
Init scripts create /.autorelabel any time you boot selinux=0. So the file will get created without a file context. The scripts do this, so the first time you boot selinux=1 a relabel will happen.
$ ls -l /.autorelabel -rw-r--r-- 1 root root 0 2006-05-17 14:56 /.autorelabel Maybe the install process skipped the relabel?
$ ls -lZ /.autorelabel -rw-r--r-- root root /.autorelabel
No the autorelabel is used when you boot with selinux=1. The installer currently ignores it.
Wouldn't that have prevented this problem? Maybe the installer should do a relabel too?
fyi, these packages were not upgraded as a result of this issue. I grepped the upgrade.log file to install the missing ones. Installing: bug-buddy i386 1:2.18.0-2.fc7 fedora 443 k compiz i386 0.3.6-8.fc7 fedora 547 k devhelp i386 0.13-8.fc7 updates 185 k eog i386 2.18.0.1-2.fc7 fedora 1.2 M evince i386 0.8.0-5.fc7 fedora 1.1 M evolution i386 2.10.1-4.fc7 fedora 29 M file-roller i386 2.18.1-1.fc7 fedora 966 k gcalctool i386 5.9.14-1.fc7 fedora 1.1 M gdm i386 1:2.18.0-14.fc7 fedora 4.3 M gedit i386 1:2.18.0-3.fc7 fedora 4.2 M gnome-applet-vm i386 0.1.2-2.fc7 fedora 76 k gnome-applets i386 1:2.18.0-7.fc7 fedora 10 M gnome-bluetooth i386 0.8.0-4.fc7 fedora 249 k gnome-games i386 1:2.18.1.1-1.fc7 fedora 8.5 M gnome-media i386 2.18.0-3.fc7 fedora 2.5 M gnome-netstatus i386 2.12.1-1.fc7 fedora 298 k gnome-pilot i386 2.0.15-5.fc7 fedora 599 k gnome-power-manager i386 2.18.2-4.fc7 fedora 2.8 M gnome-screensaver i386 2.18.0-13.fc7 fedora 1.8 M gnome-session i386 2.18.0-7.fc7 fedora 476 k gnome-terminal i386 2.18.0-1.fc7 fedora 2.3 M gnome-user-share i386 0.11-2.fc7 fedora 44 k gnome-utils i386 1:2.18.0-1.fc7 fedora 4.9 M gnome-volume-manager i386 2.17.0-7.fc7 fedora 431 k gstreamer-plugins-good i386 0.10.5-6.fc7 fedora 652 k gthumb i386 2.10.2-3.fc7 fedora 2.2 M nautilus i386 2.18.1-2.fc7 fedora 4.3 M nautilus-cd-burner i386 2.18.0-2.fc7 fedora 503 k nautilus-sendto i386 0.10-4.fc7 fedora 80 k pirut noarch 1.3.7-1.fc7 fedora 265 k planner i386 0.14.2-4.fc7 fedora 3.5 M setuptool i386 1.19.2-2 fedora 51 k sound-juicer i386 2.16.4-1.fc7 fedora 1.1 M system-config-date noarch 1.9.0-1.fc7 fedora 1.1 M system-config-printer i386 0.7.63.1-1.fc7 fedora 173 k system-config-services noarch 0.9.8-1.fc7 fedora 188 k system-config-soundcard noarch 2.0.6-5.fc7 fedora 1.1 M vino i386 2.18.0-1.fc7 fedora 411 k virt-manager i386 0.4.0-2.fc7 fedora 1.3 M
Fix for this committed to CVS
Fix confirmed upgrading F7 to F8.