Bug 618009 - Unable to log into Rawhide from level 3 after upstart-0.6.5-7+upstart-sysvinit-0.6.5-7 installation
Unable to log into Rawhide from level 3 after upstart-0.6.5-7+upstart-sysvini...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: upstart (Show other bugs)
rawhide
i686 Linux
low Severity high
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-25 11:27 EDT by sd.domrep
Modified: 2014-06-18 04:47 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-26 16:54:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sd.domrep 2010-07-25 11:27:18 EDT
Description of problem:
I installed:
upstart-0.6.5-7.fc14
upstart-sysvinit-0.6.5-7.fc14

And unable to log into the linux from Level 3
I see the login prompt, but when I type user login/password or root login/password, system just asks for it again.



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


How reproducible:
Not recommended.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

I would like to read any suggestion, what to change now to be able to log into Rawhide.
Comment 1 Casey Dahlin 2010-07-25 14:54:41 EDT
The package shouldn't have significantly changed with the split. Did you install nothing else?
Comment 2 sd.domrep 2010-07-25 15:13:12 EDT
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.
Comment 3 sd.domrep 2010-07-25 15:16:43 EDT
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.
Comment 4 Paul Bolle 2010-07-26 05:56:31 EDT
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.
Comment 5 Petr Lautrbach 2010-07-26 09:00:47 EDT
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
Comment 6 Petr Lautrbach 2010-07-26 09:30:12 EDT
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
Comment 7 Petr Lautrbach 2010-07-26 09:44:24 EDT
#  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
Comment 8 sd.domrep 2010-07-26 11:30:20 EDT
Additional info.
I have managed to successfully log in with kernel boot option: "selinux=0"
Comment 9 sd.domrep 2010-07-26 11:38:06 EDT
So, I think "enforcing=0" turn selinux to permissive state and we can see all AVC.
Comment 10 sd.domrep 2010-07-26 11:58:57 EDT
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.
Comment 11 Bill Nottingham 2010-07-26 13:04:03 EDT
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.
Comment 12 Daniel Walsh 2010-07-26 16:54:18 EDT
Fixed in selinux-policy-3.8.8-6.fc14

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