Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

shells and bells

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 => /lib/ (0x4000f000)
        /lib/ => /lib/ (0x40000000)
22:20:06 colossus:~$ ldd /bin/sh => /lib/ (0x4000f000) => /lib/ (0x4003a000) => /lib/ (0x4007a000) => /lib/ (0x4007e000)
        /lib/ => /lib/ (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 (Subject line is ignored).

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /