Description of problem: This may not be a kernel problem, but I don't yet know how to classify it better and am assuming that those who know better will reclassify it for me. http://forums.fedoraforum.org/showthread.php?t=277181 describes the same thing I experience: I've been using fedora 16 for a long time. After several weeks worth of yum update's resulting in two new kernel versions I tried to reboot and found I couldn't. The message at the bottom says something like see 'systemctl status prefdm.service' for details However, there are lots of messages above about unable to touch various files like /var/lock/... which turn out to be in directories that don't exist. I am able to boot to single mode. Simply creating those directories doesn't seem to help - they again do not exist the next time. I am able to move to runlevel 3 from the single boot. I am able to then login as root and startx but I cannot startx when logged in as a user. I suspect that many things are not working right, but one thing I find very suspicious is that yum update reports nothing to do. I was hoping that others had found this bug and that it was fixed. But if yum isn't working then I'll have to fix that manually before I can get the fixes for the rest. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Nothing there sounds kernel related. I've moved it to the general distribution component for now. This might be gdm or systemd, but I don't know which.
yum update showed a new kernel (and other stuff), so I tried rebooting to that I still get the same behavior if I don't boot single, but now after boot single and move to runlevel 3 I can login as user. Lots of things are working better but still finding things not quite right. BTW, new kernel is kernel-3.3.1-5.fc16.x86_64
A few more details - when login as user I see some new abrt entries. Rather than report them directly, I copy paste some details here. cmd line: python /usr/bin/printer-applet reason: connection.py:630:call_blocking:DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file backtrace: connection.py:630:call_blocking:DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file Traceback (most recent call last): File "/usr/bin/printer-applet", line 1163, in <module> applet = JobManager() File "/usr/bin/printer-applet", line 300, in __init__ notification = NewPrinterNotification(bus, self) File "/usr/bin/printer-applet", line 1052, in __init__ bus_name = dbus.service.BusName (PDS_OBJ, bus=bus) File "/usr/lib/python2.7/site-packages/dbus/service.py", line 129, in __new__ retval = bus.request_name(name, name_flags) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 306, in request_name 'su', (name, flags)) File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file Local variables in innermost frame: byte_arrays: False self: <dbus._dbus.SystemBus (system) at 0x2e0c6b0> args: ('com.redhat.NewPrinterNotification', 0) utf8_strings: False bus_name: 'org.freedesktop.DBus' get_args_opts: {'byte_arrays': False, 'utf8_strings': False} object_path: '/org/freedesktop/DBus' timeout: -1.0 signature: 'su' dbus_interface: 'org.freedesktop.DBus' message: <dbus.lowlevel.MethodCallMessage object at 0x2fa7600> method: 'RequestName' Second one seems harder to copy/paste data from. Problem description is that /usr/lib/jvm/java-1.7.0.../java was killed by signal 6 (sigabrt) This looks like it's related to abrt itself. Here's stuff from /var/log/messages that seems related. Apr 15 12:04:28 number11 abrtd: Directory 'ccpp-2012-04-15-12:04:26-11391' creation detected Apr 15 12:04:28 number11 abrt[11403]: Saved core dump of pid 11391 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java) to /var/spool/abrt/ccpp-2012-04-15-12:04:26-11391 (110288896 bytes) Apr 15 12:04:32 number11 abrtd: New problem directory /var/spool/abrt/ccpp-2012-04-15-12:04:26-11391, processing
Seems to be a problem with gdm. Reassigning. Please attach /var/log/messages from when this happens.
You want the entire boot transcript from /var/log/messages? I will attach what I think is the first failure - I hope there's not too much sensitive info in it.
Created attachment 577803 [details] /var/log/messages transcript from first boot failure
What does this command say?: systemctl status systemd-tmpfiles-setup.service
This is in the new kernel after I login as user and startx: $ systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: [1;31mfailed[0m since Sun, 15 Apr 2012 01:00:48 -0700; 2 days ago Main PID: 1154 (code=exited, status=127) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service Is this supposed to be deleting files from /tmp ? Can I turn it off? Or at least control it? I've disabled it for now - replaced /bin/systemd-tmpfiles with a shell script that does nothing but record that it was called. It's hard to believe that has anything to do with all of these symptoms.
(In reply to comment #8) > $ systemctl status systemd-tmpfiles-setup.service > systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories > Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static) > Active: [1;31mfailed[0m since Sun, 15 Apr 2012 01:00:48 -0700; 2 days ago > Main PID: 1154 (code=exited, status=127) > CGroup: name=systemd:/system/systemd-tmpfiles-setup.service > > Is this supposed to be deleting files from /tmp ? It can do that too, but that's not its primary purpose. As its description says, it's meant to "Recreate Volatile Files and Directories". That includes such directories as /run/lock (to which /var/lock should point). > Can I turn it off? Don't. > Or at least control it? man tmpfiles.d > I've disabled it for now - replaced /bin/systemd-tmpfiles with a shell script > that does nothing but record that it was called. Please undo that.
ok, it's undone. Now I suppose you want me to reboot? Perhaps to the older kernel to see whether it all works there too? It seems that my change didn't hurt anything until reboot. I have to say that it's extremely unfriendly to change the software that I've been using for years (tmpwatch config set NOT to delete files from /tmp) to start deleting my files. I wonder what else has been changed behind my back.
Yes, if you would, reboot and pass the following parameters on the kernel command line: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M After booting save the output of the 'dmesg' command and attach it. Thanks.
Created attachment 578159 [details] dmesg
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.