This affects all versions of initscripts. No, this is _not_ a util-linux
(aka sulogin) bug.
When something wrong in /etc/rc.d/rc.sysinit (like unable to mount
filesystem(s), unable to start raid etc etc), rc.sysinit calls
sulogin and reboot after that. Among the inconsistent messages
(rc.sysinit says that system will reboot, sulogin says "press ^D for
normal startup), that just should NOT happen. System should NOT
reboot in this case (if user wants to reboot it, he can issue
halt/shutdown manually from sulogin's shell). I just don't know
why redhat placed that reboots in rc.sysinit. If user can correct
a problem, system can continue to boot. Moreover, it is not fatal
if failure occured during some operations, _especially_ when
single boot was wanted.
For up to now, there was no problem for me, just an annoyance.
But now I have strange situation. My sulogin by some reason
wan't to check password (it says "login incorrect" each time).
This is not a bug in sulogin but probably a my fault, but does
not matter here. Ok, now I have just unusable system that can
be repaired using rescue disk or by plugging harddrives to
another machine. But the only problem I have is an extra raid
partition on another two disks that I forget to clear when removed
that disks (that was just an experiment with raid; I put two
more disks and set up a raid partition on them; after that I
turned off the machine and removed the disks; and now I can't boot,
and that disks also unavailable).
Ok, I'm able to resolve the problem. That will cost me some time
at evening, as I need to plug the disks to another machine that is
busy at worktime, and also I need to find appropriate scsi wires
(or even maybe to move scsi controller to that machine too). But
just after that I will remove those ugly and _stupid_ (yes) reboots
from /etc/rc.d/rc.sysinits. And the same I propose to Redhat.
BTW, some time ago I always removed that reboots, but after some
upgrades that was enouth -- it is a pain to edit rc.sysinit after
every upgrade on every machine.
The rc.sysinit is a big one now, with many optional "services" started from
it. Why not use init.d scripts for that services, with low ordered numbers?
Want to initialize usb -- ok, run init.d/usb; raid -- ok, init.d/raid;
want to mount filesystems -- fine, init.d/mountfs. Place them in appropriate
order, and that's all. Why not put all the init.d/* to rc.sysinit after
all?! :) With current rc.sysinit style, last possibility seemed to be
With rc.sysinit split there will be easier to repair the system, at least
to see if the failed component of it can be started next time
(for my situation, when I got a shell prompt, I would like to issue something
like 'service raid start' to check if my raid will start next boot; when
I remove reboot from sysinit, that will be my real step before hitting
^D at sulogin shell).
And also -- I know at least one possible cause of calling reboot. It is a
stupid/beginner user that aren't able to start appropriate service
(see above also). With this, that may be really better to not to allow
system to boot further. But I can't just agree with this.
Ok, if this is a case (i.e. reboot to save a beginner user from seeng tons
of error messages), than I can suggest at least to have some flag (e.g.
/noreboot file) to serve as reboot stopper. But probably this is also
not a solution (at least if this flag will be removed), since root can
be read-only at this stage. But the best solution will be just to remove
reboot completely. Error messages are not a big issue...
What do you think about this:
o have a directory, say, /etc/rc.d/sysinit.d,
similar to rc[0-9].d. This directory should be
processed by rc.sysinit the same way that other
rc\d.d processed by rc (note that sysinit.d combines
init.d that does not processed by any script _and_
rc[0-9].d that gives an order of executions).
The only exception to rc?.d is that rc.sysinit checks
return value from each sysinit.d/* script and
executes the following sequence if that return != 0:
ask "reboot? [Y/n]"
reboot IF answer was yes
It (rc.sysinit) should remember all entries from sysinit.d
before an error occured, and on reboot it should execute
them in reverse order (with argument 'stop').
o place usb, raid, filesystem checks, hdparm tuning etc to that
sysinit.d directory in appropriate order, and make that scripts
parts of corresponding package (raid for raidtools for example).
Seemed to be appropriate.
And oh yes, I found why my sulogin wan't to execute shell.
In bash-2.04-8, there are lines in /etc/bashrc:
# Don't do anything if /usr is not mounted (i.e. /usr is a separate
# partition and we're run by fsck)
[ -d /usr/bin ] || exit 0
Here, /usr is not mounted, so bash just exited... This bug was corrected
in new bash package.
Hey, you had the pinstripe bash package installed. ;)
Yes, we're looking at reorganizing rc.sysinit. Marking this
as an enhancement request for now.
This isn't an enhancement really. I said about a bug (I considered it
so, may be I'm wrong) in rc.sysinit -- it should not reboot the system
in case of some trouble, or at least it should provide an option to prevent
this reboot. This is _not_ an enhancement request. And I doesn't understand
_why_ it reboots? (I already have one possible answer above, but still not
shure). At least all other unices that I've seen does not have this reboot.
Sulogin asks for a password, and after that system continued boot process.
Yes, there may be a lot of error messages, many services can be not started
etc, but system may come to some useful state. The unices that I told about
here are solaris, hpux and sco.
The rest was about a ways of resolving that bug, together with some other
But let's go with "enhancement" state if you like so. The only thing
that I should remember from now on is that I need to download the _source_
rpm for initscripts and remove that reboots before it builds if I will need
to upgrade it... :(
BTW, what's "pinstripe"? I know that this was some prerelease, but don't
remember the release number... Is that was 6.2?
Pinstripe was the 7.0 beta. The bash package from it had
After discussions with people here, this won't be done.
The reboot is there to make sure that all FS structures are completely
re-read in cases of *massive* filesystem changes; we've had people have
corruption happen before when they didn't reboot.