Description of problem: Upgrade from f20->f21 alpha using Fedup. All appeared to go OK, did a yum update after it rebooted and found a lot of updates, but then I hit an selinux warning from sshd (same as bz 987778), restorecon showed: [dg@major ~]$ sudo restorecon -R -v /usr/sbin/sshd restorecon reset /usr/sbin/sshd context system_u:object_r:bin_t:s0->system_u:object_r:sshd_exec_t:s0 [dg@major ~]$ ls -lZ /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd [dg@major ~]$ sudo restorecon -R -v /usr/sbin restorecon reset /usr/sbin/wpa_cli context system_u:object_r:wpa_cli_exec_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/sbin/reiserfstune context system_u:object_r:bin_t:s0->system_u:object_r:fsadm_exec_t:s0 restorecon reset /usr/sbin/accton context system_u:object_r:bin_t:s0->system_u:object_r:acct_exec_t:s0 restorecon reset /usr/sbin/tmpwatch context system_u:object_r:bin_t:s0->system_u:object_r:tmpreaper_exec_t:s0 restorecon reset /usr/sbin/sshd-keygen context system_u:object_r:bin_t:s0->system_u:object_r:sshd_keygen_exec_t:s0 restorecon reset /usr/sbin/irqbalance context system_u:object_r:bin_t:s0->system_u:object_r:irqbalance_exec_t:s0 restorecon reset /usr/sbin/reiserfsck context system_u:object_r:bin_t:s0->system_u:object_r:fsadm_exec_t:s0 restorecon reset /usr/sbin/mtr context system_u:object_r:bin_t:s0->system_u:object_r:traceroute_exec_t:s0 restorecon reset /usr/sbin/iw context system_u:object_r:bin_t:s0->system_u:object_r:ifconfig_exec_t:s0 restorecon reset /usr/sbin/proftpd context system_u:object_r:bin_t:s0->system_u:object_r:ftpd_exec_t:s0 restorecon reset /usr/sbin/mkreiserfs context system_u:object_r:bin_t:s0->system_u:object_r:fsadm_exec_t:s0 restorecon reset /usr/sbin/ntpdate context system_u:object_r:bin_t:s0->system_u:object_r:ntpdate_exec_t:s0 restorecon reset /usr/sbin/resize_reiserfs context system_u:object_r:bin_t:s0->system_u:object_r:fsadm_exec_t:s0 restorecon reset /usr/sbin/mcelog context system_u:object_r:bin_t:s0->system_u:object_r:mcelog_exec_t:s0 restorecon reset /usr/sbin/mount.cifs context system_u:object_r:bin_t:s0->system_u:object_r:mount_exec_t:s0 restorecon reset /usr/sbin/rngd context system_u:object_r:bin_t:s0->system_u:object_r:rngd_exec_t:s0 restorecon reset /usr/sbin/spice-vdagentd context system_u:object_r:bin_t:s0->system_u:object_r:vdagent_exec_t:s0 restorecon reset /usr/sbin/tcpdump context system_u:object_r:bin_t:s0->system_u:object_r:netutils_exec_t:s0 and there's a bunch more in /usr/lib64 and /usr/libexec Version-Release number of selected component (if applicable): How reproducible: Only tried it once Steps to Reproduce: 1. Take happy f20 install 2. Fedup it to f20 alpha (I had to use the work around in bz 1099299 #7) 3. Update after reboot 4. Check labelling of /sbin by using restorecon to relabel Actual results: restorecon has to fix a load Expected results: They should already match what restorecon is asking. Additional info:
It looks like some kind of yum/fedup/rpm bug which is not putting labels down properly. Seems like rpm labeling is being turned off?
In Fedora >= 21, selinux support of rpm was moved into a plugin, which rpm requires for now to make sure it gets dragged in on upgrades. Its of course possible that there are regressions in the selinux plugin, but given that fedup runs in a specially built initrd (AFAIK) then its probably simply missing this new thing (%{_libdir}/rpm-plugins/selinux.so) that needs to be copied into the initrd.
Ah, plugins. Magically breaking automatic dependency-gathering stuff since the invention of ldopen()... This will need to be fixed in fedup-dracut, which means the fix has to be built into the installer image. Did the SELinux mislabeling prevent your system from working in any way?
wwoods just drew my attention to this. Nominating for both blocker and FE status. We are not 100% sure yet whether the mislabelling breaks stuff, but it seems fairly likely it does, and if it did, that'd probably be a blocker. Criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ... Upgraded system requirements: The upgraded system must meet all release criteria." https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Upgrade_requirements I'd want to know for sure if the mislabelling causes critical breakage to vote +1 blocker, but I think it makes sense to say +1 FE right now as Will says the fix is simple and low-risk, and it's probably a good idea to get it in right now so hopefully once the udev bug is fixed we'll have fully working fedup.
+1 blocker
+1 FE now, +1 blocker if it turns out to cause blocking breakage.
Will: 'Did the SELinux mislabeling prevent your system from working in any way?' Yes, but not disastrously. The first thing I hit was libvirt over ssh hitting problems; but then I relabelled /sbin and /usr/bin, but then I keep hitting a few more from time to time and find something else I have to relabel; probably the worst thing will be hitting random problems for ages as the effects of mislabelling trickle around. So, it boots, but is a mess.
+1 FE
Based on comment #7, +1 FE, at least for now to grant ack to potential fix.
Discussed in 2014-10-20 Blocker Review meeting [1]. Accepted as a freeze exception. This bug would be great to get fixed for Beta. Blocker status is still undetermined, provide more information in the bug if severe breakage is found for it. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-20/
Discussed at 2014-10-22 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-22/f21-blocker-review.2014-10-22-16.03.log.txt . We think it's pretty likely this breaks things badly enough to constitute a violation of various other criteria like 'working desktop login and browser', so this is accepted as a blocker per criterion cited in c#4. However, it's worth noting we have a bit of flexibility in re exactly how fedup gets upgrade.img; it can be specified with --instrepo and the default location comes from MirrorManager. So it's possible we may be able to fudge this as not needing to be fixed in the frozen Beta package set, if it comes down to this bug at go/no-go. For the record. This only really, really needs to be fixed in frozen Beta package set if we're going to point https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-21 at the frozen Beta tree.
fedup-dracut-0.9.0-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fedup-dracut-0.9.0-1.fc21
Package fedup-dracut-0.9.0-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedup-dracut-0.9.0-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13615/fedup-dracut-0.9.0-1.fc21 then log in and leave karma (feedback).
fedup-dracut-0.9.0-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.