oh **** : did i just lose all my data? - Help

This is a discussion on oh **** : did i just lose all my data? - Help ; 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: oh **** : did i just lose all my data?

  1. oh **** : 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

  2. Re: oh **** : did i just lose all my data?

    Allecs Chime-Ingrae wrote:

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


    Ghu! I hope not.
    The password file is /supposed/ to be on /etc

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


    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)


  3. Re: oh **** : did i just lose all my data?

    In article ,
    Allecs Chime-Ingrae wrote:
    [40GB drive, installer made 2GB partition, not big enough, made additional
    38GB filesysten manually mounted as /usr, login failures]

    > ! apparently the password file was in the /usr directory...


    Nope, /etc . Something else needed at login might be under /usr .

    > 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


    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.

    > 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


    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 ebQenW1@EtaRmpTabYayU.rIr.OcoPm 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.

  4. Re: oh **** : did i just lose all my data?

    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" escribió en el mensaje
    news:_KSpb.705$143.32216@news20.bellglobal.com...
    > Allecs Chime-Ingrae wrote:
    >
    > > 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...

    >
    > Ghu! I hope not.
    > The password file is /supposed/ to be on /etc
    >
    > > 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...

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




  5. Re: oh **** : did i just lose all my data?


    "Allecs Chime-Ingrae" wrote in message
    news:d40777b4.0311041023.3777c452@posting.google.c om...
    > 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


    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.



  6. Re: oh **** : did i just lose all my data?

    In article ,
    eidetic_vilbel@yahoo.fr (Allecs Chime-Ingrae) writes:
    > laugh as you see my stupid newbie manoevers backfire :


    I will

    > 1) my harddrive is 40gb,


    There's an m68k machine with 40gb?

    [...]
    > ps : my distro is redhat 7


    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 -- http://www.debian.org
    Nederlandstalige Linux-documentatie -- http://nl.linux.org
    "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.

  7. Re: oh **** : did i just lose all my data?

    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

  8. Re: oh **** : did i just lose all my data?

    In comp.os.linux.setup Hactar wrote:
    > In article ,
    > Allecs Chime-Ingrae wrote:
    > [40GB drive, installer made 2GB partition, not big enough, made additional
    > 38GB filesysten manually mounted as /usr, login failures]


    >> ! apparently the password file was in the /usr directory...


    > Nope, /etc . Something else needed at login might be under /usr .


    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.

  9. Re: oh **** : did i just lose all my data?


  10. Re: oh **** : did i just lose all my data?

    spike1@freenet.co.uk wrote:

    > In comp.os.linux.setup Hactar wrote:
    >
    >>In article ,
    >>Allecs Chime-Ingrae wrote:
    >>[40GB drive, installer made 2GB partition, not big enough, made additional
    >>38GB filesysten manually mounted as /usr, login failures]

    >
    >
    >>>! apparently the password file was in the /usr directory...

    >
    >
    >>Nope, /etc . Something else needed at login might be under /usr .

    >
    >
    > Which is VERY badly broken in itself.


    Not really. See below.

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


    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)


  11. Re: oh **** : did i just lose all my data?

    In comp.os.linux.misc Lew Pitcher wrote:
    >> 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.


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


    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.

  12. Re: oh **** : did i just lose all my data?

    In article ,
    eidetic_vilbel@yahoo.fr (Allecs Chime-Ingrae) writes:
    > as for the pedantic m68k'er who woke up on the wrong side of the bed :


    Uh, I wasn't trying to be pedantic, only funny

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


    That's nice, but your question didn't handle that.

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


    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.

    > 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 !!


    You should've mentioned that in your post, then. It wasn't clear at
    all.

    > 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


    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 -- http://www.debian.org
    Nederlandstalige Linux-documentatie -- http://nl.linux.org
    "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.

  13. Re: oh **** : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher wrote:
    > spike1@freenet.co.uk wrote:
    > > 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.


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

    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!

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


    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

  14. Re: oh **** : did i just lose all my data?

    P.T. Breuer wrote:
    > In comp.os.linux.help Lew Pitcher wrote:
    >
    >>spike1@freenet.co.uk wrote:
    >>
    >>>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.

    >
    >
    >>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
    manner

    > 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!


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

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

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


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


  15. Re: oh **** : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher wrote:
    > P.T. Breuer wrote:
    > > In comp.os.linux.help Lew Pitcher 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
    > manner


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

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


    Sure.

    > 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?

    > rescue diskettes, and occurs /because/ something is corrupt in your system.


    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.

    > 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!

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


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


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

    > 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


    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!

    > 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


    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!

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


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

    Peter


  16. Re: oh **** : did i just lose all my data?

    P.T. Breuer wrote:
    > In comp.os.linux.help Lew Pitcher wrote:
    >
    >>P.T. Breuer wrote:
    >>
    >>>In comp.os.linux.help Lew Pitcher 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
    >>manner

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


    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:owerfail:/sbin/genpowerfail start
    pg:owerokwait:/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]

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

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

    [snip]

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



    [snip]

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


  17. Re: oh **** : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher wrote:
    > P.T. Breuer wrote:
    > > 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).


    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.

    > 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:owerfail:/sbin/genpowerfail start
    > pg:owerokwait:/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)


    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.

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


    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]

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


    % 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 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

+ Reply to Thread