Description of problem: This is a multi-fold problem: a) When booting into run level 3 and updating with yum, then in the middle of the update the Plymouth's screen pops-up. Switching back to VT does not work, TAB key does not do anything. So I would suspect systemd to be responsible for these things. The krb5* stuff was part of the update. b) Next boot, yum complains that it cannot load libkrb5.so.3, because it is to short. The same for dnf. GDM obviously does not start. So the system is basically DEAD. Version-Release number of selected component (if applicable): yum-3.4.3-132 systemd-208-9 How reproducible: UNKNOWN Steps to Reproduce: 1. Boot into run level 3 2. yum update --enablerepo=*testing 3. When Plymouth's screen pops-up wait until HDD is idle. 4. Restart 5. yum update --enablerepo=*testing Actual results: libkrb5.so.3 is broken (has zero size). Neither yum or dnf could be invoked. Expected results: yum or dnf are both work fine. Additional info:
Well, the fact that multiple components are affected suggests that the problem is not in one of them. Either update of the krb5 component was broken or systemd did something nasty to the update process. Reassigning to krb5 for further evaluation, feel free to switch to systemd if nothing bad is going on in there. You might try working around the issue by reinstalling the Kerberos library manually by rpm.
I have another Fedora 20 based system that runs just fine. The first issue is there and it is persistent (100% reproducible). The only difference is that I've done an update (that included krb5 stuff) from gnome, but not from run level 3. So I would not blame krb5, but rather systemd and yum. To me having such a single point of failure as not-even-used krb5 in yum/dnf/gdm is a huge security flow. At the end of the day, yum's reinstall/disto-sync is the only recovery tools for such a bleeding-edge beast as Fedora is. So in my opinion it should be as isolated and independent as it possible.
There are two problems in there: the first one is the cause and the second is the consequence. The consequence can be hardly influenced by yum, as the dependency on Kerberos lies deep underneath (FYI it's yum -> python-urlgrabber -> python_pycurl -> libcurl -> krb5-libs). At this point the problem is about hardcore general system inconsistency, probably going way down to dynamic linker not being able to process the krb5 library. And as for the cause, it is perfectly possible that the problem was caused by systemd shutting down yum and rpm in the middle of transaction. In such cases there is no way to guarantee consistency of the system from yum's point of view. I reassigned the bug to krb5 to eliminate the possibility of bad testing update of krb5-libs. If there is no such problem, investigation can continue to see if and why the update was interrupted in the middle of transaction. On this front I'd like to ask you for more information (anything that can help identifying the problem), as the description you have is most certainly insufficient and would lead to the bug getting closed.
Ok, I see your point. The only problem I see is the 'yum-complete-transaction' that should, in principle, recover the system if yum was interrupted. But it suffers from the same problem. Perhaps, I am mistaken and just don't see the logic here. Anyway, I will recover my system in a few hours and provide some more details.
I understand your perspective, however there are some blind spots. For instance yum-complete-transaction is a tool that just attempts to complete the transaction, in many cases the transaction is beyond repair. Also, as I noted earlier, this issue is much deeper than yum can influence. To use rather extreme comparison, if your BIOS is broken, you will also not blame Fedora for not starting. Anyway, if you can provide any extra details how the system got to the current state, it will be definitely helpful.
What's the version of krb5-libs (including arch and release) that the system believes is installed? It should be easy enough to look at the contents of the package as the build systems produced it.
Created attachment 861973 [details] 'yum history info' of the failed transaction that broke krb5* among others
Created attachment 861974 [details] 'yum history info' of the following reinstall of the krb5* stuff
Created attachment 861976 [details] 'journalctl -b' of the boot, when yum transaction failed
Jan, Nalin, I've posted what I believe is the relevant info. Please feel free to request other things if it is required.
Jan, I can verify that neither krb5-libs-1.11.3-39.fc20 nor krb5-libs-1.11.5-2.fc20, for either i686 or x86_64, included a zero-length libkrb5.so.3.3.
Nalin, thank you for your assistance, seems like krb5 is really not the issue. I looked at the journal and I find this part the most interesting: Feb 11 09:37:25 localhost.localdomain yum[1102]: Installed: systemd-libs-208-9.fc20.i686 Feb 11 09:37:27 localhost.localdomain systemd[1]: Reloading. Seems like after the installation of systemd-libs, systemd decided to do something extra with the system which might have caused yum to interrupt. Reassigning to systemd component for further evaluation.
*** Bug 1063957 has been marked as a duplicate of this bug. ***
There appear to be a race condition in systemd's reload implementation. We're working on a fix.
The problem is not specific to the case when systemd is updated. It does 'something extra' every time yum is invoked from VT.
Created attachment 864392 [details] 'journalctl -b' of the boot, when yum is invoked
*** This bug has been marked as a duplicate of bug 1043212 ***
*** Bug 1045856 has been marked as a duplicate of this bug. ***