I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
end of messages: http://rd.and.net/SJhX3LWZ6
On 10/24/2010 10:29 AM, Bill Davidsen wrote:
I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
I know that if you're using kmod-nvidia you may have trouble after a kernel update if there's not a matching kmod update. Does X come up if you boot into the previous kernel?
Joe Zeff wrote:
On 10/24/2010 10:29 AM, Bill Davidsen wrote:
I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
I know that if you're using kmod-nvidia you may have trouble after a kernel update if there's not a matching kmod update. Does X come up if you boot into the previous kernel?
No amod/kmod in use, this is a stock system, and the messages regarding stale locks are probably the clue, when I did the reboot the system didn't reboot, it went down and hung. But I checked /var/lock for any leftover files, and didn't find them, so if there are stale locks they are in some non-standard place.
Previous kernel does the same thing, comes up to a black screen with a mouse pointer in the shape of a watch, and there it sits.
On 24 October 2010 18:29, Bill Davidsen davidsen@tmr.com wrote:
I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
Can you go through your yum log and see what exact packages did you update?
With me X boots fine, but it has frozen several times over the past 24 hours (I am on 32 bits, Intel graphics).
Looking at my yum log for Saturday, I see that glibc was updated with this version: https://admin.fedoraproject.org/updates/glibc-2.12.1-3?_csrf_token=4c28cc8ac...
The list of changes looks harmless enough, still I am considering downgrading glibc if I have another freeze, to see if that solves the problem.
Piscium wrote:
On 24 October 2010 18:29, Bill Davidsendavidsen@tmr.com wrote:
I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
Can you go through your yum log and see what exact packages did you update?
With me X boots fine, but it has frozen several times over the past 24 hours (I am on 32 bits, Intel graphics).
Looking at my yum log for Saturday, I see that glibc was updated with this version: https://admin.fedoraproject.org/updates/glibc-2.12.1-3?_csrf_token=4c28cc8ac...
I see that, but I'm not sure it matches the warnings about stale locks in the log. xorg.conf was not modified for several months.
The list of changes looks harmless enough, still I am considering downgrading glibc if I have another freeze, to see if that solves the problem.
Bill Davidsen wrote:
I did an upgrade last night (fc13, x86) to get the security updates, and on the reboot X doesn't come up. I think I've seen this before, but can someone jog my memory what it messed up? And thoughts as to why would be appreciated as well, of course.
end of messages: http://rd.and.net/SJhX3LWZ6
Maybe I should call this one FIXED, because I am not sure how it got broken. After the upgrade my root filesystem was very low on space. Rather than play with sizes (not on LVM) I decided to move the two GB of /usr/share to another partition and mount that.
What I did: - defined another partition on sdb - created a filesystem on it - mounted the new filesystem on /mnt/tmp - copied /usr/share to /mnt/tmp (yes with -r) - checked that the directories were the same - dropped to single user mode - removed (rm /usr/share/*) all the old content - umounted the new filesystem - remounted the new filesystem on /usr/share - got the new filesystem UUID and put in /etc/fstab - rebooted and got no video
Having tried everything else, I used restorecon to restore the labels on the /usr/share filesystem. Rebooted and got video.
I am reasonably sure I used "cp -ra" to copy the files, and if I didn't I would have used rsync with the "a" option which also should copy all the label information.
The clue was an sealert saying that the access was blocked to /usr/share/locale, and I didn't hit on it right away because without X the warning didn't pop up, it wasn't until I thought of selinux blocking some trojan in the update that I checked. No trojan, just a failure in the copy.
I'm unable to produce a failure in either cp or rsync, so I will assume either my typo or this keyboard which has been known to drop a character now and again.
Thanks to the two people who contributed some good thoughts on possible causes, they both proposed workarounds for other possible causes of a problem of this type.
-
Bill Davidsen -
Joe Zeff -
Piscium