Recién actualizado el equipo de Fedora 31 a Fedora 32 si intentas iniciar el servicio de Postgrqsql ejecutando como root (en adelante, todo lo escrito se ejecuta como root) # systemctl start postgresql da un error.
Como siempre, miramos que dice el log tecleando: # journalctl -xe
En alguna línea aparece un mensaje similar a este (las negritas son mías):
-- The job identifier is 5061.
de maig 01 11:49:13 localhost.localdomain postgresql-check-db-dir[5619]: An old version of the database format was found.
de maig 01 11:49:13 localhost.localdomain postgresql-check-db-dir[5619]: Use 'postgresql-setup --upgrade' to upgrade to version '12'
Aplicamos lo que se recomienda y ejecutamos (el comando forma parte del paquete postgresql-server): # postgresql-setup --upgrade
La actualización dejará un log en /var/lib/pgsql/upgrade_postgresql.log. Si todo ha ido como se indica podremos iniciar el servicio con normalidad # systemctl start postgresql
Hemos instalado el RDBMS Postgresql y tenemos una sentencia SQL que queremos ejecutar planificadamente. A modo de ejemplo tomemos una SQL sencilla: # select count (*) cod_cli from client;
Evitaré utilizar el usuario predeterminado de Postgresql para que se parezca más al mundo real y conectaremos a una BD llamada factura.
La tarea en modo no batch
Consistiría en:
Conectar a la BD tecleando nuestra contraseña : psql factura -h 127.0.0.1 -d factura
Ejecutar la sentencia SQL : select count (*) cod_cli from client;
cod_cli
---------
49
(1 fila)
La tarea en modo batch
Lanzaremos un shell script que se conecta a la BD, este shell script llama a un fichero query.sql que solo contiene una línea: select count (*) cod_cli from client;
La manera de que evitar que nos pida contraseña es crear un fichero .pgpass en nuestro directorio $HOME
El fichero contendrá una línea por cada acceso a BD que queramos tener siguiendo el formato: nombre de host: puerto: base de datos: nombre de usuario: contraseña
El problema: actualizo de Fedora 29 a 30 y al reiniciar el sistema aparece un mensaje de la BIOS diciendo que no reconoce la tabla de particiones. (Podía haber ocurrido en cualquier otra circunstacia.)
La solución: está profusamente documentada por Internet. Se trata de tres pasos básicamente;
arrancar el sistema desde una distribución live (no es importante cuál, la que prefieras)
montar el sistema de ficheros de tus discos duros y hacer chroot a tu Linux
reinstalar grub y reiniciar
Y con más detalle: Primero: Existen distribuciones Linux o CD de rescate orientados a esta tarea, por ejemplo System rescue CD. Un administrador de sistemas no siempre tiene el tiempo o las ganas de utilizarlas, o confía más en sus capacidades. En el caso de seguir por esta opción, se toma cualquier distribución live y se entra en la BIOS e indicamos en el orden de arranque que inicie el sistema por el USB, en donde dejaremos la ISO live. En el caso real que me llevó a esto, no utilice una live, tomé una CentOS Minimal que tenía a mano y elegí iniciar en rescue mode. Aparecerá una pantalla como la que sigue y elegimos la opción 1:
CentOS in rescue mode
Segundo: El arranque elegido nos permite entrar en nuestro Linux haciendo cd /mnt/sysimage/ y si allí está nuestra instalación, entonces hacemos chroot /mnt/sysimage para convertirlo en nuestro sistema raiz.
Reinstalamos grub, en el caso del ejemplo era grub2; grub2-install –boot-directory=/boot/ –recheck /dev/sda lo que actualizará la tabla de particiones dañada y reinstalará GRUB en el MBR. Dañado, en nuestro caso, por un reinicio que acabó mal tras actualizar la distribución .
Tercero: reiniciamos el sistema y dejamos que SELinux vuelva a etiquetar el sistema de ficheros (lamento la calidad de la foto, se hizo con prisas para documentarlo). Se inició el sistema de nuevo, el MBR reconoció la tabla de particiones y todo fue bien,
