Hide Forgot
Description of problem:There was a problem with my raid(software) disk.My system went into maintenance, I remounted root in rw mode in maintenance mode. After that I entered init 1, it then went to in runlevel 5. I am confused as in RHEL5.3 when I do the same thing in maintenance mode i:e init 1 for runlevel 1 and it boots fine in runlevel 1, but here its goin in runlevel 5. After logging in the system when i try to do any operation it throws me back on log in screen. This issue is recoverable if i remove raid entry from fstab. My question is why its going in runlevel 5 instead of 1. Version-Release number of selected component (if applicable):RHEL 6.0 How reproducible:Can reproduce it if i make a entry in fstab. Steps to Reproduce: 1.vi /etc/fstab #/dev/md0 /RAID5 ext4 defaults 0 2 2.init 6 3.it goes into maintenance mod while doin e2fsck Actual results:Booting into runlevel 5 after hitting init 1 from maintenance mode. Expected results:Should boot into runlevel 1 from maintenance after hitting init 1. Additional info:This is a test only environment. I thought it is a Bug, so thought of reporting to you.
Filesystem is just package owning system directories and has nothing to do with ext4 filesystem or e2fsck ... Reassigning to e2fsck owner (e2fsprogs), Eric, feel free to reassign to better place if you know one...
My problem is not about e2fsck or ext4, the issue is with system booting into runlevel 5 after hitting init 1 in maintenance mode. I will post you the screenshot after reproducing the issue. Regards, Shrikant Sayankar
Ok, it's not the filesystem package's problem, at any rate ;) I'm not clear on what your issue is, though. An exact sequence of what you did, what you typed, and what the system did, along with relevant system logs, would probably help me understand.
"My system went into maintenance, I remounted root in rw mode in maintenance mode. After that I entered init 1, it then went to in runlevel 5." so something like this? Dropping you into maintenance mode. Hit ctrl-D to exit (sic) # <do stuff> # mount -o remount,rw / # telinit 1 ... and then it went to runlevel 5?
Created attachment 519663 [details] Recreated the issue and attached the screenshot.
Eric, Thank you for the reply. I have recreated the issue and took all the possible screenshots. When you will go through the screenshots you will observe that after hitting init 1 its goint into runlevel 5 and here comes the question why it is going in runlevel 5. Warm Regards, Shrikant Sayankar
Upstart bug perhaps?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
You can see following message when you're entering "maintenance": *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. *** Warning -- SELinux is active *** Disabling security enforcement for system recovery. *** Run 'setenforce 1' to reenable. So the right way here should be edit fstab, leave the shell and add '1' to kernel command line on reboot to get into runlevel 1. Calling 'init 1' in the recovery shell just confuses boot process. Maintenance shell is run by /etc/rc.sysinit which is run by upstart rcS job (/etc/init/rcS.conf). When 'init 1' is called, 'runlevel RUNLEVEL=1' event is sent and rc job (/etc/init/rc.conf) is going to start and also rcS job is going to stop. Stopping rcS job calls 'telinit <default runlevel>' which causes that rc job for runlevel 1 is stopped and rc job for runlevel 5 is going to start.
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
As described in comment 11, this can't be fixed properly -> wontfix