shells and bells

[Mike Bilow]

Linux can specify an alternative replacement for the init process if you
are hosed to this extent: just run /bin/sh or /bin/bash instead of init.

Note that /lib should be available if /bin is available, and that it is
not necessary or expected that init and sh should be statically linked:

22:20:03 colossus:~$ ldd /sbin/init
        libc.so.6 => /lib/libc.so.6 (0x4000f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
22:20:06 colossus:~$ ldd /bin/sh
        libreadline.so.2 => /lib/libreadline.so.2 (0x4000f000)
        libncurses.so.4 => /lib/libncurses.so.4 (0x4003a000)
        libdl.so.2 => /lib/libdl.so.2 (0x4007a000)
        libc.so.6 => /lib/libc.so.6 (0x4007e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

If even this does not allow booting, then you resort to floppies.

-- Mike


On 2000-05-03 at 20:45 -0400, Derek Martin wrote:

> This often presented a problem on older platforms if you changed root's
> shell to say, csh, and there was a problem with the usr partition.  init
> would try to start root's shell, and be unable to, making the system
> essentially unbootable.  
> 
> I think most of the vendors have worked this out now by simply having init
> spawn a statically linked version of sh rather than checking to see what
> root's shell was, but HP-UX may be an exception.  I can't remember.


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).