Nach Upgrade auf Stretch nur noch read-only

NewZorker · December 29, 2018 at 11:51 AM

Hallo,

ich habe meinen Pi 3 Server auf Stretch upgegradet, um endlich einmal den Pi 3+ zu nutzen. Auf dem Server läuft mein Blog rustimation.eu, eine Owncloud und Gateways für div. Revese Tunnel. Boot erfolgt noch mit der SD Karte, Root ist komplett auf einer externen SSD Platte.

Der Upgrade ging so einigermaßen durch, das System bootet, aber die SSD USB Disk wird jetzt immer als read-only gemounted. Boot auf der SD Karte ist Read/Write. Damit funktioniert weder die Datenbank noch der Webserver.

Mit sudo mount -n -o remount,rw / und nachfolgendem Start der Datenbank und des Webservers bekomme ich das System wieder zum laufen, aber schön ist das nicht. Außerdem erscheint eine Meldung mount: /etc/fstab: parse error at line 3 -- ignored, wobei Zeile 3 genau die ist, die das USB Device einhängt.

Syslog ist logischerweise leer, da das Log nicht geschrieben werden kann.

Dmesg sagt:

[ 3.910029] usb-storage 1-1.5:1.0: USB Mass Storage device detected

[ 3.920523] scsi host0: usb-storage 1-1.5:1.0

[ 4.952247] scsi 0:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6

[ 4.965017] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)

[ 4.977005] sd 0:0:0:0: [sda] Write Protect is off

[ 4.985546] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00

[ 4.986007] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[ 5.002810] sd 0:0:0:0: [sda] Attached SCSI disk

[ 7.136404] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)

[ 7.147910] VFS: Mounted root (ext4 filesystem) readonly on device 8:0.

Meine fstab:

proc /proc proc defaults 0 0

/dev/mmcblk0p1 /boot vfat defaults

/dev/sda / ext4 defaults, rw, noatime 0 1

df: Platz ist noch genug vorhanden

Mit mount wird die USB Platte nach dem Booten wie folgt ausgegeben:

/dev/sda on / type ext4 (ro,relatime,data=ordered)

Was mache ich falsch, bzw. wo ist Stretch hier empfindlicher als Jessie? Schließlich hat vorher alles mit den selben Einstellungen funktioniert...

Vielen Dank für jegliche Hinweise!

Chris aka Rustimator aka NewZorker

Bot · Vor 5 Minuten

Nach Upgrade auf Stretch nur noch read-only? Schau mal ob du hier fündig wirst!

**hyle** · December 29, 2018 at 12:03 PM Official Post

Quote

/dev/sda on / type ext4 (ro,relatime,data=ordered)

sda... Fehlt da nicht noch die Angabe der Partition bzw. wäre das verwenden der UUID nicht sinnvoller?

NewZorker · December 29, 2018 at 12:09 PM

Da die Disk nur eine Partition hat brauche ich - glaube ich - keine Partition ID. Ich habe es auch über die UUID versucht. Bringt leider nichts.

proc /proc proc defaults 0 0

/dev/mmcblk0p1 /boot vfat defaults

#/dev/sda / ext4 defaults, rw, noatime 0 1

uuid=8dd91411-1643-4116-9db4-6c0a605f02bd / defaults, user, rw, noatime, timeo=10 0 1

Danke erstmal

Chris

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

**hyle** · December 29, 2018 at 12:27 PM Official Post

Quote from NewZorker

Da die Disk nur eine Partition hat brauche ich - glaube ich - keine Partition ID

sda ist das reine Laufwerk. sda1 oder sda2... sind die Partitionen auf dem Laufwerk.

https://wiki.ubuntuusers.de/Datentr%C3%A4g…gesuchte-Geraet

Die Partitionen kannst Du ja mal anzeigen lassen mit:

Code

sudo blkid -o list -w /dev/null

NewZorker · December 29, 2018 at 12:34 PM

Das Ergebnis sieht so aus:

device fs_type label mount point UUID

--------------------------------------------------------------------------------------------------------------------------------------------------------

/dev/mmcblk0 (in use)

/dev/mmcblk0p1 vfat boot /boot 0EF2-CA4B

/dev/mmcblk0p2 ext4 (not mounted) e093a5bb-b180-4f87-9d60-467b3e79811d

/dev/sda ext4 USBDISK / 8dd91411-1643-4116-9db4-6c0a605f02bd

Da steht also nix mit Partitionen auf der USBDISK...

**hyle** · December 29, 2018 at 12:55 PM Official Post

Quote from NewZorker

Da steht also nix mit Partitionen auf der USBDISK

So etwas sehe ich zum ersten Mal. Funktioniert es mit der UUID?

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

NewZorker · December 29, 2018 at 12:57 PM

UUID habe ich eingestellt aber ohne dass das Phänomen verschwindet (siehe Post #3)

**hyle** · December 29, 2018 at 1:09 PM Official Post

Eine Idee hätte ich noch...

Quote from NewZorker

/dev/sda / ext4 defaults, rw, noatime 0 1

Lösche mal die Leerzeichen zwischen defaults, rw, noatime in der fstab. Und das rw kannst Du auch gleich löschen, das ist in den defaults schon mit enthalten.

RTFM · December 29, 2018 at 1:19 PM

Quote from NewZorker

Was mache ich falsch, bzw. wo ist Stretch hier empfindlicher als Jessie? Schließlich hat vorher alles mit den selben Einstellungen funktioniert...

Du hast es geschafft, bei der Einrichtung der SSD das Ext4 / root-Filesystem nicht in eine Partition (/dev/sda1), sondern auf das ganze Device (Gerät) /dev/sda - quasi wie eine Floppy Disk - einzurichten.

Das kann auf Dauer nicht funktionieren, mich wundert, dass es vor dem Upgrade überhaupt ging.

Servus !

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

NewZorker · December 29, 2018 at 1:24 PM

Okay, das schwant mir so langsam auch. Gibt es eine Möglichkeit, das zu korrigieren, ohne, dass ich die Daten Verlieren bzw. Ohne erstmal alles wegzusichern und dann wieder aufzuspielen?

Danke für den Hinweis.

Chris

dreamshader · December 29, 2018 at 1:25 PM

Genau so isses:

Code

dirk@uranus:~$ mount 
/dev/sdb on /mnt type ext4 (rw,relatime,data=ordered)

in Ermangelunt einer Platte hatte ich einfach mal eine micro SD genommen, weil mir so was dachte ...

Alle Partitionen gelöscht und einfach mit fdisk ein ext4 Dateisystem erstellt.

Code

dirk@uranus:~$ sudo mkfs -t ext4 /dev/sdb
[sudo] Passwort für dirk: 
mke2fs 1.44.1 (24-Mar-2018)
In /dev/sdb wurde eine dos-Partitionstabelle gefunden
Trotzdem fortfahren? (j,n) j
Ein Dateisystem mit 3889536 (4k) Blöcken und 972944 Inodes wird erzeugt.
UUID des Dateisystems: 3c5ae37b-0e71-4f0f-924c-9c26bec2abdb
Superblock-Sicherungskopien gespeichert in den Blöcken: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

beim Anfordern von Speicher für die Gruppentabellen: erledigt                            
Inode-Tabellen werden geschrieben: erledigt                            
Das Journal (16384 Blöcke) wird angelegt: fertig
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

dirk@uranus:~$ lsblk
NAME                   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                      8:0    0 931,5G  0 disk 
├─sda1                   8:1    0   512M  0 part /boot/efi
└─sda2                   8:2    0   931G  0 part 
  ├─lubuntu--vg-root   253:0    0 930,1G  0 lvm  /
  └─lubuntu--vg-swap_1 253:1    0   976M  0 lvm  [SWAP]
sdb                      8:16   1  14,9G  0 disk 
sr0                     11:0    1  1024M  0 rom  

dirk@uranus:~$ sudo mount /dev/sdb /mnt
dirk@uranus:~$ ls -l /mnt
insgesamt 16
drwx------ 2 root root 16384 Dez 29 13:20 lost+found

Display More

//EDIT:

btw: womit einmal mehr bewiesen wäre, dass der offizielle update/upgrade Vorgang i.d.R. keine Fehler erzeugt, sondern lediglich bereits existierende sichtbar machen kann ...

Und nein, Du wirst um eine Sicherung nicht drum herum kommen ... schliesslich änderst Du mit dem Anlegen einer Partition die Systemtabellen des FS.

cu,

-ds-

NewZorker · December 29, 2018 at 1:44 PM

Danke an alle! Ich probier das mal aus, muss voher aber nochmal ein Backup vom Root ziehen. Am saubersten wäre natürlich gewesen, den Server unter Stretch neu aufzusetzen anstatt einen Upgrade zu fahren, aber das alles mit Zertifikaten etc. zum Laufen zu bringen, ist einfach unheimlich aufwändig

Schönen Samstag noch

Chris

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

RTFM · December 29, 2018 at 1:50 PM

Quote from NewZorker

Gibt es eine Möglichkeit, das zu korrigieren, ohne, dass ich die Daten Verlieren bzw. Ohne erstmal alles wegzusichern und dann wieder aufzuspielen?

Nein. (für Experten auch nicht, die würden zumindest die Metadaten sichern)

Dort, wo die Partitionstabelle (GPT oder MBR) sich normalerweise befindet, sind bereits die Metadaten der EXT4 Partition derzeit situiert.

Du kannst aber mit "tar" eine Komplettsicherung abziehen, dann ersparst Du Dir das Verkleinern des dd-gesicherten FS.

Servus !

Manul · December 29, 2018 at 3:38 PM

Quote from RTFM

Das kann auf Dauer nicht funktionieren

Warum? Prinzipiell sollte das kein Problem sein.

Quote from RTFM

Nein.

Auch hier bin ich anderer Meinung: Prinzipiell geht das, wie ist hier beschrieben. Riskant und bringt keinen Vorteil gegenüber Wegsichern und Zurückkopieren, aber ich würde es wahrscheinlich aus reiner Neugier ausprobieren.

llutz · December 29, 2018 at 4:27 PM

Quote from Manul

Warum? Prinzipiell sollte das kein Problem sein.

Nicht nur prinzipiell. Solange man im Hinterkopf behält, dass man so etwas betreibt und nicht jedem hergelaufenen Tool blind Zugang dazu gewährt, ist das überhaupt kein Problem.

(*Es gibt leider immer kaputte Tools, die ein Dateisystem auf einem Device nicht erwarten.)

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

RTFM · December 29, 2018 at 5:23 PM

Es geht IMHO deshalb nicht, weil Du keinen Schreibzugriff mehr auf das Ext4-FS hast.

Und die Frage war: "Ohne Sicherung", also Operation am offenen Herzen.

Servus !

Manul · December 30, 2018 at 3:54 PM

Quote from RTFM

Es geht IMHO deshalb nicht, weil Du keinen Schreibzugriff mehr auf das Ext4-FS hast.

Ich sehe da keinen ursächlichen Zusammenhang.

Quote from RTFM

Und die Frage war: "Ohne Sicherung", also Operation am offenen Herzen.

Genau das ist in meinem link beschrieben.

NewZorker · January 1, 2019 at 4:23 PM

Hallo,

so! habe jetzt gut 2 Tage gebraucht mein - durch eigene Blödheit - zerstörtes System wieder neu aufzubauen.

Ich hatte einen Backup mit raspiBackup gezogen, die Partition SDA1 erzeugt und den Backup wieder aufgespielt. Danach ging nichts mehr, bzw. kein sudo, viele Utilities gingen nicht mehr, ganz zu schweigen von der Datenbank - nicht zu gebrauchen.

Ich habs dann meinen Server "from scratch" wieder neu erzeugt. Teilweise anhand der rsync Rohdaten aus dem Backup und eigenständiger Wordpress Backups. Nervig, aber ich habe auch viel dabei gelernt.

Der Fehler lag darin, dass ich das Backupmedium unter /mnt/NAS mit 777 Permissions für alle freigegeben habe. Damit war alles unterhalb des Mountpoints auch mit 777 gespeichert. Beim Wiederherstellen streikt das System dann, da einige Systemfunktionen eben nur für den Superuser zugreifbar sein dürfen - zumindest vermute ich das.

Jetzt geht wieder alles, ABER: mit lsblk wird die SSD Festplatte, auf der sich root befindet korrekt mit 111,8 GB angegeben

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda 8:0 0 111,8G 0 disk

└─sda1 8:1 0 111,8G 0 part /

mmcblk0 179:0 0 29,7G 0 disk

├─mmcblk0p1 179:1 0 43,9M 0 part /boot

└─mmcblk0p2 179:2 0 29,7G 0 part

mit df -h ist Root viel kleiner, nämlich nur 30GB:

Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

/dev/root 30G 18G 11G 64% /

devtmpfs 484M 0 484M 0% /dev

tmpfs 489M 0 489M 0% /dev/shm

tmpfs 489M 6,6M 482M 2% /run

tmpfs 5,0M 4,0K 5,0M 1% /run/lock

tmpfs 489M 0 489M 0% /sys/fs/cgroup

/dev/mmcblk0p1 44M 23M 22M 51% /boot

tmpfs 98M 0 98M 0% /run/user/1000

Wie kann das sein? Macht da df einen Fehler oder habe ich da einen Hund reingebracht?

Wäre toll, wenn mir jemand auf die Sprünge helfen würde.

Ansonsten "Happy New Year a tutti"

Chris

https://www.rustiation.eu

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

RTFM · January 1, 2019 at 7:16 PM

Wenn sich mit sudo raspi-config das EXT4 Filexstem auf /dev/sda1 nicht auf die gesamte SSD ausdehnen lässt, kannst Du das mit "tune2fs" machen und vorher das neue Sektorende der Partition Nr.1 mit parted oder fdisk in die Partition Table eintragen.

Servus !

NewZorker · January 1, 2019 at 9:23 PM

Hallo RTFM,

danke für den Fingerzeig. Ich hab dann mit Hilfe deines Hinweises auf tune2fs noch etwas "RTFM" gemacht und habe bei wiki.ubuntuusers.de folgendes entdeckt und bei nicht mehr gemounteten /dev/sda1 folgenden Befehl eingegeben:

Code

sudo resize2fs -p /dev/sda1   # Vergrößert das Dateisystem bis zur maximalen Größe des Logical Volumes oder der Partition

Der letzte Sektor war ja schon eingetragen, nur wurde die Partition irgenwie - weiß der Geier warum - nicht vollständig ausgenutzt. raspi-config kann nur bei SD Karten das Filesystem vergrößern.

Jetzt funktioniert alles.

Vielen Dank, viele Grüße, ein schönes neues Jahr.

Chris

https://www.rustimation.eu - Ich mache und erkläre dort mehr IoT Kram und Netzwerk, vom Dateisystem habe ich bisher immer die Finger gelassen.

Nach Upgrade auf Stretch nur noch read-only

Participate now!

Tags