Bug 618009
| Summary: | Unable to log into Rawhide from level 3 after upstart-0.6.5-7+upstart-sysvinit-0.6.5-7 installation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | sd.domrep |
| Component: | upstart | Assignee: | Casey Dahlin <cdahlin> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | cdahlin, dwalsh, lpoetter, mgrepl, notting, pebolle, plautrba, vanhoof |
| Target Milestone: | --- | Keywords: | SELinux |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-07-26 20:54:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
sd.domrep
2010-07-25 15:27:18 UTC
The package shouldn't have significantly changed with the split. Did you install nothing else? No, I did update "rawhide report: 20100725 changes", but it did update only two package: xorg-x11-server-utils-7.4-19.fc14 and one more. The problem is I can't even log into linux on level 3: "init 3" on kernel boot options. It looks like it can't start bash or shell, because I see hdd activity, and then login prompt again. Of course I can swap hdd, start Fedora 13, which can mount ext4, and mount hdd with rawhide and check everything. But you need to explain where and what to look. 0) Removing upstart-sysvinit-0.6.5-7.fc14.i686 and downgrading upstart-0.6.5-7.fc14.i686 to upstart-0.6.5-5.fc14.i686 fixed this issue for me. I choose upstart-0.6.5-5.fc14.i686 because it looked safer to do that and upstart-0.6.5-6.fc14.i686 never hit my system (upstart-0.6.5-7.fc14.i686 was already in the repositories before the last upgrade of my rawhide machine). 1) (In reply to comment #3) > Of course I can swap hdd, start Fedora 13, which can mount ext4, and mount hdd > with rawhide and check everything. But you need to explain where and what to > look. This is off topic, I guess, but in very short: I booted a Fedora 13 Live Image from USB, mounted the hard disk, and manually deleted/downgraded these packages using rpm's --root option. Tricky stuff. same problem here: f14 login: root Password: Last login: Mon Jul 26 14:43:39 from master login: no shell: Permission denied. Fedora release 14 (Rawhide) Kernel 2.6.35-0.56.rc6.git1.fc14.x86_64 on an x86_64 (/dev/ttyS0) f14 login: and same via ssh: $ ssh root@f14 root@f14's password: Unable to get valid context for root Last login: Mon Jul 26 14:55:51 2010 Connection to f14 closed. seems like problem with move /sbin/init to /sbin/upstart and other tools to /lib/upstart selinux labels are different among f13 and f14: F13: # matchpathcon /sbin/init /sbin/upstart /sbin/init system_u:object_r:init_exec_t:s0 /sbin/upstart system_u:object_r:bin_t:s0 # matchpathcon /sbin/shutdown /sbin/reboot /sbin/telinit /sbin/runlevel /sbin/shutdown system_u:object_r:shutdown_exec_t:s0 /sbin/reboot system_u:object_r:bin_t:s0 /sbin/telinit system_u:object_r:bin_t:s0 /sbin/runlevel system_u:object_r:bin_t:s0 F14: # matchpathcon /sbin/init /sbin/upstart /sbin/init system_u:object_r:bin_t:s0 /sbin/upstart system_u:object_r:bin_t:s0 # matchpathcon /lib/upstart/shutdown /lib/upstart/reboot /lib/upstart/telinit /lib/upstart/runlevel /lib/upstart/shutdown system_u:object_r:lib_t:s0 /lib/upstart/reboot system_u:object_r:lib_t:s0 /lib/upstart/telinit system_u:object_r:lib_t:s0 /lib/upstart/runlevel system_u:object_r:lib_t:s0 # ls -lZ /sbin/init /sbin/upstart /sbin/shutdown /sbin/reboot /sbin/runlevel /sbin/telinit /lib/upstart/ lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/init -> upstart lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/reboot -> ../lib/upstart/reboot lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/runlevel -> ../lib/upstart/runlevel lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/shutdown -> ../lib/upstart/shutdown lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/telinit -> ../lib/upstart/telinit -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/upstart /lib/upstart/: lrwxrwxrwx. root root system_u:object_r:lib_t:s0 halt -> reboot lrwxrwxrwx. root root system_u:object_r:lib_t:s0 poweroff -> reboot -rwxr-xr-x. root root system_u:object_r:lib_t:s0 reboot -rwxr-xr-x. root root system_u:object_r:lib_t:s0 runlevel -rwxr-xr-x. root root system_u:object_r:lib_t:s0 shutdown -rwxr-xr-x. root root system_u:object_r:lib_t:s0 telinit Additional info. I have managed to successfully log in with kernel boot option: "selinux=0" So, I think "enforcing=0" turn selinux to permissive state and we can see all AVC. Yes, "enforcing=0" works, so if you someone want to try upstart-0.6.5-7.fc14 & upstart-sysvinit-0.6.5-7.fc14 , this is the temporary solution. Right, this should have been caught in Lennart's testing of his solution. Too bad it wasn't. It needs a policy fix if we're actually planning to support this bi-init idea. Or we can drop the idea. Fixed in selinux-policy-3.8.8-6.fc14 |