Re: oh shit : did i just lose all my data?
From: Lew Pitcher (lpitcher_at_sympatico.ca)
Date: Tue, 11 Nov 2003 22:59:19 -0500
P.T. Breuer wrote:
> In comp.os.linux.help Lew Pitcher <firstname.lastname@example.org> wrote:
>>P.T. Breuer wrote:
>>>In comp.os.linux.help Lew Pitcher <Lew.Pitcher@td.com> wrote:
>>>>Presumably, once the system is ready to accept logins, it can no longer be
>>>>considered as "booting".
>>>If that were the case, a kernel alone would match up
>>>to YOUR criteria.
>>Sorry, Peter, but I don't see how you can interpret what I've said in that
> I seem to have been interpreting what you said later, which I thought
> meant that (according to you), login stuff was NOT required to be on /
> as opposed to /usr.
>>>No - boot means start booting and finish booting and leave you in a
>>>working state - which is one in which you can at least log in!
>>I look through my Slackware setup, and the /last/ thing done in the setup
>>scripts is the start of the UI (agetty and/or X)
> Well, getty should be run from init (inittab), and inittab should
> start a getty in practically every run level. I have
> 1:2345:respawn:/sbin/getty 38400 tty1
> 2:234:respawn:/sbin/getty 38400 tty2
> 3:234:respawn:/sbin/getty 38400 tty3
> 4:234:respawn:/sbin/getty 38400 tty4
> 5:234:respawn:/sbin/getty 38400 tty5
> plus the serial console :-). So I don't think one can say it's "last"
Then you don't understand how init and /etc/inittab work (or perhaps you do,
because you've taken those lines out of context).
Here's a bit better image (comments removed for this illustration)....
ca::ctrlaltdel:/sbin/shutdown -t5 -r now
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
c2:1235:respawn:/sbin/agetty 38400 tty2 linux
c3:1235:respawn:/sbin/agetty 38400 tty3 linux
c4:1235:respawn:/sbin/agetty 38400 tty4 linux
c5:1235:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
When transitioning from one runstate to another, init processes inittab
sequentially, running each entry that matches the new runstate in turn. The
"wait" entries cause init to wait until the launched process completes, the
"respawn" entries cause init to launch and continue, but relaunch when the
process completes. The "sysinit" entries are run once, before transition to
the default runstate, which is specified by the "initdefault" line.
Thus, when booting /this/ inittab, the steps are:
wait for si (/etc/rc.d/rc.S) to complete,
wait for rc (/etc/rc.d/rc.M) to complete (initdefault runstate aka state 4)
launch/respawn c6 (/sbin/agetty)
wait for x1 (/etc/rc.d/rc.4)
/etc/rc.d/rc.S runs the startup (or boot) scripts
/etc/rc.d/rc.M runs the multiuser scripts
/sbin/agetty is the console agetty
/etc/rc.d/rc.4 runs the xdm/kdm/gdm launch scripts
Technically, "boot" is complete when init completes all the "sysinit" steps
>>All the preparation (including filesystem mounts and daemon startups) are
>>done *before* the user is given a login prompt. Once the system is ready to
>>accept logins, all the setup has already been done, and the system can no
>>longer be considered to be "booting".
>>I'd take "booting" to include /at least/ the "sysinit" state transition, but
>>also the transition to singleuser or multiuser runstate (as selected by the
>>initdefault value of /etc/inittab. Once those states have been processed, I
>>grant that "booting" has completed.
>>Having said that, there's no guarantee that, once out of the "booting"
>>stage, your system will be stable enough to log on to. That's the /why/ of
> If corruption is a possibility, there's no guarrantee of anything anyway.
> But booting to a prompt with no /usr is normal design. What would not
> work about /sbin/getty and /bin/login?
No argument here.
>>I stand by my statement: Presumably, once the system is ready to accept
>>logins, it can no longer be considered as "booting".
> True, but that's not at issue. The system must BOOT in the absence of
> /usr, and that means getting to a stage where it has finished booting.
> This is normally also a stage where it offers you a login prompt (c.f.
> my inittab, which will offer a getty in run levels 2-5). What's more,
> the LFSH standard says that the system must be so arranged that in the
> absence of /usr, you can expect to be in a state where you can repair
> and recover the rest of the system - and I submit that "login" must
> be expected to be available and working in such a situation!
Again, no argument. I'm surprised that the OP had a problem logging on with
a missing /usr. However, despite my surprise, he /did/ have a problem
logging on with a missing /usr.
>>>Boot with no /usr and you will be able to login. /bin/login is
>>>not on /usr. Nor is /bin/getty. /bin/login is not linked to any lib
>>>apart from ones in /lib. libpam is the only dubious thing. And it's all
> THe OP's problem is opaque to me. I rather think he has been hacked,
> SINCE /bin/login does not work.
FWIW, I can guarantee that my system /isn't/ "hacked", but take a look at
the results below...
bash-2.05b$ strings /bin/login | grep /usr
Can't execute /usr/bin/passwd
Apparently /usr/share/locale and /usr/bin/passwd are named by the /bin/login
program. Inspection of the source code might be in order, but my /guess/ is
that their use is conditional, and that the OP's problem situation left his
system in a state where these conditions were satisfied, even if
/usr/share/locale and/or /usr/bin/passwd were not available.
Tell me, what does your system show in the way of "strings" in /bin/login?
I'm curious to know what code the other distro's versions execute.
-- Lew Pitcher Master Codewright and JOAT-in-training Registered Linux User #112576 (http://counter.li.org/) Slackware - Because I know what I'm doing.