On Sun, 21 Nov 2021 13:09:13 -0700 stan via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 21 Nov 2021 09:34:17 -0700 > stan via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > There have been no updates to rawhide most of this week. Today a > > slug of updates came through, 271 for 775 MB. After those updates, > > run when the system was in multiuser, the system locks when I try to > > start X. I rebooted and received the same result; multiuser boots, > > X doesn't and locks the system. I haven't investigated extensively > > yet, but I don't find any bugzillas or other messages about this. I > > thought I would post a heads up about it, and attach a file of the > > dnf transaction log that caused the problem. I don't see anything > > that should have caused this issue in the updates, but it might be > > an obscure library that has changed ABI. The keyboard still is > > active, but when I try to use the REISUB sequence to recover, no > > dice. I have to hard reset the computer. > > > > The command that is causing the lockup is > > startx -- vt10 > > with > > exec startlxde > > in $XCLIENTS > > > > Some further information indicating the problem is xinit. On my > system, that is still an f35 package, though many of the packages it > depends on are now f36. I wonder if that isn't the problem. Should I > open a bugzilla against xinit? Or should I try rebuilding the xorg > packages locally and seeing if that is the problem? The only direct > dependency package in the update seems to be glibc. Could that > somehow be the issue? That the xorg stack has to rebuilt with the new > glibc? binutils isn't listed as a dependency, but could it be > affecting X somehow? Compiled the server, xinit, and xauth packages locally, made no difference. I think that lets glibc off the hook. The line that is different from when an X start succeeds is: xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) Don't know where that is coming from, will have to track it down. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure