Very Computer

   We just got an IBM RISC 6000 530H and while browsing with it
for the first time I changed the shell command for the root in the
/etc/passwd file. From ksh to csh. However, when I now try to
login as root the machine comes up with the following error
message:

3004-009 Failed running loging shell

and throws me back to the login prompt again. There're no new
users set-up in the system and I tried to login as sys, adm
or lp with no success. I know the machine can be set to single-user
mode however I don't know how to get into that mode whitout shutting
down the system. And to shutdown the system I have to login as root :-(
      Maybe there's a way to reboot the machine into single-user
mode or get into the prom somehow but the manuals don't say anything
about it and I already browsed through the whole info dbase ( available
on another RISC system we have) finding nothing that can give me a clue
to solve this problem.

Can anybody help ?

Thanks in advance for any reply,

Luigi Manna--

Los Angeles, California.

You probably have an incorrect path to csh specified, or a typo. Note
that specifying a shell that is not in the "/" filesystem can cause
identical problems on system recovery. .... if "/usr" is not mounted
then /usr/bin/SHELL will not run. This can easily happen thusly:

$ ls -l /bin/csh
lrwxr-xr-x  1 root           14 Apr 22 20:31 /bin/csh -> ../usr/bin/csh

As you can see "/bin/csh" does not really exist on this OS (Ultrix 4.2A)
and would cause great trouble if I were to specify it as the root shell.
Unless , I copied it over to /bin and made it real.

Quote:>and throws me back to the login prompt again. There're no new
>users set-up in the system and I tried to login as sys, adm
>or lp with no success. I know the machine can be set to single-user
>mode however I don't know how to get into that mode whitout shutting
>down the system. And to shutdown the system I have to login as root :-(
>      Maybe there's a way to reboot the machine into single-user
>mode or get into the prom somehow but the manuals don't say anything
>about it and I already browsed through the whole info dbase ( available
>on another RISC system we have) finding nothing that can give me a clue
>to solve this problem.

>Can anybody help ?

As per my above comments.... you might be hosed even if you power down
and power up in single user mode. Before trying that, get responses
from AIX wizzes here on the net and/or (!!) call IBM support as they
have probably seen this one before  (-:

--
*****************************************************************************
*                                                                           *
*  Charles Richmond     International Integrated Systems Corporation        *
*  One Longfellow Place Suite 3309 , Boston , Ma. USA 02114-2431            *

Since this is a new machine, make sure you have bosext1 installed.
Without it, there is no csh shell.

Charlie McGuire
Computer Science Dept.
The University of Montana

As Charlie says, the problem is you changed root to use csh before you
installed csh.  I STRONGLY recommend that root run ksh, even if everyone
on the system uses csh.  All the systems admin stuff IBM provides "should"
work in either environment, but in practice are used in ksh 95%+ of time.
Guess which is better tested.

Now, you need to reboot the machine from your installation media (tape,
diskettes), start a "limited function maintenance shell",
getrootfs hdisk0 (or whichever hdiskn you installed AIX on), and change
the root userid to use ksh.  chsh will probably work after the getrootfs;
if not, vi /etc/passwd (remembering to first say TERM=hft;export TERM)
and change the "/bin/csh" to "/bin/ksh".

You note that you can't shut it down first.  Right.  Just push the    
Big Yellow-Orange Button (BYOB to us IBM-types) twice after putting the
key in maintenance mode.  If that won't make it reboot, there's always
the power switch.  Sometimes you have to show these machines who's boss!
--

IBM Champaign

|>
|>    We just got an IBM RISC 6000 530H and while browsing with it
|> for the first time I changed the shell command for the root in the
|> /etc/passwd file. From ksh to csh. However, when I now try to
|> login as root the machine comes up with the following error
|> message:
|>
|> 3004-009 Failed running loging shell
|>
|> and throws me back to the login prompt again. There're no new
|> users set-up in the system and I tried to login as sys, adm
|> or lp with no success. I know the machine can be set to single-user
|> mode however I don't know how to get into that mode whitout shutting
|> down the system. And to shutdown the system I have to login as root :-(

I'm sorry but I don't have a solution off the top of my head for your problem.
In fact I am quite suprised because we have changed the login shell for root
on AIX systems around here. However, I want to give you a warning on using
anything other than ksh for the login shell for root. It turns out that
in several cases when you use smit, it assumes that you are running ksh. If you
aren't the action fails (this was true in AIX 3.1.5, they may have fixed
it in AIX 3.2.)
--
Matt Wicks
Fermi National Accelerator Laboratory

708-840-8083

|> >   We just got an IBM RISC 6000 530H and while browsing with it
|> >for the first time I changed the shell command for the root in the
|> >/etc/passwd file. From ksh to csh. However, when I now try to
|> >login as root the machine comes up with the following error
|> >message:
|> >
|> >3004-009 Failed running loging shell
|> >
|>
|> You probably have an incorrect path to csh specified, or a typo. Note
|> that specifying a shell that is not in the "/" filesystem can cause
|> identical problems on system recovery. .... if "/usr" is not mounted
|> then /usr/bin/SHELL will not run. This can easily happen thusly:
|>
|> $ ls -l /bin/csh
|> lrwxr-xr-x  1 root           14 Apr 22 20:31 /bin/csh -> ../usr/bin/csh
|>

 I have changed the root's password on a couple of our RS/6000's
(AIX 3.2). Because of the heavy use of SMIT on these things, I did
not change the shell by modifying the /etc/passwd file as there are
other things in /etc/security/<various files> to change, as well as
some -unknown to me- repercussions from the SMIT database.

Hence, I simply used
# passwd -s
and as expected, a list of all the available shells is put forth and
from that I chose the /bin/csh and all went well.

T get out of your dilemma (I've been in a number just like it on the
AIX machined ;-(  ) there is a trick to starting up via the service mode
and then choosing a menu selection from which you can issue a
:!sh
which will put you into the file system. Go back and reverse the changes made
to /etc/passwd and then :

1. exit the sh
2. backout of the service menus (F3's)

shutdown
If you shutdown while in the escaped shell, you may trash the entire
filesystem ( It happened to me via an IBM employee showing me how
quickly he could get things done !!!).

Chris Hook -  Computing Systems/Network Manager
Atmospheric & Geographic Sciences
University of British Columbia, Vancouver, B.C.

        Did you actually use SMIT to change that login shell?  AIX tends
to get really bent out of shape when people manually edit /etc/passwd...

Quote:>and throws me back to the login prompt again. There're no new
>users set-up in the system and I tried to login as sys, adm
>or lp with no success. I know the machine can be set to single-user
>mode however I don't know how to get into that mode whitout shutting
>down the system. And to shutdown the system I have to login as root :-(

        Since you don't have ANY other user accounts (from which you could
have su'd to root) your best bet is to haul out the ol' boot/diag floppies
and just do a RESTORE from a tape or other machine (or have your IBM
service-person do it).

Quote:>      Maybe there's a way to reboot the machine into single-user
>mode or get into the prom somehow but the manuals don't say anything
>about it and I already browsed through the whole info dbase ( available
>on another RISC system we have) finding nothing that can give me a clue
>to solve this problem.

        The lesson here is that, ROOT should ALWAYS have a Bourne or Korn shell.
If you REALLY want a C shell for ROOT, push one AFTER you log in.

        -- Matt "C P." Rush
        A* (Amiga, Accell, AIX, Apple) hack

--

        -- C P.
        -- Matt
        ".signature?  I don't need no stinkin' .signature!"

  I want to personally thank the following people who answered
to my help call. I received more replys than I expected; many
of them with different solutions and with a lot of information
that turned out to be really useful. I also want to thank all
those who published their replys in comp.unix.aix. To all of you
thanks.

Rob van Leeuwen
 Michael F. Alexander               University of Southern California  *
Bob Watson  (PLY067)         |

J. P. DeLong
Eric Siebert

Charles Richmond        International Integrated Systems Corporation        *
Michael J. Corrigan

  This last person sent me a higly detailed, step by step, procedure
which worked perfectly and I think it could be useful for other people like
me who mess around with root shells ;-) Here it is a translation
from the original in Spanish:

---------------------------------------------------------------------
You need to bootup the system in single-user mode. Here's how:

a) If you have the boot diskettes ( 3 or 4 of them )

1)  Switch the key to the "Service" position
2)  Insert the bosboot diskette
3)  Hit the Yellow button ( or turn the machine on and off )
4)  When it's time to insert the second diskette the machine
    would let you know about it by putting c07 in the 3 digits display.
5)  Take the boot disk out and insert the display diskettes
    ( if you have a graphics display )
6)  Hit F1 and Enter ( or 1 and Enter if you're in a ascii terminal )
7)  It's gonna ask you for the Installation Disk. Insert it and hit
    Enter.
8)  When you get the installation menu choose the option number 4
    or 5 ( "Enter maintenance Shell" or something like that )
9)  You'll get the root prompt. Now you've got to mount the hard disks.
    The commands are: /etc/continue hdisk0 ( if AIX 3.1.5)
                      getrootfs          ^  ( if AIX 3.2 )
                                         |
                                       J.P. DeLong made a big WARNING
                                       about this "0". If it is not
                                       the correct device number you
                                       can SEVERELY MANGLE YOUR SYSTEM.
10) vi /etc/passwd    
11) change /etc/csh to /etc/ksh
12) sync;sync;sync;fastboot
13) switch the key to the "Normal" position.
14) You're done. Check if the c-shell is installed
    in your system. If not you've got to install it.

b) In case you don't have the boot diskettes then switch the
   machine to "Service" mode hit the Big yellow Button and let it
   boot into Diagnostic. Then:

1) Hit Enter
2) Select "Service Aids"
3) Select "Service Hints"
4) you'll get into pg mode with a ":" prompt. Type !/bin/csh
5) Bingo! you'll get into single-user mode with the disks
   already mounted. Procede from step 10.
---------------------------------------------------------------------

  I followed the second part and it worked nicely.

Luigi Manna--

Los Angeles, California.

[stuff deleted]

Quote:

>1) Hit Enter
>2) Select "Service Aids"
>3) Select "Service Hints"
>4) you'll get into pg mode with a ":" prompt. Type !/bin/csh

                                                          ^^^
OOOPS! It should read "ksh" of course !!!

Cheers,

Luigi Manna--

Los Angeles, California.

Quote:>    Did you actually use SMIT to change that login shell?  AIX tends
>to get really bent out of shape when people manually edit /etc/passwd...

I know that this is what IBM wants you to believe, but it is definitely
not true. As a matter of fact, this goes for all administrative data
files on the system. SMIT is not a magic program. The only difference
is that most of the time SMIT really knows what it is doing (which is
not always the case with people who operate RS/6000s these days). I
never use SMIT to add or delete users, change their shells or home
directories, for example. I have *NEVER* experienced a problem related
to this, and there is no reason why I should; knowledgeable IBM-people
(although hard to find) will confirm this. Believe it or not, AIX is
(even if IBM messed around with it *A LOT*) still UNIX. Almost all
standard procedures you have learned on other UNIX systems will work,
unless of course those procedures themselves were vendor-specific. In
a similar way, AIX has a lot of vendor-specific peculiarities, where the
knowledge of managing these is also useless on other machines.

Quote:>    Since you don't have ANY other user accounts (from which you could
>have su'd to root) your best bet is to haul out the ol' boot/diag floppies
>and just do a RESTORE from a tape or other machine (or have your IBM
>service-person do it).

My suggestion on handling this situation would be this:

        1) Turn the key to the Diagnostic position.

        2) Use the appropriate media you have installed the
           system from, or, if you have already created boot
           floppies from this release of the system, use those
           (they're faster than tape). DO NOT USE A DIFFERENT
           RELEASE OF THE BOOTMEDIA THAN IS INSTALLED ON THE
           SYSTEM UNLESS YOU KNOW ****EXACTLY**** WHAT YOU
           ARE DOING!!! Insert this bootmedia in the appropriate
           drive.

        3) This one hurts, but do it anyway: Hit the yellow
           reset button (you may need to hit it *twice*). Don't
           worry, the filesystem will survive -- your machine is
           idle anyway, so there isn't too much activity on the
           filesystem anyway. Boot until you get the Installation
           menu.

        4) Select "Perform System Maintenance" from the menu. This
           will give you a standalone shell. Note that the system
           is running from a RAM disk at this point. It has no idea
           about your filesystems yet.

        5) Depending on your OS-release, you may need to type either
           /etc/continue or getrootvg (3.2. will tell you to do this,
           so if you see just a prompt, /etc/continue is a good bet).
           These commands will mount all your filesystems (or at least
           those that are vital, to be exact), which you can access
           and modify then. I.e. remove a root password that you have
           forgotten, or change the shell back to what it was ... you
           get my drift. Note that you are still working with a very
           limited system, though -- be prepared that you may have to
           use "ed" to modify any files :) :) :)

I could split up point 5) if I wanted to, but I don't think it's
necessary at this point. Basically what happens is a importvg, a
varyonvg, fsck if necessary and then a mount. I feel a lot more
comfortable doing it manually than with the provided scripts. But
that's just me, I suppose :) :) :)

                Chris,
                     who will give
                        telephone support
                           to anyone from the
                              Los Angeles area even
                                 in the middle of the
                                    night, provided they
                                       buy him lunch at Gladstone's
                                          the next time he gets there :)

--
SOFTPRO doesn't speak for me, and I do not speak for SOFTPRO. So what?

I'm not sure if this will work or not, but it might be worth a try:
     make 2 copies of the current password file (one to change, one as backup)
     edit one of them so the root's shell is as it was originally
     ftp local and log in as root
     put the newly edited password as /etc/password
     cross your fingers and see if it works

--Frank

The problem here is that csh is missing.  Does /etc/passwd show /bin/csh
as the shell or just csh?  Restore the old /etc/passwd file, restart the
system, and find the csh.

                                --              Ed

--

cat /std/disclaimer > /dev/null; cat /dev/kmem > /dev/lp; sync; halt
     Don't Settle For The Lesser Evil This November - Cthulhu For
                        President In 1992!

                          ^^^
                        IBM who?  Not me, that's for sure.  I can only think
of two reasons why someone would say such a thing:
   1) They understood that it was safer for novices to use smit than to try
      to directly edit the file, knowing that there was some chance that
      the user might try to change their login shell to "John Doe" or somesuch.
   2) or more pessimistically, they didn't know what they were talking about.

Quote:>          ...  As a matter of fact, this goes for all administrative data
>files on the system. SMIT is not a magic program. The only difference
>is that most of the time SMIT really knows what it is doing (which is
>not always the case with people who operate RS/6000s these days). I
>never use SMIT to add or delete users, change their shells or home
>directories, for example. I have *NEVER* experienced a problem related
>to this, and there is no reason why I should; knowledgeable IBM-people
>(although hard to find) will confirm this. Believe it or not, AIX is
>(even if IBM messed around with it *A LOT*) still UNIX. Almost all
>standard procedures you have learned on other UNIX systems will work,
>unless of course those procedures themselves were vendor-specific. In
>a similar way, AIX has a lot of vendor-specific peculiarities, where the
>knowledge of managing these is also useless on other machines.

Very well put.  SMIT is basically an interface - it spawns off processes
to perform tasks based upon the input given.  Some of the processes that
it spits off are a bit obtuse, but most are very straightforward.  I would
be surprised if anyone except the most novice UNIX user would not be able
to recognize that "Show All Current Processes" just invokes ps.  I use
SMIT when it seems easier to do so (I don't always remember all of the options
to specify when I start messing around with my network setups).  I never use
SMIT to mess with users, groups, or even installation.

Quote:

> [ lots of instructions about removing passwords via maintenance mode deleted ]

>    5) Depending on your OS-release, you may need to type either
>       /etc/continue or getrootvg (3.2. will tell you to do this,

                                   ^^
                            getrootfs                  
Like Chris stated, once you enter maintenance mode on 3.2, there will be a
statement on your screen telling you to use getrootfs to access your
filesystems.  You don't have to remember that it is "getrootfs," just read
it off of your screen.

--
Marc Stephenson             IBM AWD (Advanced Workstations Division - Austin,TX)
DISCLAIMER: The content of this posting is independent of official IBM position.

Quote:>>directories, for example. I have *NEVER* experienced a problem related
>>to this, and there is no reason why I should; knowledgeable IBM-people

  Well, I did. I put my login into group 0 (rather than group 10) on
a machine that didn't have a group 0 defined.
  Normally, not a terrible thing, but under AIX, it seems that groups
must exist, or you get kicked off with a message about being unable to
change TTY ownership. Deleting the account with SMIT and recreating it
works --- SMIT doesn't let you make the mistake.
  I'm not a naive admin -- just the opposite. I eventually stumbled
upon the solution yesterday morning, and IBM tech support called a
couple of hours later to tell me exactly that. (They did find the
solution though. I'll give them that)

  This is why I *don't* like SMIT. I'd love to have a `differences in
AIX administration from standard BSD/SysV practices' --- maybe there
is such a thing, I can't seem to find one. If you tell me to RTFM,
make sure you tell me the full title :-)

--
  :!mcr!:           | #include <ansi-std/disclaimer.h>  +1 613 592 5780

It sounds like the real problem is that login doesn't deal if you are in an
undefined group, not anything related to SMIT vs. editing the files by hand.
The only difference is that by using SMIT (or the chuser command) instead of
hand-editing the files would have caught the problem.  Disliking a system
because it catches errors doesn't seem to be quite logical.  If it's because
it isn't BSD, well, it's never going to be.

Quote:>I'd love to have a `differences in AIX administration from standard
>BSD/SysV practices' --- maybe there is such a thing, I can't seem to find
>one. If you tell me to RTFM, make sure you tell me the full title :-)

Look in /usr/lpp/bos/bsdadm ("AIXv3 for 4.3 BSD System Administrators")  and
/usr/lpp/bos/bsdport ("Porting 4.3 BSD Programs to AIX Version 3.1").  Of
course, it can't cover everything, but it should help you get started.

My $0.02-  I cut my teeth on BSD based systems, and it did take an effort to
get used to doing things differently under AIX.  However, by doing things
differently, they also had the chance to do things better.. While they
didn't succeed in all cases, I think they by and large did at least as well,
and in some things (filesystem, ODM) did much better.

        -Lucien
--
----------------------------------------------------------------------------

MIT Athena Systems Development |