Bug 693410 - yum upgrade to systemd-22-1.fc15.x86_64 stales the boot
Summary: yum upgrade to systemd-22-1.fc15.x86_64 stales the boot
Status: CLOSED DUPLICATE of bug 692573
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-04-04 15:13 UTC by Mark Struberg
Modified: 2011-04-05 14:21 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-04-05 14:21:38 UTC
Type: ---

Attachments (Terms of Use)

Description Mark Struberg 2011-04-04 15:13:30 UTC
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
yum update on Monday 4th April 15:00 CEST

Steps to Reproduce:
1. boot fedora 15 beta
Actual results:
System hangs in boot with the message
"Failed to mount /sys/fs/cgroup/systemd: No such file or directory"

Expected results:

Additional info:
I tried to start with the following
*) enforcing=0
*) 3 nomodeset
*) removed all kms settings

none of the actions solved my problem. 

Booting from CD and looking through the logs doesn't reveal any additional info.

Comment 1 Mark Struberg 2011-04-04 15:31:32 UTC
yum downgrade to 20-1.fc15 (via chroot) fixed the boot problem in the meantime

Comment 2 Mark Struberg 2011-04-04 16:49:26 UTC
apparently it seems to be a selinux problem with the new systemd.
If I use selinux=0 as boot param all works well.

Comment 3 Steven Haigh 2011-04-04 16:56:16 UTC
I also see this... The full boot errors are:

Failed to load SELinux policy.
Failed to set security context: system_u:object_r:sysfs_t:s0 for /sys: Invalid argument
Failed to set security context: system_u:object_r:sysfs_t:s0 for /sys: Invalid argument
Failed to mount /sys/fs/cgroup/systemd: No such file or directory

# rpm -qa | grep systemd

# rpm -qa | grep selinux-policy

Comment 4 Mark Struberg 2011-04-04 17:19:37 UTC
same selinux versions over here (3.9.16-11.fc15)

Comment 5 James Laska 2011-04-04 17:30:19 UTC
Same as bug#692436 ?

Comment 6 Daniel Walsh 2011-04-04 17:31:16 UTC
systemd should be checking for enforcmode before failing.  If SELinux is in
permissive mode it should report the problem and continue.  If it is disabled
it should not try.

Comment 7 Steven Haigh 2011-04-04 17:35:34 UTC
I have the following in /etc/sysconfig/selinux (which now a link to /etc/selinux/config):

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.

This bug still occurs though - so the only option at the moment is to boot with selinux=0 on the kernel line.

Comment 8 Steven Haigh 2011-04-04 17:51:38 UTC
Tried booting with systemd.log_level=debug on the kernel line, however the first hint of any problem was the failure in my first post above. Can't add any value there.

Comment 9 Michal Schmidt 2011-04-04 19:29:26 UTC
(In reply to comment #7)
> I have the following in /etc/sysconfig/selinux (which now a link to
> /etc/selinux/config):
> SELINUX=disabled

You're seeing bug 692573.

Comment 10 Nathan Watson 2011-04-05 13:39:03 UTC
same problem here, running with SELINUX=disabled

Comment 11 Nathan Watson 2011-04-05 13:53:55 UTC
entering rescue mode and setting SELINUX=permissive works for now

Comment 12 Michal Schmidt 2011-04-05 14:21:38 UTC

*** This bug has been marked as a duplicate of bug 692573 ***

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