remsh - There is no passwd entry for you

Doing an remsh or rlogin and receiving the following message:  "There is no passwd entry for you"   means that something in the local password file is screwed up.   In my case, a daemon was changing it's password entry and kept adding ....,  to the password field until it started to span multiple (10) lines in the password file.  Any system call that would search the passwd file would stop at the screwed up entry.  Removing and fixing the messed up entries solved the problem.

Some other symptoms of this include having a blank user name when doing the 'id' command:
$ id
uid=12345() gid=20(users)


vi session hung (old IBM version of vi)

$ vi

UNIX Visual Text Editor Front End Utility
Copyright (C) 1996,1997 IBM Global Services
A vi session is already in progress.

delete /var/adm/vi.lock

HP-UX hangs at boot

Boot problems:
panic: lv_fixrootlv: Stale extent array overflow

cause: volume group header and /etc/lvmtab out of sync when logical volumes are mirrored.
  • boot into lvm maintenance mode: hpux -lm
  • activate vg00: vgchange -a y vg00
  • vgdisplay vg00 -- shows 3 current PV and 2 Active PV (or whatever the discrepancy is)
  • unmirror logical volumes:
    • for i in 1 2 3 4 5 6 7 8 9
    • do
    • lvreduce -A n -m 0 /dev/vg00/lvol$i
    • done
  • vgreduce -f vg00
  • now vgdisplay vg00 shows the same number of current and active PV


logname error in rlogin session on particular tty

when you rlogin and your tty is pts/0 (/dev/pts/0) you might get the following message when trying to execute logname:

logname: could not get login name

It appears that rlogind doesn't update /etc/utmp This of course appears to be intermittent if you have several clients doing rlogins, the first one that uses /dev/pts/0 will have the problem, the other will probably be fine. This is more of a problem if you are using the logname command in something like /etc/profile

Only noticed this on 11.23 (both IA and PA platforms). Both had PHNE_32818 installed. A possible fix is PHNE_33792, but I couldn't test it. A workaround is to use the variable $LOGNAME instead of the command logname.