☰

Das Dateisystem ist nach der Aktualisierung auf 15.04 schreibgeschützt?

tag-icon • tag-icon 15.04 fsck fdisk tmp
Das Dateisystem ist nach der Aktualisierung auf 15.04 schreibgeschützt?

Ich habe dummerweise beschlossen, von 14.04LTS auf 14.10 und dann auf 15.04 zu aktualisieren.

Seitdem ist meine Website nicht mehr erreichbar und das Dateisystem ist schreibgeschützt. Ich habe keine Ahnung, was schiefgelaufen ist, da die Updates erfolgreich abgeschlossen wurden.

Das habe ich bisher gefunden:

    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.

dann 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

und fsck /

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

Ich bin ein Anfänger in all dem, aber nach dem, was ich gelesen habe, muss ich etwas in fstab reparieren? Warum hat das Update das kaputt gemacht, was könnte schiefgelaufen sein?

Ich melde mich per SSH bei diesem Server an, da er bei DigitalOcean gehostet wird.

Bearbeiten:

Schwarz

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"

Montieren

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

Antwort1

Die Lösung wurde in den Kommentaren gepostet von@Lewis Lebentz 26. Juli um 15:00.

Ich werde es umschreiben, damit jeder, der nach der Antwort sucht, sie hier leicht finden kann. Aber @Lewis sollte die Antwort selbst posten, sie als beantwortet markieren und Sie erhalten die gebührende Anerkennung.

Die Lösung: Öffnen Sie ein Support-Ticket und bitten Sie Digital Ocean, das Wiederherstellungs-ISO zu mounten (es ist ein spezielles ISO, das nur sie mounten können).

  1. Wählen Sie 1, um das Dateisystem zu mounten und zu bearbeiten /etc/fstab. Notiz:Verwenden Sie die Konsole und führen Sie nanooder aus vi /mnt/etc/fstab. Alternativ können Sie SSH und Netzwerk (in den Wiederherstellungsoptionen) aktivieren, um sich mit Ihrem Terminal anzumelden (sieheAnweisung), obwohl ich das selbst nicht ausprobiert habe.
  2. Habe die UUID dort in die Ausgabe von blkid geändert, gespeichert.
  3. Bitten Sie DO, die Wiederherstellungsdiskette zu entfernen. Starten Sie neu und Sie sollten wieder Zugriff haben!

Antwort2

Sie können tun, was ændrük in den Kommentaren gepostet hat:

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

..und dann booten Sie Ihr Linux erneut! Stellen Sie sicher, dass Sie vda1 durch Ihren Gerätenamen ersetzen. Und im sed-Befehl natürlich die richtigen UUIDs!

Antwort3

Das ist mir auch passiert. Die Festplatten-UUID in /etc/fstab konnte nicht aufgelöst werden. Ich habe das Problem behoben, indem ich zuerst die UUID der Festplatte ermittelt habe, indem ich Folgendes ausgeführt habe:

sudo blkid -c /dev/null -o list

Und kopieren Sie die Disk-UUID für den Mount-Punkt/

Ich bin dann dem Kommentar von @ændrük gefolgt und habe die Festplatte erneut gemountet mit

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

Anschließend habe ich /etc/fstab bearbeitet, um die Datenträger-UUID für den Root-Datenträger zu ändern.

verwandte Informationen