oh shit : did i just lose all my data?

hello 'nuxers!

i have been using the fine linux os for about a week now. i am really
getting the hang of it and bash is more fun than i ever imagined a
command line could be. (just waiting to get my greedy little brain
around sed and awk.)

just one problem : i have successfully ****ed myself out of being able
to login to my machine.

this is how i did it :
laugh as you see my stupid newbie manoevers backfire :

1) my harddrive is 40gb, but when i installed linux last week it
simply created a 2gb main partition, so once i figured out how to use
fdisk i created a 38gb partition... oh yeah, and i didn't automount
it...

2) this didn't solve the problem of not having enough space on the 2gb
partition... just today i decided to install the aleph programming
language and effectively ran out of room ... so... i decided to move
"/usr" to that 38 gb partition

yep, i should have thought about that one

i didn't see anything wrong with it until i started up my machine

then this happened:

Login: ossk
incorrect

Login: root
incorrect

Login: eat my shorts
incorrect

! apparently the password file was in the /usr directory... ah, yes...

so, the only way to solve this, as i see it, is to mount that 38gb
partition to /usr when everything is starting up. then, breathe a big
sigh of relief

this doesn't seem like it should be too hard... then again...

failing that, i have to reinstall linux and lose the novel i've been
writing for NaNoWriMo (nanowrimo.org) no biggie, but a real pain in
the ass

in any case, a learning experience...

please, help if you can

tanya

ps : my distro is redhat 7

Allecs Chime-Ingrae wrote:
[color=blue]
> hello 'nuxers!
>
> i have been using the fine linux os for about a week now. i am really
> getting the hang of it and bash is more fun than i ever imagined a
> command line could be. (just waiting to get my greedy little brain
> around sed and awk.)
>
> just one problem : i have successfully ****ed myself out of being able
> to login to my machine.
>
> this is how i did it :
> laugh as you see my stupid newbie manoevers backfire :
>
> 1) my harddrive is 40gb, but when i installed linux last week it
> simply created a 2gb main partition, so once i figured out how to use
> fdisk i created a 38gb partition... oh yeah, and i didn't automount
> it...
>
> 2) this didn't solve the problem of not having enough space on the 2gb
> partition... just today i decided to install the aleph programming
> language and effectively ran out of room ... so... i decided to move
> "/usr" to that 38 gb partition
>
> yep, i should have thought about that one
>
> i didn't see anything wrong with it until i started up my machine
>
> then this happened:
>
> Login: ossk
> incorrect
>
> Login: root
> incorrect
>
> Login: eat my shorts
> incorrect
>
> ! apparently the password file was in the /usr directory... ah, yes...[/color]

Ghu! I hope not.
The password file is /supposed/ to be on /etc
[color=blue]
> so, the only way to solve this, as i see it, is to mount that 38gb
> partition to /usr when everything is starting up. then, breathe a big
> sigh of relief
>
> this doesn't seem like it should be too hard... then again...[/color]

Boot from your installation media, but /don't/ reinstall.
Instead, get to a shell as root, mount your primary partition (the one that
would have /etc on it) to (say) /mnt, then fix up the /mnt/etc/fstab so that
the new /usr partition is named and mounted properly.

Save your changes, unmount the partition, and reboot to your installed
linux. If your only problem was an unmounted /usr, then you should be back
in the race.

[snip]

--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

In article <d40777b4.0311041023.3777c452@posting.google.com>,
Allecs Chime-Ingrae <eidetic_vilbel@yahoo.fr> wrote:
[40GB drive, installer made 2GB partition, not big enough, made additional
38GB filesysten manually mounted as /usr, login failures]
[color=blue]
> ! apparently the password file was in the /usr directory...[/color]

Nope, /etc . Something else needed at login might be under /usr .
[color=blue]
> so, the only way to solve this, as i see it, is to mount that 38gb
> partition to /usr when everything is starting up. then, breathe a big
> sigh of relief[/color]

At your bootloader, boot single-user (usually by entering "linux single").
That may present you with a root prompt, or it may ask you for the root
password first, possibly depending on distribution.

Anyhow, edit /etc/fstab and remove "noauto" from the 38GB partition line.

BTW, 2GB (/+/home+/tmp+/var+...) and 38GB /usr is kinda excessive for /usr,
unless you plan to put lots and lots of stuff under /usr and not much
anywhere else.
[color=blue]
> this doesn't seem like it should be too hard... then again...
>
> failing that, i have to reinstall linux and lose the novel i've been
> writing for NaNoWriMo (nanowrimo.org) no biggie, but a real pain in
> the ass[/color]

Back up the important stuff, then repartition. If you have another drive
big enough to hold /usr, it's _possible_ to do it without reinstalling:
mount 2nd drive in temp location, copy /usr to 2nd drive, change fstab to
mount 2nd drive as /usr, umount 1st drive, mount /usr, repartition 1st
drive, format 1st drive partitions, mount new /usr in temp location, copy
backup /usr to new /usr, change fstab to mount new /usr as /usr, switch back.
But it's not for the faint of heart.

Get a good book on Linux.

--
-eben [email]ebQenW1@EtaRmpTabYayU.rIr.OcoP[/email]m home.tampabay.rr.com/hactar

"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.

Redhat 7.. I guess you're using LILO.
With lilo, press control-X to get the text mode, and type
linux init=/bin/bash
that would boot yout linux onto a shell, withouth any special thing.
With grub, it is a little more complicated.. but following the on-screen
instruccionts, you will be able to modify your booting options.

Well..
Once you are on the shell, you must mount the /proc filesystem, and remount
your root filesystem with read-write permissions.
mount -n -t proc /proc /proc
mount -n -o remount rw /
then , login as root (dont need the pass)
su -
and voila, you're root.
IF you cant execute the mount/su commands, use the entire path ... like
/bin/mount -n -o blablabla

The password file, (in redhat) is on /etc. Dont know what happens on your
distro... but "maybe" you had some other login-related-program located on
/usr ... (hope you dont copy it using cp ... cause you loss all the
privileges... one way to do it, is using tar )
Well..
As root, edit your /etc/fstab file
and add your /usr partition to automount.... usually it will look like this

/dev/hda5 / ext2 defaults 1 1
/dev/hda1 /boot ext2 defaults 1 2
/dev/hda6 /home ext2 defaults 1 2
/dev/hda10 /var ext2 defaults 1 2

you could put /usr something like

/dev/hda2 /usr ext2 defaults 1 2
(Assuming your usr is hda2, and using ext2)

If this is the only thing that went wrong... the you just have to reboot (
use the halt, reboot, poweroff cmd, or press crtl-alt-del)
And it must boot fine..

If dont fix your problem, you can contact me by email, msn, irc, and i can
help you on-line.
Ah! dont lose the hope... we alway can recover the data (or at least.. a bit
of it.. in your case, u have lot of ways of recover ALL your data)

Best Regards!


--

Atte
Ivan Barrera
Ivn Systems/Software


"Lew Pitcher" <Lew.Pitcher@td.com> escribió en el mensaje
news:_KSpb.705$143.32216@news20.bellglobal.com...[color=blue]
> Allecs Chime-Ingrae wrote:
>[color=green]
> > hello 'nuxers!
> >
> > i have been using the fine linux os for about a week now. i am really
> > getting the hang of it and bash is more fun than i ever imagined a
> > command line could be. (just waiting to get my greedy little brain
> > around sed and awk.)
> >
> > just one problem : i have successfully ****ed myself out of being able
> > to login to my machine.
> >
> > this is how i did it :
> > laugh as you see my stupid newbie manoevers backfire :
> >
> > 1) my harddrive is 40gb, but when i installed linux last week it
> > simply created a 2gb main partition, so once i figured out how to use
> > fdisk i created a 38gb partition... oh yeah, and i didn't automount
> > it...
> >
> > 2) this didn't solve the problem of not having enough space on the 2gb
> > partition... just today i decided to install the aleph programming
> > language and effectively ran out of room ... so... i decided to move
> > "/usr" to that 38 gb partition
> >
> > yep, i should have thought about that one
> >
> > i didn't see anything wrong with it until i started up my machine
> >
> > then this happened:
> >
> > Login: ossk
> > incorrect
> >
> > Login: root
> > incorrect
> >
> > Login: eat my shorts
> > incorrect
> >
> > ! apparently the password file was in the /usr directory... ah, yes...[/color]
>
> Ghu! I hope not.
> The password file is /supposed/ to be on /etc
>[color=green]
> > so, the only way to solve this, as i see it, is to mount that 38gb
> > partition to /usr when everything is starting up. then, breathe a big
> > sigh of relief
> >
> > this doesn't seem like it should be too hard... then again...[/color]
>
> Boot from your installation media, but /don't/ reinstall.
> Instead, get to a shell as root, mount your primary partition (the one[/color]
that[color=blue]
> would have /etc on it) to (say) /mnt, then fix up the /mnt/etc/fstab so[/color]
that[color=blue]
> the new /usr partition is named and mounted properly.
>
> Save your changes, unmount the partition, and reboot to your installed
> linux. If your only problem was an unmounted /usr, then you should be back
> in the race.
>
> [snip]
>
> --
> Lew Pitcher, IT Consultant, Application Architecture
> Enterprise Technology Solutions, TD Bank Financial Group
>
> (Opinions expressed here are my own, not my employer's)
>[/color]

"Allecs Chime-Ingrae" <eidetic_vilbel@yahoo.fr> wrote in message
news:d40777b4.0311041023.3777c452@posting.google.com...[color=blue]
> hello 'nuxers!
>
> i have been using the fine linux os for about a week now. i am really
> getting the hang of it and bash is more fun than i ever imagined a
> command line could be. (just waiting to get my greedy little brain
> around sed and awk.)
>
> just one problem : i have successfully ****ed myself out of being able
> to login to my machine.
>
> this is how i did it :
> laugh as you see my stupid newbie manoevers backfire :
>
> 1) my harddrive is 40gb, but when i installed linux last week it
> simply created a 2gb main partition, so once i figured out how to use
> fdisk i created a 38gb partition... oh yeah, and i didn't automount
> it...
>
> 2) this didn't solve the problem of not having enough space on the 2gb
> partition... just today i decided to install the aleph programming
> language and effectively ran out of room ... so... i decided to move
> "/usr" to that 38 gb partition
>
> yep, i should have thought about that one
>
> i didn't see anything wrong with it until i started up my machine
>
> then this happened:
>
> Login: ossk
> incorrect
>
> Login: root
> incorrect
>
> Login: eat my shorts
> incorrect
>
> ! apparently the password file was in the /usr directory... ah, yes...
>
> so, the only way to solve this, as i see it, is to mount that 38gb
> partition to /usr when everything is starting up. then, breathe a big
> sigh of relief
>
> this doesn't seem like it should be too hard... then again...
>
> failing that, i have to reinstall linux and lose the novel i've been
> writing for NaNoWriMo (nanowrimo.org) no biggie, but a real pain in
> the ass
>
> in any case, a learning experience...
>
> please, help if you can
>
> tanya
>
> ps : my distro is redhat 7[/color]

Can you boot into "single user mode" by telling your lilo or grub prompt to
use runlevel 1? This would let you edit your /etc/fstab to mount the /usr
partition at boot time.

Otherwise, boot with the CD or installation floppies and type "linux
rescue". Let it mount your Linux "/" partition automatically at
/mnt/sysimage. Then mount the new "/usr" partition at "/mnt/sysimage/usr".
Then edit "/mnt/sysimage/etc/fstab" to match the new locations for things.
You may have to do some tricks with editing "/mnt/sysiamge/etc/mtab" with
tools like "cat" and "grep" and echo" to get a usable mount setup there,
then do a "chroot /mnt/sysimage" to get better editing tools like "emacs"
or "vi".

I don't think your password file was in /usr, but a whole stack of other
critical tools are that are part of the standard login procedure.

In article <d40777b4.0311041023.3777c452@posting.google.com>,
[email]eidetic_vilbel@yahoo.fr[/email] (Allecs Chime-Ingrae) writes:[color=blue]
> laugh as you see my stupid newbie manoevers backfire :[/color]

I will :)
[color=blue]
> 1) my harddrive is 40gb,[/color]

There's an m68k machine with 40gb?

[...][color=blue]
> ps : my distro is redhat 7[/color]

There's a RedHat 7 for m68k machines?

Great.

If not, please choose your newsgroups more carefully next
time. comp.os.linux.m68k is a newsgroup dedicated to (what else) the
m68k range of processors, which was EOLed by Motorola about 10 years
ago.

Followup-To set.

--
Wouter Verhelst
Debian GNU/Linux -- [url]http://www.debian.org[/url]
Nederlandstalige Linux-documentatie -- [url]http://nl.linux.org[/url]
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

thanks for all your help everyone!

with a little ingenuity i have managed to sort things out

only problem -- i mounted /dev/hda3 in readonly mode originally
i didn't know you could "remount -rw" until reading the man page
(should have done that first)

so when i rebooted things in frustration there was a dirty unmount!
(since mtab could not be changed)
now e2fscking ... quite a few bad blocks it looks like ...
but i'm learning ...

the thing i love about linux is that every move you make
invariably involves you learning something about your system

as for the pedantic m68k'er who woke up on the wrong side of the bed :

*ahem*

in coming weeks i plan to install linux on my mac lc550

since you seem to relish your knowledge of the 68k you must know this
was one of the last 68k macs (produced in 1996 i believe -- that would
be two years later than you say they were EOL'ed ... maybe you don't
know everything ?)
and generally rare since it was sold mainly to schools

i have been scared to put linux on my lc precisely because i don't
want to mess anything up -- as i thought i had yesterday

cross-posting , i thought , might give me some relevant information
as to how to go about troubleshooting any coming problems
in the case that the same thing did arise on my macintosh !!

so i did have a reason for cross-posting , you grinch !!

i know this is usenet ,
but why don't you watch it next time you get all huffy

thanks everyone

if linux succeeds ,
it will be because there are so many nice people using it !!

tanya

In comp.os.linux.setup Hactar <ebenONE@tampabay.are-are.com.unmunge> wrote:[color=blue]
> In article <d40777b4.0311041023.3777c452@posting.google.com>,
> Allecs Chime-Ingrae <eidetic_vilbel@yahoo.fr> wrote:
> [40GB drive, installer made 2GB partition, not big enough, made additional
> 38GB filesysten manually mounted as /usr, login failures][/color]
[color=blue][color=green]
>> ! apparently the password file was in the /usr directory...[/color][/color]
[color=blue]
> Nope, /etc . Something else needed at login might be under /usr .[/color]

Which is VERY badly broken in itself.
the whole point of /usr is that nothing on it should be required to boot the
machine. Everything that's required should be under /etc, /sbin, /bin and
/dev.

[url]http://hubcap.clemson.edu/~hubcap/d.weekly/dangerous.html[/url]

-Mike <g>

[email]spike1@freenet.co.uk[/email] wrote:
[color=blue]
> In comp.os.linux.setup Hactar <ebenONE@tampabay.are-are.com.unmunge> wrote:
>[color=green]
>>In article <d40777b4.0311041023.3777c452@posting.google.com>,
>>Allecs Chime-Ingrae <eidetic_vilbel@yahoo.fr> wrote:
>>[40GB drive, installer made 2GB partition, not big enough, made additional
>>38GB filesysten manually mounted as /usr, login failures][/color]
>
>[color=green][color=darkred]
>>>! apparently the password file was in the /usr directory...[/color][/color]
>
>[color=green]
>>Nope, /etc . Something else needed at login might be under /usr .[/color]
>
>
> Which is VERY badly broken in itself.[/color]

Not really. See below.
[color=blue]
> the whole point of /usr is that nothing on it should be required to boot the
> machine. Everything that's required should be under /etc, /sbin, /bin and
> /dev.[/color]

Presumably, once the system is ready to accept logins, it can no longer be
considered as "booting".

The OP's problem came at login time, not at boot time, and by login time,
/usr can (and probably should) be available.




--
Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

In comp.os.linux.misc Lew Pitcher <Lew.Pitcher@td.com> wrote:[color=blue][color=green]
>> the whole point of /usr is that nothing on it should be required to boot the
>> machine. Everything that's required should be under /etc, /sbin, /bin and
>> /dev.[/color][/color]
[color=blue]
> Presumably, once the system is ready to accept logins, it can no longer be
> considered as "booting".[/color]
[color=blue]
> The OP's problem came at login time, not at boot time, and by login time,
> /usr can (and probably should) be available.[/color]

Yes... But there should still be nothing in /usr that'll get in the way of a
simple getty/login prompt. All the stuff like pam, shadow, etc should be in
the root partition so you CAN get into the system to fix things if /usr
fails. OK, you lose a lot of functionality, but you should be able to at
least log in and edit text files.

In article <d40777b4.0311050655.22b50c36@posting.google.com>,
[email]eidetic_vilbel@yahoo.fr[/email] (Allecs Chime-Ingrae) writes:[color=blue]
> as for the pedantic m68k'er who woke up on the wrong side of the bed :[/color]

Uh, I wasn't trying to be pedantic, only funny :)
[color=blue]
> *ahem*
>
> in coming weeks i plan to install linux on my mac lc550[/color]

That's nice, but your question didn't handle that.
[color=blue]
> since you seem to relish your knowledge of the 68k you must know this
> was one of the last 68k macs (produced in 1996 i believe -- that would
> be two years later than you say they were EOL'ed ... maybe you don't
> know everything ?)[/color]

I didn't claim knowledge. I said `about 10 years ago', meaning, I
don't know exactly at what time they were EOLed, but it was about at
the time I specified.
[color=blue]
> and generally rare since it was sold mainly to schools
>
> i have been scared to put linux on my lc precisely because i don't
> want to mess anything up -- as i thought i had yesterday
>
> cross-posting , i thought , might give me some relevant information
> as to how to go about troubleshooting any coming problems
> in the case that the same thing did arise on my macintosh !![/color]

You should've mentioned that in your post, then. It wasn't clear at
all.
[color=blue]
> so i did have a reason for cross-posting , you grinch !!
>
> i know this is usenet ,
> but why don't you watch it next time you get all huffy[/color]

You shouldn't assume I'm getting fed up because of a single post. My
skull is a little thicker than that :-)

--
Wouter Verhelst
Debian GNU/Linux -- [url]http://www.debian.org[/url]
Nederlandstalige Linux-documentatie -- [url]http://nl.linux.org[/url]
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

In comp.os.linux.help Lew Pitcher <Lew.Pitcher@td.com> wrote:[color=blue]
> [email]spike1@freenet.co.uk[/email] wrote:[color=green]
> > the whole point of /usr is that nothing on it should be required to boot the
> > machine. Everything that's required should be under /etc, /sbin, /bin and
> > /dev.[/color][/color]
[color=blue]
> Presumably, once the system is ready to accept logins, it can no longer be
> considered as "booting".[/color]

If that were the case, a kernel alone would match up
to YOUR criteria.

No - boot means start booting and finsih booting and leave you in a
working state - which is one in which you can at least log in!
[color=blue]
> The OP's problem came at login time, not at boot time, and by login time,
> /usr can (and probably should) be available.[/color]

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
in /lib.


Peter

P.T. Breuer wrote:[color=blue]
> In comp.os.linux.help Lew Pitcher <Lew.Pitcher@td.com> wrote:
>[color=green]
>>spike1@freenet.co.uk wrote:
>>[color=darkred]
>>>the whole point of /usr is that nothing on it should be required to boot the
>>>machine. Everything that's required should be under /etc, /sbin, /bin and
>>>/dev.[/color][/color]
>
>[color=green]
>>Presumably, once the system is ready to accept logins, it can no longer be
>>considered as "booting".[/color]
>
>
> If that were the case, a kernel alone would match up
> to YOUR criteria.[/color]

Sorry, Peter, but I don't see how you can interpret what I've said in that
manner
[color=blue]
> No - boot means start booting and finsih booting and leave you in a
> working state - which is one in which you can at least log in![/color]

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)
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
rescue diskettes, and occurs /because/ something is corrupt in your system.

I stand by my statement: Presumably, once the system is ready to accept
logins, it can no longer be considered as "booting".
[color=blue][color=green]
>>The OP's problem came at login time, not at boot time, and by login time,
>>/usr can (and probably should) be available.[/color]
>
> 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
> in /lib.[/color]

That's the point. The /OP/ said that the error he encountered /at login/
indicated that the login process required something on /usr that was not
available.

My point was that, by the time that the OP gets a login prompt, /usr (and
it's contents) /should/ be available, having been made available as part of
the "boot" process that precedes this state. I'll grant that, in
/exceptional/ circumstances (like booting into "single user" mode), the boot
may not leave /usr mounted (it depends on the settings in /etc/inittab and
the rc scripts used to transition to the "single user" runlevel 1 state),
but the OP didn't indicate that he took any special steps to achieve his
problem.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 ([url]http://counter.li.org/[/url])
Slackware - Because I know what I'm doing.

In comp.os.linux.help Lew Pitcher <lpitcher@sympatico.ca> wrote:[color=blue]
> P.T. Breuer wrote:[color=green]
> > In comp.os.linux.help Lew Pitcher <Lew.Pitcher@td.com> wrote:[color=darkred]
> >>Presumably, once the system is ready to accept logins, it can no longer be
> >>considered as "booting".[/color]
> >
> > If that were the case, a kernel alone would match up
> > to YOUR criteria.[/color][/color]
[color=blue]
> Sorry, Peter, but I don't see how you can interpret what I've said in that
> manner[/color]

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.
[color=blue][color=green]
> > 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![/color][/color]
[color=blue]
> 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)[/color]

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"
here.

Anyway, never mind. Yes, this init wants to get to runlevel 2 to start
a getty. I presume that in runlevel S, the initrc script (or whatever)
will set up a login prompt on its own.

However - and this is the point - getting to level 2 or any level
without /usr mounted will work (will have some daemon failures for
/usr/sbin) to deliver you a working login prompt, whenever it so happens
that getty's are started.
[color=blue]
> 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".[/color]

Sure.
[color=blue]
> 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.[/color]
[color=blue]
> 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[/color]

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?
[color=blue]
> rescue diskettes, and occurs /because/ something is corrupt in your system.[/color]

The FSH says:

The contents of the root filesystem must be adequate to boot, restore,
recover, and/or repair the system.

* To boot a system, enough must be present on the root partition to
mount other filesystems. This includes utilities, configuration,
boot loader information, and other essential start-up data. /usr,
/opt, and /var are designed such that they may be located on
other partitions or filesystems.
* To enable recovery and/or repair of a system, those utilities
needed by an experienced maintainer to diagnose and reconstruct a
damaged system must be present on the root filesystem.
* To restore a system, those utilities needed to restore from system
backups (on floppy, tape, etc.) must be present on the root
filesystem.

Now, since to "recover and/or repair" the system, you must have logged
in (module init=/bin/sh), I submit that a working login prompt is at
least implied to be expected.

BUT - I agree with you that the system may have a failsafe mode that
brings up a login prompt without a getty, so we get no guarantee that if
you get a login prompt from a getty, then it will be a working one (in
the absence of /usr).

However, experience and common expectation are that if you get a getty
login prompt, it will work in the absence of /usr, whether it is the
designed recovery and repair login mode or not. And logic finds nothing
missing for getty and login when /usr is absent.
[color=blue]
> I stand by my statement: Presumably, once the system is ready to accept
> logins, it can no longer be considered as "booting".[/color]

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!
[color=blue][color=green]
> > 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
> > in /lib.[/color][/color]
[color=blue]
> That's the point. The /OP/ said that the error he encountered /at login/
> indicated that the login process required something on /usr that was not
> available.[/color]

Well, the only thing he is likely to be missing is a shell located on
/usr/bin instead of in /bin. I recall that RH used to make such a
mistake with tcsh? However, that would not affect root, who uses
/bin/sh as his shell.

So if root can't log in without /usr, then something in /bin/login is
FUBAR. A remote possibility is /usr/bin/loadkeys, but failures to map
keyboards away from the default should not be deadly (and happen on
boot, not at login).
[color=blue]
> My point was that, by the time that the OP gets a login prompt, /usr (and
> it's contents) /should/ be available, having been made available as part of[/color]

They should be available, but in case they are not, the FSH requires
that everything be present on / that could normally be needed to repair
and recover the system. I submit that that implies that you can login
in order to use them!
[color=blue]
> the "boot" process that precedes this state. I'll grant that, in
> /exceptional/ circumstances (like booting into "single user" mode), the boot
> may not leave /usr mounted (it depends on the settings in /etc/inittab and[/color]

I think it will run an init.d/mount.sh under all conceivable
circumstances, but failures there should not be deadly, and should
leave you in a state where you can repair and recover the system from
/ alone. Which includes a login!
[color=blue]
> the rc scripts used to transition to the "single user" runlevel 1 state),
> but the OP didn't indicate that he took any special steps to achieve his
> problem.[/color]

THe OP's problem is opaque to me. I rather think he has been hacked,
SINCE /bin/login does not work.

Peter

P.T. Breuer wrote:[color=blue]
> In comp.os.linux.help Lew Pitcher <lpitcher@sympatico.ca> wrote:
>[color=green]
>>P.T. Breuer wrote:
>>[color=darkred]
>>>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.[/color][/color]
>
>[color=green]
>>Sorry, Peter, but I don't see how you can interpret what I've said in that
>>manner[/color]
>
>
> 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.
>
>[color=green][color=darkred]
>>>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![/color][/color]
>
>[color=green]
>>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)[/color]
>
>
> 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"
> here.[/color]

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)....

id:4:initdefault:
si:S:sysinit:/etc/rc.d/rc.S
su:1S:wait:/etc/rc.d/rc.K
rc:2345:wait:/etc/rc.d/rc.M
ca::ctrlaltdel:/sbin/shutdown -t5 -r now
l0:0:wait:/etc/rc.d/rc.0
l6:6:wait:/etc/rc.d/rc.6
pf::powerfail:/sbin/genpowerfail start
pg::powerokwait:/sbin/genpowerfail stop
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
x1:4:wait:/etc/rc.d/rc.4


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
/in order/.

[snip]
[color=blue][color=green]
>>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".[/color]
>
>
> Sure.
>
>[color=green]
>>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.[/color]
>
>[color=green]
>>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[/color]
>
>
> 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?[/color]

No argument here.

[snip]
[color=blue][color=green]
>>I stand by my statement: Presumably, once the system is ready to accept
>>logins, it can no longer be considered as "booting".[/color]
>
>
> 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![/color]

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.
[color=blue][color=green][color=darkred]
>>>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
>>>in /lib.[/color][/color][/color]


[snip]
[color=blue]
> THe OP's problem is opaque to me. I rather think he has been hacked,
> SINCE /bin/login does not work.[/color]

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
/usr/share/locale
Can't execute /usr/bin/passwd
PATH=/bin:/usr/bin

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 ([url]http://counter.li.org/[/url])
Slackware - Because I know what I'm doing.

In comp.os.linux.help Lew Pitcher <lpitcher@sympatico.ca> wrote:[color=blue]
> P.T. Breuer wrote:[color=green]
> > 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"[/color][/color]
[color=blue]
> Then you don't understand how init and /etc/inittab work (or perhaps you do,
> because you've taken those lines out of context).[/color]

Mmm .. this is rather observant of you. I'm not going to look, but I
assume my inittab also starts and finishes rc.M in the rc state before
starting the getties.
[color=blue]
> Here's a bit better image (comments removed for this illustration)....[/color]
[color=blue]
> id:4:initdefault:
> si:S:sysinit:/etc/rc.d/rc.S
> su:1S:wait:/etc/rc.d/rc.K
> rc:2345:wait:/etc/rc.d/rc.M
> ca::ctrlaltdel:/sbin/shutdown -t5 -r now
> l0:0:wait:/etc/rc.d/rc.0
> l6:6:wait:/etc/rc.d/rc.6
> pf::powerfail:/sbin/genpowerfail start
> pg::powerokwait:/sbin/genpowerfail stop
> 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
> x1:4:wait:/etc/rc.d/rc.4[/color]

[color=blue]
> 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.[/color]
[color=blue]
> Thus, when booting /this/ inittab, the steps are:[/color]
[color=blue]
> 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)[/color]

My point was only meant to be the rather unobservant observation that
the getties are one of plenty of things started asynchronously when
one reaches any of a number of runlevels, so there is a race condition
for last, and no definite statement about who it is.
[color=blue]
> /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[/color]
[color=blue]
> Technically, "boot" is complete when init completes all the "sysinit" steps
> /in order/.[/color]

You know, that's almost fair! I would also say that the entries in
inittab for that runlevel should start as well, but clearly they may or
may not be successfully started, without anyone caring overmuch either
way.

[snip]
[color=blue][color=green]
> > THe OP's problem is opaque to me. I rather think he has been hacked,
> > SINCE /bin/login does not work.[/color][/color]
[color=blue]
> FWIW, I can guarantee that my system /isn't/ "hacked", but take a look at
> the results below...[/color]
[color=blue]
> bash-2.05b$ strings /bin/login | grep /usr
> /usr/share/locale
> Can't execute /usr/bin/passwd
> PATH=/bin:/usr/bin[/color]
[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]

% strings /bin/login | grep /usr
/usr/share/locale
PATH=/bin:/usr/bin

(debian potato).

% strings /bin/login | grep /usr
/usr/local/bin:/bin:/usr/bin
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin
%

(slackware 3.0).

apt-getting the source for login (unstable). There is no explicit ref
to /usr in the sources, apart from:

login.c: * Wait a while (a la SVR4 /usr/bin/login) before attempting
su.c: addenv (cp ? cp : "PATH=/bin:/usr/bin", NULL);
su.c: addenv ("PATH=/bin:/usr/bin", NULL);

Yo ho ho ... let's make it ... gah ... excuse me while I mod this unstable
gunk build so it will compile here ... this is torture ... fine.
Someone should lart the person who complicated that build. There's
a $(MKINSTALLDIRS)/$(mkinstalldirs) inversion in po/Makefile.* too.
And a (unimportant) missing #include <signal.h> in newgrp.c. Anyway ...

/tmp/shadow-4.0.3% strings debian/login/bin/login | grep /usr
/usr/share/locale
PATH=/bin:/usr/bin
/tmp/shadow-4.0.3%

So where did that come from? Oh - the Makefile:

-DLOCALEDIR=\"$(datadir)/locale

../src/login.c: bindtextdomain (PACKAGE, LOCALEDIR);
../src/login.c: bindtextdomain (PACKAGE, LOCALEDIR);

/*
* Some quick initialization.
*/

sanitize_env ();

setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);

initenv ();

Wonderful - they duplicate libc functions (just as well, I don't have
them).

/* Specify that the DOMAINNAME message catalog will be found
in DIRNAME rather than in the system locale data base. */
char *
BINDTEXTDOMAIN (domainname, dirname)
const char *domainname;
const char *dirname;
{
set_binding_values (domainname, &dirname, NULL);
return (char *) dirname;
}

so correct me if I am wrong, but this call was unneeded, since the
messages ARE in te system locale data base.

Gah. The source should maybe have something like

#if ! USE_STANDARD_LOCALE

around the call to bindtextdomain. If that wouldn't introduce too many
compile paths. Still, it is silly.

It's where it looks up message translations.



Peter