Built for Rock'n'Roll (i was)

Hasta hace bien poco para correr el servidor de Open Media Vault (OMV) en RaspBerry Pi había que seguir el método tradicional que se aplicaba a los sistemas operativos de esta máquina: quemar una imagen del software en una microsd o un pendrive usb y arrancarlo en RaspBerry Pi. Se trataba de un sistema operativo "dedicado", basado en ArmBian, que corría todo lo necesario para que el servidor OMV funcionara.

Actualmente ese método ancestral ya no está "activo", e incluso la imagen .ISO ya no se encuentra en el "repositorio" habitual de SourceForge.

Hoy se instala Open Media Vault en RaspBerry Pi sobre un sistema operativo ya existente -RaspBian Lite es lo "recomendado- como si fuera un servicio convencional, incorporando elementos mediante apt.
Esto se puede hacer de dos formas: paso a paso, o bien automatizado a través de un script.

He intentado instalar Open Media Vault (y todas sus "dependencias") en RaspBian Buster completo (no en RaspBian Buster Lite, como se especifica oficialmente).

Ambos métodos han dado como resultado una instalación fallida debido, fundamentalmente, a que en el sistema ya existía una instalación mía de apache2, mariadb, php, etcétera...

He experimentado e investigado 3 cosas:



1) ¿Cómo se pueden subsanar los problemas que acontecen en RaspBian "completo" para que la instalación de OMV sea exitosa?
→ Desde cero. Sin instalar previamente servidores web, php, mysql etcétera. A partir de Raspbian limpio y actualizado se puede instalar OMV sin errores.



2) Si el fallo está en emplear como base RaspBian "completo" y no RaspBian Lite. Probar ambos métodos en RaspBian Lite.
Por ejemplo: Existe la posibilidad de que el hecho de emplear RaspBerry Pi 4 y no los anteriores modelos influya en los errores antes mencionados. O también que la versión de RaspBian empleada sea Buster y no Stretch. O también que la instalación de NextCloud + apache2 + mariadb + php7.2 que tenía ya consolidada interfiera.
→ El modelo de RaspBerry Pi no afecta en absoluto. OMV 5 funciona correctamente en RaspBerry Pi 4b.
SÍ es cierto que los problemas de instalación de OMV 5 eran debidos a las interferencias de la instalación de NextCloud + apache2 + mariadb + php7.2 que tenía ya consolidada.


3) Si, en caso de que OMV fuera exitosamente instalado en RaspBian Lite, ¿existirían incompatibilidades con...?:
3.1 la incorporación de un entorno gráfico
3.2 la incorporación mediante apt de servicios extras como NextCloud, PiHole, OpenVpn, etcétera.... algunos de los cuales he leído que OMV acepta incorporarlos como plugins o como Docker.
→ No he constatado incompatibilidades con el añadido a posteriori de un escritorio gráfico al sistema y mucho menos si el entorno gráfico es anterior a la instalación de OMV 5. Se logra instalar sin incidencias OMV 5 en RaspBian completo.
→ PiHole no interfiere, al menos si se instala después de instalar OMV y se le cambia el puerto a uno diferente del 80 (que es el que emplea PiHole) desde el interface web (de OMV).



4) Si el antiguo sistema para poner en funcionamiento un servidor OMV a partir de una imagen de disco (.ISO) funcionaría en RaspBerry Pi 4. Intuyo que no, mas he de comprobarlo empíricamente.
→ en curso.....

Este blog se está transportando a un sitio "más libre".
Puede consultarse este artículo en su nueva ubicación:
>>>>>>>>>>>>>>>>>>>>>>

Para poner o quitar el modo mantenimiento en NextCloud basta con editar el fichero /var/www/html/nextcloud/config/config.php y modificar el valor de 'maintenance' a true o false, según convenga.

sudo nano /var/www/html/nextcloud/config/config.php

  'maintenance' => false,

La partición boot y la partición rootfs deben estar en sincronía.
Podemos tener la partición boot en la tarjeta microsd y la partición de datos -rootfs- en un dispositivo de almacenamiento usb -algo muy común en RaspBerry Pi 4, que no arranca de forma "nativa" desde USB, o en el resto de modelos de RaspBerry Pi cuando utilizamos discos duros mecánicos que tienen excesiva latencia al arrancar-, mas ambas particiones deben estar sincronizadas: si se actualiza el sistema ambas particiones se ven afectadas. La partición de datos -rootfs- muy probablemente no funcionará correctamente si arrancamos desde una microsd con una partición de arranque -boot- que no ha sido actualizada simultáneamente.

Obtendremos, por ejemplo, el siguiente error nada más arrancar:

[Failed] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.

Generalmente viene aderezado con el problemón de que ningún dispositivo usb funcionará, ni las tarjetas de red, etcétera...

La solución rápida es recurrir a una copia de seguridad de ambas que haya sido realizada simultáneamente: partición de arranque y partición de datos.

Por consiguiente: cuando hagamos copia de seguridad del sistema, hagámoslo de ambas particiones.

Esto se puede hacer desde gnome-disks o tambien con gparted.

No obstante, últimamente obtengo muchos fallos desde esas dos aplicaciones cuando trato de redimensionar o cambiar la etiqueta de una partición.

En mi caso estoy tratando de renombrar la etiqueta de una partición que está en mayúsculas a lo mismo pero en minúsculas. Es una partición fat32 y sé que el uso de minúsculas está desaconsejado. Quizás por eso gparted o gnome-disks no permite ese cambio.

Antes de llevar a cabo estas modificaciones es conveniente desmontar la partición.

Solución (dado que es fat32):
sudo umount /dev/sdxx
fatlabel /dev/sdxx nueva_etiqueta

Procedimiento general:

Siempre desmontar la partición
umount /dev/sdxx

Si el sistema de ficheros es FAT/FAT32 el comando a emplear es fatlabel:
fatlabel /dev/sdxx nueva_etiqueta

Si el sistema de ficheros es ext2/3/4 utilizaremos los comandos e2label o tune2fs:
e2label /dev/sdxx nueva_etiqueta
ô
tune2fs -L nueva_etiqueta /dev/sdxx

Si el sistema de ficheros es NTFS utilizaremos ntfslabel:
ntfslabel /dev/sdxx nueva_etiqueta


Una vez renombrada/cambiada la etiqueta se puede verificar la etiqueta que tiene una partición:

Para FAT32
fatlabel /dev/sdxx

Para ext2/3/4
e2label /dev/sdxx
ô
tune2fs -l /dev/sdxx | grep volume

Para NTFS
ntfslabel /dev/sdxx

En la fotografía, marcados en rojo, los puntos "de calor" de RaspBerry Pi 4


Imagen térmica de RaspBerry Pi 4:

El parámetro a continuación de -n es el tiempo en segundos que pasará entre comprobación y comprobación.
En este ejemplo se especifica que haga la comprobación cada 1 segundo.

watch -n 1 "vcgencmd measure_clock arm; vcgencmd measure_temp"