Professional Web Applications Themes

oh : did i just lose all my data? - Linux Setup, Configuration & Administration

Removed by Administrator...

  1. Moderated Post

    Default oh : did i just lose all my data?

    Removed by Administrator
    Allecs Guest
    Moderated Post

  2. Moderated Post

    Default Re: oh : did i just lose all my data?

    Removed by Administrator
    Lew Guest
    Moderated Post

  3. Moderated Post

    Default Re: oh : did i just lose all my data?

    Removed by Administrator
    Hactar Guest
    Moderated Post

  4. Moderated Post

    Default Re: oh : did i just lose all my data?

    Removed by Administrator
    Bruce Guest
    Moderated Post

  5. Moderated Post

    Default Re: oh : did i just lose all my data?

    Removed by Administrator
    Nico Guest
    Moderated Post

  6. #6

    Default Re: oh : did i just lose all my data?

    In article <google.com>,
    fr (Allecs Chime-Ingrae) writes: 

    I will :)
     

    There's an m68k machine with 40gb?

    [...] 

    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-doentatie -- 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.
    Wouter Guest

  7. #7

    Default 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
    Allecs Guest

  8. #8

    Default Re: oh : did i just lose all my data?

    In comp.os.linux.setup Hactar <are-are.com.unmunge> wrote: 
     [/ref]
     

    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.
    spike1@freenet.co.uk Guest

  9. #9

    Default Re: oh : did i just lose all my data?

    co.uk wrote:
     
    >
    > [/ref]
    >

    >
    >
    > Which is VERY badly broken in itself.[/ref]

    Not really. See below.
     

    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)

    Lew Guest

  10. #10

    Default Re: oh : did i just lose all my data?

    In comp.os.linux.misc Lew Pitcher <com> wrote: [/ref]
     
     

    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.
    spike1@freenet.co.uk Guest

  11. #11

    Default Re: oh : did i just lose all my data?

    In article <google.com>,
    fr (Allecs Chime-Ingrae) writes: 

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

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

    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.
     

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

    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-doentatie -- 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.
    Wouter Guest

  12. #12

    Default Re: oh : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher <com> wrote: [/ref]
     

    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!
     

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

  13. #13

    Default Re: oh : did i just lose all my data?

    P.T. Breuer wrote: [/ref]
    >

    >
    >
    > If that were the case, a kernel alone would match up
    > to YOUR criteria.[/ref]

    Sorry, Peter, but I don't see how you can interpret what I've said in that
    manner
     

    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".
     
    >
    > 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.[/ref]

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

    Lew Guest

  14. #14

    Default Re: oh : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher <ca> wrote: 
    > >
    > > If that were the case, a kernel alone would match up
    > > to YOUR criteria.[/ref][/ref]
     

    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.
     [/ref]
     

    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.
     

    Sure.
     
     

    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?
     

    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.
     

    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!
     [/ref]
     

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

    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!
     

    I think it will run an init.d/mount.sh under all conceivable
    cirstances, 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 OP's problem is opaque to me. I rather think he has been hacked,
    SINCE /bin/login does not work.

    Peter

    P.T. Guest

  15. #15

    Default Re: oh : did i just lose all my data?

    P.T. Breuer wrote: [/ref]
    >

    >
    >
    > 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.
    >
    > [/ref]
    >

    >
    >
    > 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.[/ref]

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

    >

    >
    >
    > 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?[/ref]

    No argument here.

    [snip]
     
    >
    >
    > 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![/ref]

    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.
     [/ref][/ref]


    [snip]
     

    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.

    Lew Guest

  16. #16

    Default Re: oh : did i just lose all my data?

    In comp.os.linux.help Lew Pitcher <ca> wrote: [/ref]
     

    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.
     
     

     
     
     

    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.
     
     

    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]
     [/ref]
     
     
     
     

    % 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
    P.T. Guest

Similar Threads

  1. Will I lose data when upgrading MySQL?
    By bcr07548@creighton.edu in forum MySQL
    Replies: 4
    Last Post: January 14th, 08:30 PM
  2. loadmovie...
    By Sebastian in forum Macromedia Flash Sitedesign
    Replies: 3
    Last Post: June 9th, 01:20 PM
  3. Multiple File Conversion makes FILLED - In Forms lose data
    By Sarah_J_Murphy@adobeforums.com in forum Adobe Acrobat Windows
    Replies: 0
    Last Post: May 17th, 12:17 PM
  4. Flash is really !
    By Pasqual in forum Macromedia Flash Sitedesign
    Replies: 3
    Last Post: January 19th, 03:25 PM
  5. Photo's who looks like
    By Paul in forum Photography
    Replies: 6
    Last Post: September 18th, 09:32 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139