Fhem auf einer SSD anstatt einer microSD Karte

MadMax-FHEM · 15 Dezember 2020, 19:38:41

Komisch, dass die part-uuid beim Klonen nicht auch mit geclont wurden...

Aber wenn die nicht gleich sind aber in der /boot/cmdline.txt und /etc/fstab auf der SSD die der SD stehen ist klar warum (auch jetzt) nix bootet...

Gibt folgende Möglichkeiten:

- SSD mounten und Einträge in fstab und cmdlin.txt "anpassen"...

- part-uuid der Partitionen der SSD "umbenennen"...

Welcher Weg soll's sein?

Ich habe beides schon gemacht, muss dann nur nachsehen wie das Vorgehen genau war...

Bzw.: kannst du auf /boot/cmdline.txt und /etc/fstab auf der SSD zugreifen von dem "MAC-Linux" aus? Wenn ja, dann eunfach dort wo die part-uuid der SD steht die entsprechende part-uuid der SSD eintragen...

Gruß, Joachim

Sammy51 · 15 Dezember 2020, 20:40:53

Ich kann vom Mac/Mac-Linux via ssh auf den pi zugreifen - und vermutlich dann auch irgenwie auf die SSD am pi. Oder meinst Du ssd vom pi entfernen - am mac anstecken und dann die files dort bearbeiten?

Nehme ich richtig an - das die ssd am mac zunächst noch nicht "von selbst" gemounted ist und ich die ssd einfach abstecken und am mac anstöpseln kann? dort würde sie ja vermutlich automatisch gemounted so dass das file editieren (falls es keine Berechtigungsprobleme gibt) so vermutlich am einfachsten wäre?

MadMax-FHEM · 15 Dezember 2020, 21:27:06

Sind die Ausgaben von blkid vom PI oder MAC?

Wenn PI, dann kannst du sie wie folgt umbenennen:

https://askubuntu.com/questions/1250224/how-to-change-partuuid
-> Now change the disk identifier with fdisk:

Also:

Code Auswählen


sudo fdisk /dev/sda

dann 'x' drücken und dann 'i' dann 0x123456 (123456->passende/alte part-uuid) dann 'r' drücken und abschließend 'w' und fertig.
Danach kannst du ja mit sudo blkid noch mal prüfen...

Ansonsten am PI mounten und die Dateien bearbeiten:

Code Auswählen


sudo mkdir /mnt/rootfs
sudo mkdir /mnt/boot
sudo mount /dev/sda1 /mnt/boot
sudo mount /dev/sda2 /mnt/rootfs

Dann solltest du unter /mnt/boot/ cmdlint.txt der SSD finden und unter /mnt/rootfs/etc/ eben fstab

Code Auswählen


sudo nano /mnt/boot/cmdline.txt
sudo nano /mnt/rootfs/etc/fstab

Wenn du per MAC tatsächlich die Dateien bearbeiten kannst (sind aber root und weiß nicht, ob es da sowas wie "sudo" gibt), dann kannst du das nat. auch da tun...

Ja klar, einfach abziehen: du machst ja (noch) nichts mit der SSD...

EDIT: erst nach dem Bearbeiten evtl. "unmounten" oder einfach den PI runter fahren...

Gruß, Joachim

Sammy51 · 15 Dezember 2020, 21:52:36

Mac basiert wohl auf unix sudo scheints auch zu geben ... aber mit debian als dual boot auf dem mac sowieso.

Bin nicht sicher ob ich Deine Anleitung heute noch korrekt umsetzen kann.
Vielleicht klappts morgen umso besser.

===========

Die obige Ausgabe war vom PI - dort hängt die SSD im Moment "neben" der SD Karte

Verstehe ich das richtig das Du oben drei Varianten beschreibst ( 1 - pi fdisk; 2 - pi mount und files editieren; 3 - am mac files editieren)

MadMax-FHEM · 15 Dezember 2020, 22:08:37

Genau, 3 Varianten...

Bzw. 4, wenn fdisk auf dem MAC-Dingens auch geht...

Oder eher 2 Varianten: part-uuid ändern oder Dateien anpassen...

Aber mit der Möglichkeit es auf 2 Systemen durchzuführen...

Lass dir Zeit und in Ruhe...

Gruß, Joachim

Sammy51 · 17 Dezember 2020, 20:07:43

Zitat von: MadMax-FHEM am 15 Dezember 2020, 21:27:06

Ansonsten am PI mounten und die Dateien bearbeiten:

Code Auswählen Erweitern
sudo mkdir /mnt/rootfs sudo mkdir /mnt/boot sudo mount /dev/sda1 /mnt/boot sudo mount /dev/sda2 /mnt/rootfs

Dann solltest du unter /mnt/boot/ cmdlint.txt der SSD finden und unter /mnt/rootfs/etc/ eben fstab

Code Auswählen Erweitern
sudo nano /mnt/boot/cmdline.txt sudo nano /mnt/rootfs/etc/fstab

Ok habe mich für die Variante entschieden und in cmdline die rootfs uuid eingetragen. die fstab wollte beide.
Also diese hier. Jetzt probiere ich sudo shutdown now .. sd karte raus .. und strom wieder dran.

Code Auswählen

/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="b268bd2d-01"
/dev/sda2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4" PARTUUID="b268bd2d-02"

Hurra vielen Dank Joachim - das booten dauerte jetzt tatsächlich länger als von sd aber es hat geklappt.
Jetzt müsste ich nur noch die rootfs partition auf die volle ssd größe ausdehnen. Oder könnte dort noch eine weitere partition für

anlegen (die SSD ist hierfür scheinbar unnötige 256 GB groß).

Und ich könnte evt. ein backup von gestern einspielen um ggf. an der ein oder anderen stelle etwas aktueller zu sein als mit dem image von vor x Tagen.

Beste Grüße
Sammy

MadMax-FHEM · 17 Dezember 2020, 20:22:59

Die rootfs Partition solltest du mit gparted ganz einfach größer "schieben" können...

Gibt es auch als Live-Boot oder auch unter Ubuntu oder Mint...

Geht auch mit Kommandos von der Kommandozeile, dann aber wieder von SD booten und dann auf dem PI...

Oder eben schauen, ob das auf dem MAC geht...

Weil solange die Partition in Nutzung ist geht das nicht...

Kommando müsste ich aber erst nachsehen...
...oder du suchst im Netz...

EDIT: wenn du eine weitere Partition anlegst, musst du halt noch mounten. Z.B. weiterer Eintrag in fstab. Habe so eine Datendisk für Samba-Freigabe eingebunden...

Viel Spaß, Joachim

Sammy51 · 17 Dezember 2020, 20:32:11

Ok das geht das sicherlich am einfachsten mit der gui variante am "LinuxBook" wenn ich die SSD dafür umstöpsel.
Backup ist schon eingespielt und jetzt gibt es die SD-KArte mit Tesa am Pi als "hardware backup".

WEnn es jetzt noch ginge einen weiteren pi in die Schublade zu legen und im Fall der Fälle den einfach anzustöpseln (mit ssd/SD und USB per ID angebundenen Dingern) wäre man diesbezüglich "safer" als zuvor mit dem NUC (abgesehen von den FHEM backups die im Moment in verchiednen Versionen auf X Geräten hier liegen