Bug 812555 - unable to boot normally after yum update
Summary: unable to boot normally after yum update
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-14 19:42 UTC by Donald Cohen
Modified: 2013-02-13 22:06 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 22:06:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
/var/log/messages transcript from first boot failure (102.20 KB, application/octet-stream)
2012-04-16 18:22 UTC, Donald Cohen
no flags Details
dmesg (242.84 KB, text/plain)
2012-04-17 21:28 UTC, Donald Cohen
no flags Details

Description Donald Cohen 2012-04-14 19:42:19 UTC
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:

Comment 1 Josh Boyer 2012-04-14 20:29:12 UTC
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.

Comment 2 Donald Cohen 2012-04-15 19:54:41 UTC
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

Comment 3 Donald Cohen 2012-04-15 20:23:05 UTC
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

Comment 4 Lennart Poettering 2012-04-16 17:52:41 UTC
Seems to be a problem with gdm. Reassigning.

Please attach /var/log/messages from when this happens.

Comment 5 Donald Cohen 2012-04-16 18:21:16 UTC
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.

Comment 6 Donald Cohen 2012-04-16 18:22:32 UTC
Created attachment 577803 [details]
/var/log/messages transcript from first boot failure

Comment 7 Michal Schmidt 2012-04-17 12:25:44 UTC
What does this command say?:
systemctl status systemd-tmpfiles-setup.service

Comment 8 Donald Cohen 2012-04-17 16:49:09 UTC
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.

Comment 9 Michal Schmidt 2012-04-17 17:07:39 UTC
(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.

Comment 10 Donald Cohen 2012-04-17 17:27:22 UTC
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.

Comment 11 Michal Schmidt 2012-04-17 17:35:25 UTC
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.

Comment 12 Donald Cohen 2012-04-17 21:28:20 UTC
Created attachment 578159 [details]
dmesg

Comment 13 Fedora End Of Life 2013-01-16 17:26:20 UTC
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

Comment 14 Fedora End Of Life 2013-02-13 22:06:35 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.