Fhem auf einer SSD anstatt einer microSD Karte

[ch.eick]

verm. steht bei dir (wie bei mir, eben geschaut) in /etc/default/rpi-eeprom-update noch "critical"...
Warum auch immer bei einem frisch gekauften und noch nie nix was gemachten dort "critical" steht...

Dort dann "stable" eintragen (eigenes RISIKO, eh klar) und dann noch mal update usw.

done

Code Auswählen Erweitern


pi@raspberrypi:~ $ vcgencmd bootloader_version
Jun 15 2020 14:36:19
version c302dea096cc79f102cec12aeeb51abf392bd781 (release)
timestamp 1592228179
pi@raspberrypi:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Mo 15. Jun 13:36:19 UTC 2020 (1592228179)
LATEST: Mo 15. Jun 13:36:19 UTC 2020 (1592228179)
FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad


Und nun internet suche?

[MadMax-FHEM]

Naja jetzt solltest du halt ein OS auf die SSD spielen (Buster aufwärts soll tun)...
...oder ein bestehendes transferieren (sollte muss aber möglichst up-to-date sein)...

Und dann sollte er davon booten...

Gruß, Joachim

[ch.eick]

Naja jetzt solltest du halt ein OS auf die SSD spielen (Buster aufwärts soll tun)...
...oder ein bestehendes transferieren (sollte muss aber möglichst up-to-date sein)...

Und dann sollte er davon booten...

Das habe ich im Netz gefunden und durchgefuehrt....

Code Auswählen Erweitern


## RPI4 usb boot

ls -l /etc/default/rpi-eeprom-update    # stabile in die Datei schreiben

sudo apt-get update
sudo apt-get upgrade

sudo rpi-eeprom-update

## bootloader config ansehen
vcgencmd bootloader_config
## Das ist die alte config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

## Ein frischer boot
reboot

## bootloader config ansehen
vcgencmd bootloader_config
## Da steht dann immer noch die alte config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0


## bootloader config aus dem neuen Image in eine Datei schreiben
rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin > bootconf.txt

less bootconf.txt
## so sieht die neue standard config aus
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
bootconf.txt (END)


## bootloader config in neues usbboot Image schreiben, wenn etwas veraendert wurde
rpi-eeprom-config --out pieeprom-usbboot.bin --config bootconf.txt  /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

## Neues usbboot Image ins eeprom schreiben
sudo rpi-eeprom-update -d -f ./pieeprom-usbboot.bin

## bootloader config ansehen
vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41



Dann habe ich die SD Card auf die SSD gecloned. Nach einem mounten ist auch alles auf der ssd zu sehen.

Nur leider stoppt, nach dem Entfernen der SD Card, der boot von der ssd mit einem blinkenden Curser links oben in der Ecke.
Das muss ich mir dann morgen nochmal in Ruhe anschauen.

Gruss
    Christian

[Sammy51]

Hallo zusammen,

habe nich nun auch diesbezüglich versucht um die Stabilität und Ausfallsicherheit zu erhöhen.
Fand dazu auch Anleitungen (nachfolgend). Es klappt zunächst aber nicht.

Sobald die SSD am USB hängt (und die SD entfernt ist) - startet der Raspberry PI3b mit Buster nicht mehr (die Leds bleiben schlicht dunkel; nur die Netzwerkleds blinken). Sobald ich wieder die SD-Karte einstecke läuft es wie bislang.

Woran kanns liegen?

Was habe ich gemacht:
1.) Boot Option gemäß dieser Anleitung aktiviert https://www.elektronik-kompendium.de/sites/raspberry-pi/2404241.htm

Code Auswählen Erweitern

vcgencmd otp_dump | grep 17:
17:3020000a
2.) Raspberry PI heruntergefahren

Code Auswählen Erweitern

sudo shutdown -h 0
3.) SD Karte entfernt
4.) SSD in USB Gehäuse (Ugreen mit USB c auf USB A Kabel) eingebaut (Das ist dieses: https://www.youtube.com/watch?v=FGGxtUYyqOE)
5.) SD-Karte mit Aomei Backup auf SSD geklont https://www.ubackup.com/de/klonen/sd-karte-auf-groessere-kopieren.html
6.) USB SSD an RPI angesteckt
7.) Stromversorgung RPI "aktiviert"

[MadMax-FHEM]

Hast du dir die SSD mal nach dem Klonen auf einem Linux-System angeschaut!?

Weil so ich das gesehen habe ist es ja ein Windoof-Tool?

Die Datenpartition bei der SD ist aber Ext4, also ein Linux-File-System...
...nicht, dass das Klone-Programm damit nicht zurecht kommt...

Ansonsten hatte ich auch schon SATA-USB-Adapter die nicht gingen...

Mehr Idee aktuell nicht.

Gruß, Joachim

[Sammy51]

Vielen Dank für die schnelle Antwort!

1.) Bezüglich der Windoof/Linux Idee: Bevor der NUC (früher FHEM) Neu aufgesetzt ist (aus dem ist die SSD) hab ich nur ein lange nicht mehr genutztes 2007er ThinkPad mit Linux Mint (seitdem mir das 2011er MacBook zur VErfügung steht ist das fürs Sofa "netter").

Damit könnte ich drauf gucken - oder wenn Du ein Tipp ein Anleitungs-Fundstück hast auch das klonen darüber nochmal versuchen.
Das Windoof Tool hat immerhin ext4 als solches erkannt insofern war ich optimistisch.

2.) Um falls das nicht hilft das USB Case auszuschließen - hast Du oder hat einer von Euch positive Erfahrungen mit einem konkreten Modell? WEnn das USB-C hätte fände ich es elegant weil zukunftsicherer (und irgendwan vielleicht weniger Performance Verschwendung bzgl der integrierte SSD wenn der raspi mal upgegradet wird).

[MadMax-FHEM]

Naja, besser mal prüfen...

Aber war ja nur eine mögliche Idee...

Ich habe folgendes im Einsatz: https://forum.fhem.de/index.php/topic,112704.msg1070259.html#msg1070259

Aber nix mit USB-C weil ja kein PI das hat, also als Datenanschluss...

Gruß, Joachim

[Sammy51]

Ric

Naja, besser mal prüfen... Aber war ja nur eine mögliche Idee...

Ich habe folgendes im Einsatz: https://forum.fhem.de/index.php/topic,112704.msg1070259.html#msg1070259
Aber nix mit USB-C weil ja kein PI das hat, also als Datenanschluss...

Richtig - aber vielleicht ja der Rasperry 5 oder ein anderes künftig verwendetes System.
Deswegen habe ich ja das Ugreen mit USB-C und USB-C=>USB-A Kabel besorgt. Das würde ja vermutlich "künftig" auch mit USB-C auf USB-C Kabel "laufen".

Leider kannst Du natürlich recht haben das das Problem an dem Ding liegt

Nachtrag: Am Linux-Mint Thinkpad sieht die SSD übrigens ok aus. Zeigt die rootfs partition mit /opt/fhem usw.   sowie die boot Partition (die auch windows anzeigen konnte). Bislang nutzt die wohl nicht die denkbare maximale Größe (ein großer TEil der SSD ist ungenutzt da die Partitionsgröße zunächst 1:1 von der SD-Karte übernommen wurde.

[MadMax-FHEM]

Naja, ich hatte schon mindestens einen SATA-USB-Adapter der nicht geht/ging...

Aber ich weiß nicht mehr genau wie sich das "optisch" geäußert hat...
...gefühlt kommt es der Beschreibung nahe...

Aber auch falsche Partitionen oder falsche Einträge in der /boot/cmdline.txt bzw. /etc/fstab sehen so aus...

Das könnte nat. auch noch sein. Aber wenn von einem "offiziellen" Raspbian-Download dann ein Clon erstellt wird sollte das passen (daher habe ich das nicht als Idee aufgeführt).

Weil da dann die part-uuid drin steht und die wird normalerweise mit geclont...

Aber es schadet auch nicht das zu prüfen.

Also mal in der /boot/cmdline.txt schauen und in /etc/fstab
EDIT: auf der SSD natürlich

Und mit:

Code Auswählen Erweitern


sudo blkid


vergleichen.
Also damit wird ausgegeben welche UUIDs die Partitionen haben.
Aber halt auch wieder auf Linux
EDIT: natürlich wenn die SSD steckt

Aber das sollte auch gehen, wenn du den PI mit SD bootest und DANACH die SSD steckst.

Dann kannst du auch sehen, ob die erkannt wird/wurde...

Ich denke nicht dass dabei die ja eigentlich doppelten UUIDs "Probleme" machen...

Und die sollten "doppelt" sein.
Wenn nicht, dann hast du das Problem evtl. schon gefunden...

Und auch, wenn die Platte gar nicht auftaucht (außer wie geschrieben: "Durcheinander" wegen doppelter UUIDs)...
EDIT: wenn du ganz sicher gehen willst, dann eben an einem Linux-Rechner... Live-Boot geht nat. auch...

Gruß, Joachim

[Otto123]

Einfach mit dem "Standard" Imager mal das neue Raspbian OS auf die externe Platte schreiben und versuchen booten. Damit man weiß ob es überhaupt geht?
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

[Sammy51]

Wenn die SSD am Linux-Mint-Notebook hängt kann ich folgendes auslesen:

Code Auswählen Erweitern

sudo blkid
/dev/sdc1: LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat"
/dev/sdc2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4"

boot/cmdline.txt

Code Auswählen Erweitern

console=serial0,115200 console=tty1 root=PARTUUID=a8c25ad2-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

/etc/fstab/

Code Auswählen Erweitern

proc            /proc           proc    defaults          0       0
PARTUUID=a8c25ad2-01  /boot           vfat    defaults          0       2
PARTUUID=a8c25ad2-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

[ch.eick]

Hallo zusammen,

ich habe seit vorgestern das Raspberry OS 64  auf ein RPI4 mit 4G Ram auch bereits von SSD gebooted, also komplett ohne sd Card.
Beim ersten Versuch lief es sau langsam und die SSD hat nur geblinkt. Abhilfe hat dann der "usb-storage.quirks" Eintrag in der cmdline.txt gebracht.

ich denke mein Controller ist nicht so super für USB3 geeignet, wodurch der Treiber nicht richtig arbeiten kann.
Nun habe ich zwar nicht die maximale SSD Geschwindigkeit, aber hat schon einen mega Schub gebracht.

Die Migration von Docker ist noch nicht vollzogen. Die Daten der Container liegen bereits länger auf der SSD, aber halt noch mit Boot von der sd Card.
Für Docker denke ich muss ich dann noch mal das docker-compose mit den 64 Bit Images machen, aber das teste ich besser mit einer Kopie der Daten in einem anderen Verzeichnis.
Habt Ihr da noch irgendwelche Tips?

Code Auswählen Erweitern


pi@raspberrypi:/media/pi/boot $ cat cmdline.txt
usb-storage.quirks=152d:0578:u console=serial0,115200 console=tty1 root=PARTUUID=af40e462-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles


Geholfen haben mir diese zwei externen Links
https://forum.openmarine.net/showthread.php?tid=2648
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931&sid=3c0ef7eba15d4c60f6d19017224abf16

Gruß
    Christian

[MadMax-FHEM]

@Sammy51:

leider sieht man die part-uuid nicht in deiner Ausgabe...

Komisch.

Daher kann man nat. nicht sehen, ob die passt.

Probier das doch mal wie vorgeschlagen am PI.
Also mit SD OHNE SSD booten und dann SSD stecken und auch den "sudo blkid" ausführen...

@ch.eick: hier geht es allerdings um einen PI3...

Gruß, Joachim

[Sammy51]

@Sammy51:
Probier das doch mal wie vorgeschlagen am PI.
Also mit SD OHNE SSD booten und dann SSD stecken und auch den "sudo blkid" ausführen...

OK - probiere ich nachher geht dann ja ohne das alte linux mit über ssh (eigentich muss ich jetzt unter windoof Fotos bearbeiten um Weihnachtsgeschenke zu generieren)
Was ist dann die einfachste Methode die files einzusehen?

[ch.eick]

@ch.eick: hier geht es allerdings um einen PI3...

Sorry, die Begeisterung ist mit mir durchgegangen...bin schon wieder weg