☰

¿El sistema de archivos se ha vuelto de solo lectura después de actualizar a 15.04?

tag-icon • tag-icon 15.04 fsck fdisk tmp
¿El sistema de archivos se ha vuelto de solo lectura después de actualizar a 15.04?

Estúpidamente decidí actualizar de 14.04LTS a 14.10 y luego a 15.04.

Desde que hice eso, mi sitio web dejó de funcionar y el sistema de archivos pasó a ser de solo lectura. No tengo idea de qué salió mal, ya que las actualizaciones se completaron correctamente.

Esto es lo que he encontrado hasta ahora:

    root@lew:/# service apache2 status
apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
   Active: failed (Result: exit-code) since Sun 2015-07-12 08:36:18 EDT; 31min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 901 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE)

Jul 12 08:36:18 lew.im systemd[1]: Starting LSB: Apache2 web server...
Jul 12 08:36:18 lew.im apache2[901]: * Starting web server apache2
Jul 12 08:36:18 lew.im apache2[901]: mktemp: failed to create file via template ‘/tmp/tmp.XXXXXXXXXX’: Read-only file system
Jul 12 08:36:18 lew.im apache2[901]: /etc/init.d/apache2: 91: /etc/init.d/apache2: cannot create : Directory nonexistent
Jul 12 08:36:18 lew.im apache2[901]: *
Jul 12 08:36:18 lew.im apache2[901]: * The apache2 configtest failed.
Jul 12 08:36:18 lew.im systemd[1]: apache2.service: control process exited, code=exited status=1
Jul 12 08:36:18 lew.im systemd[1]: Failed to start LSB: Apache2 web server.
Jul 12 08:36:18 lew.im systemd[1]: Unit apache2.service entered failed state.
Jul 12 08:36:18 lew.im systemd[1]: apache2.service failed.

luego fdisk -l:

root@lew:/# fdisk -l

Disk /dev/vda: 20 GiB, 21476933632 bytes, 41947136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 06F7B3C9-8E13-42CD-AD52-7A02301B6F16

Device     Start      End  Sectors Size Type
/dev/vda1   2048 41945087 41943040  20G Linux filesystem

y fsck/

root@lew:/# sudo fsck /
fsck from util-linux 2.25.2
fsck.ext4: Unable to resolve 'UUID=815063a9-c956-44a6-ab11-05e1d0bb3a58'

Soy un principiante en todo esto, pero por lo que he leído, ¿necesito arreglar algo en fstab? ¿Por qué la actualización ha roto esto? ¿Qué podría haber salido mal?

Conecto SSH a este servidor, ya que está alojado en DigitalOcean.

Editar:

Blkid

root@lew:~# blkid
/dev/vda1: LABEL="DOROOT" UUID="18254707-08e8-494e-b456-938592928a5e" TYPE="ext4" PTTYPE="dos" PARTLABEL="primary" PARTUUID="8c484e81-f919-4803-acc7-1447fdd81b45"

Montar

root@lew:~# mount
/dev/vda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,nodev,noexec,nosuid)
sysfs on /sys type sysfs (rw,nodev,noexec,nosuid)
none on /sys/fs/cgroup type tmpfs (rw,uid=0,gid=0,mode=0755,size=1024)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,nodev,noexec,nosuid,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,nodev,noexec,nosuid,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,noexec,nodev,none,name=systemd)

Fstab

root@lew:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda1 during installation
#UUID=815063a9-c956-44a6-ab11-05e1d0bb3a58 /               ext4    errors=remount-ro 0       1
UUID=06F7B3C9-8E13-42CD-AD52-7A02301B6F16 /               ext4    errors=remount-rw 0       1

/swapfile       none    swap    sw      0       0

Respuesta1

La solución fue publicada en los comentarios de@Lewis Lebentz 26 de julio a las 15:00.

Lo parafrasearé para que cualquiera que busque la respuesta pueda encontrarla aquí fácilmente. Pero @Lewis debería publicar la respuesta él mismo, marcarla como respondida y obtendrá el crédito correspondiente.

La solución: Abra un ticket de soporte, solicite a Digital Ocean que monte el ISO de recuperación (es un ISO especial que solo ellos pueden montar).

  1. Elija 1 para montar el sistema de archivos y editarlo /etc/fstab. Nota:Utilice la consola y ejecute nanoo vi /mnt/etc/fstab. Alternativamente, puede habilitar SSH y redes (en las opciones de recuperación) para iniciar sesión con su terminal (consulteinstrucción) aunque no lo he probado yo mismo.
  2. Cambió el UUID allí a la salida de blkid, guarde.
  3. Pídale a DO que retire el disco de recuperación. ¡Reinicie y debería tener acceso nuevamente!

Respuesta2

Puedes hacer lo que ændrük publicó en los comentarios:

$ mount -rw -o remount /dev/vda1 /
$ sed s/wrong_uuid/correct_uuid/ -i /etc/fstab

..y luego reinicia tu Linux nuevamente! Asegúrese de cambiar vda1 con el nombre de su dispositivo. Y en el comando sed, ¡los uuids correctos, por supuesto!

Respuesta3

Descubrí que esto también me pasa a mí. No se pudo resolver el UUID del disco en /etc/fstab. Solucioné esto encontrando primero el UUID del disco ejecutando

sudo blkid -c /dev/null -o list

Y copiando el UUID del disco para el punto de montaje./

Luego seguí el comentario de @ændrük y volví a montar el disco con

mount -rw -o remount UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx

Luego edité /etc/fstab para cambiar el UUID del disco raíz.

información relacionada