AIX: Cannot set process environment

El problema es

$ su -
Passwd:
3004-505 Cannot set process environment

Solución
La solución pasa por detectar qué hay de anómalo en el perfil en este caso de root. Contamos según el resultado con que sí sabemos la contraseña del root (en otro caso habríamos obtenido un error de autenticación) y podemos hacer "su - -c "

$ sudo - -c 'usrck -n root'
3001-602 The user name root is not unique.
3001-603 The UID 0 is duplicated for user root.

Antes de asustarnos más comprobamos quiénes son esos dos usuarios con UID "0".
$ grep :0:0: /etc/passwd
root:!:0:0::/:/usr/usr/bin/ksh
root:!:0:0::/:/usr/bin/ksh

Se trata de eliminar una de las entradas. Como podemos hacer uso del "su" en las condiciones arriba descritas, hacemos una copia del /etc/passwd la retocamos y la devolvemos a su sitio de nuevo ya retocada.

En este caso, el problema que tenía el usuario era ese, pero el comando usrck podía habernos advertido de otra cosa diferente. Con "su -" nos apañamos para arreglarlo.

Origen del problema
Realmente son 2. El primero es un despiste humano o un fallo del smit al modificar el shell (debe hacer mucho tiempo porque no lo recuerdo). Pero el decisivo es que al migrar de AIX 5.2 a AIX6.1 al shell del root les ha puesto /usr/ delante, lo que ha convertido el shell de la primera de las 2 entradas en inexistente.

AIX: savebase failed

En alguna ocasión he comentado el error "savebase" haciendo operaciones del tipo que sea como administrador. Esto hay que interpretarlo como que no puede guardar los cambios y ante un eventual reinicio puede que ni arranque el servidor.

Ej:
# extendvg rootvg hdisk1
0516-1734 extend vg: Warning, savebase failed. Please manually run 'savebase' before rebooting.

Lo más preocupante es que ejecutamos "savebase" sin obtener ningún error pero el mensaje anterior vuelve a aparecer en la próxima ocasión que hacemos algo delicado.

Se confirman las sospechas cuando el verbose dice lo siguiente:
# savebase -v
non-bootable LV name given


SOLUCION
Lo primero es asegurarnos de que /dev/ipldevice apunta al dispositivo correcto. Para nuestro ejemplo, el rootvg está en el disco hdisk0 y nos vamos a asegurar de que sea así:

# rm /dev/ipldevice
# ln /dev/hdisk0 /dev/ipldevice
# bosboot -ad /dev/ipldevice

bosboot: Boot image is 36250 512 byte blocks.
# savebase -v
saving to '/dev/hd5'
145 CuDv objects to be saved
706 CuAt objects to be saved
47 CuDep objects to be saved
75 CuVPD objects to be saved
474 CuDvDr objects to be saved
2 CuPath objects to be saved
0 CuPathAt objects to be saved
0 CuData objects to be saved
Number of bytes of data to save = 98151
Compressing data
Compressed data size is = 25679
bi_start = 0x3600
bi_size = 0x11cfc00
bd_size = 0x11afc00
ram FS start = 0x513130
ram FS size = 0xc9cad0
sba_start = 0x11b3200
sba_size = 0x20000
sbd_size = 0x6453
Checking boot image size:
new save base byte cnt = 0x6453
Wrote 25683 bytes
Successful completion


Finalmente configuramos el disco en el bootlist si no lo estaba:
# bootlist -m normal hdisk0
# bootlist -m normal -o
hdisk0

AIX: target hdisk does not exist

Estamos en la situación de que el disco existe y lo vemos sin problemas el "lsdev" y "lspv", pero sin embargo algunos comandos dicen que no existe:


# alt_disk_install -C -B hdiskpower1
0505-125 alt_disk_install: target disk hdiskpower1 does not exist.

En mi caso era debido a que el disco estaba asignado también a otro host en la cabina de discos. Dicho host no lo estaba usando pero casualmente era un VIOS y lo tenía bloqueado porque existía un mapeo sobre el disco. La conclusión es que solamente el mapeo (el host virtual estaba parado esperando el disco) bloquea el disco.

La solución fué quitar el mapeo en el VIOS para que me permitiera trabajar en el otro host.