Hallo Zusammen,
eine Frage mal so zwischendurch.....ist das die richtige Vorgehensweise um von microSD auf SSD oder USB Stick zu gehen?:
1.man nimmt eine microsd karte und haut da zb das neue buster light drauf....dann wie immer rein in raspi...booten lassen ssh datei nicht vergessen
2. dann folgendes in der Konsole eingeben nacheinander
sudo apt-get update && sudo apt-get upgrade
echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
sudo reboot
vcgencmd otp_dump | grep 17:
dann muss folgendes ausgegeben werden:
17:3020000a
Wenn das kommt raspi ausmachen.....
Auf den USB Stick oder SSD Platte mit etcher das neueste buster light draufkopieren lasssen
Dann microSD raus aus Raspi und USB Stick oder SSD an Raspi dran....und hochbooten lassen....ungefähr 2-3 Minuten Dauer
Dann sollte man wenn man über Putty die ip des pis eingibt wieder am Konsolen Prompt stehen....
Nun fhem wie gewohnt installieren....
Gruss
Ja, sieht gut aus. Die Programmierung kannst Du auch mit deiner jetzigen Konfiguration / SD Karte machen.
Im Vorfeld, wenn das System auf SD Karte läuft, prüfen, dass die SSD Disk vom System erkannt wird. Z.B. mit
sudo fdisk -l
SSD einstecken
sudo fdisk -l wieder. Vergleichen. Ist da sda (oder sdb oder sdc, abhängig von was schon vorhanden war) dazu gekommen, und mit der richtigen Grösse?
Zitat von: amenomade am 08 Juli 2020, 23:30:31
Ja, sieht gut aus. Die Programmierung kannst Du auch mit deiner jetzigen Konfiguration / SD Karte machen.
Das ist ein guter Tipp für alle. So muss ich nicht wieder eine neue microSD nehmen.
MadMax-FHEM meinte noch, wenn ichs richtig verstanden habe...wenn man USB nicht mehr nutz bzw. wieder die microSD verwenden will soll man diesen Eintrag aus der /boot/config.txt wieder herausnehmen:
program_usb_boot_mode=1und diesen wenn man mit USB arbeitet soll man eintragen. damit wird verhindert das immer nach der microSD gesucht wird
dtoverlay=sdtweak,poll_onceGruss
Zitat von: Kusselin am 09 Juli 2020, 09:11:23
Das ist ein guter Tipp für alle. So muss ich nicht wieder eine neue microSD nehmen.
Ja klar, es geht ja nur darum eben den Eintrag USB-Boot ins EEPROM zu bekommen...
...da ist es dem PI egal mit welcher SD das passiert ;)
Zitat von: Kusselin am 09 Juli 2020, 09:11:23
MadMax-FHEM meinte noch, wenn ichs richtig verstanden habe...wenn man USB nicht mehr nutz bzw. wieder die microSD verwenden will soll man diesen Eintrag aus der /boot/config.txt wieder herausnehmen:
program_usb_boot_mode=1
Naja du kannst ihn auch drin lassen...
...ABER: JEDER PI3 in den du dann DIESE SD steckst wird halt "umprogrammiert" ;)
Tut nicht weh...
...ist aber nicht immer gewollt ;)
Zitat von: Kusselin am 09 Juli 2020, 09:11:23
und diesen wenn man mit USB arbeitet soll man eintragen. damit wird verhindert das immer nach der microSD gesucht wird
dtoverlay=sdtweak,poll_once
Wenn du im Internet suchst, also entweder (wie ich damals): warum habe ich seit SSD-/USB-Boot zusätzliche Last auf einem PI (mit Angabe des Prozesses, den ich jetzt nicht mehr weiß, weil ich habe das Problem ja nicht mehr :) )
ODER: nach "dtoverlay=sdtweak,poll_once" dann kannst du nachlesen was es genau tut...
Aber wie (auch per PM ;) ) schon geschrieben, hatte ich unnötige Last von immer demselben Prozess (irgendein "worker") und das hat mich gestört...
...da steigt man auch schnelle SSD um und dann "sowas" :-\ ;)
Gruß, Joachim
P.S.: und du siehst -> besser "hier", sonst "muss" ich u.U. alles doppelt schreiben ;)
Zitat von: MadMax-FHEM am 09 Juli 2020, 10:02:50
...ABER: JEDER PI3 in den du dann DIESE SD steckst wird halt "umprogrammiert" ;)
d. h. durch die Einträge...die ja auf der Karte in der config.txt drinne sind habe ich das dann.... ich ziehe die Karte raus...stecke sie in einen anderen Pi3 der noch nicht auf USB ist-> ist dieser automatisch nach dem Booten auch auf USB getrimmt...richtig?
Also wenn Karte raus aus dem Pi udn ich es nicht will das die anderen Pi3´s auch USB haben sollen dann vor dem einsteckemn den Eintrag
program_usb_boot_mode=1 rausnehmen....
Gruss
Wenn man mit seiner gesamten Installation (ohne neue Aufsetzen) von der SD-Karte auf USB/SSD umziehen will. Hier ist eine super Anleitung, hat bei mir ohne Probleme funktioniert
https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/ (https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/)
Zitat von: EinEinfach am 09 Juli 2020, 10:16:10
Wenn man mit seiner gesamten Installation (ohne neue Aufsetzen) von der SD-Karte auf USB/SSD umziehen will. Hier ist eine super Anleitung, hat bei mir ohne Probleme funktioniert
https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/ (https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/)
Mache ich auch so ähnlich...
Nutze statt rsync aber tar und nehme das auch als Fullbackup (wobei ich von "Full-Backups" wenig halte)...
Das hier sollte auch (wenn überhaupt) mit Bedacht getan werden (ein "normaler" raspi-update ist schon ausreichend)
Zitat
Dann wird die Firmware noch auf den aktuellsten Stand gebracht, mit folgendem Befehl. Hierbei wird immer die aktuellste, und nicht unbedingt die stabilste, veröffentlichte Version eingespielt. Bei einem bereits laufenden System sollte es im Normalfall nicht nötig sein, diesen Befehl auszuführen.
sudo BRANCH=next rpi-update
Und ja, bei der Gelegenheit passe ich auch die BOOT-Partition an (weil man ja meist Platz hat)...
...allerdings ist da schon einiges an Linux-Know-How nötig ODER man vertraut einfach bei copy/paste, dass das alles beim eigenen System auch einfach so passt...
...und wenn nicht, dann ist man auf jeden Fall tief in den Linux-Untiefen unterwegs um das wieder glatt zu kriegen...
Ein Umzug einfach die SD auf die SSD zu klonen ist da deutlich einfacher... :)
Und (wenn es stimmt), dann wird zumindest die rtfs-Partition vergrößert (oder lässt sich einfach vergrößern)...
(wobei schon sehr pauschal von neuem PI macht das eh und PI vorbereiten gesprochen wird / wäre besser, wenn genau genannt wird bei welchem PI was zu tun ist, weil wenn man das in ein paar Jahren liest, dann ist eben neu nicht gleich neu usw. ;) und der aktuelle PI4 macht das [wenn alles aktuell ist ;) ] tatsächlich "einfach so")
Gruß, Joachim
Zitat(wobei schon sehr pauschal von neuem PI macht das eh und PI vorbereiten gesprochen wird / wäre besser, wenn genau genannt wird bei welchem PI was zu tun ist
Ziemlich am Anfang steht welcher PI hier benutzt wird:
ZitatBooten von USB funktioniert mit dem Raspberry Pi 4 derzeit noch nicht.
Diese Anleitung funktioniert daher nur mit dem Raspberry Pi 3 oder 3B+.
Dann ist das auch nicht (mehr) ganz richtig: PI4 kann das mittlerweile! und das sogar ohne "Hacks"... :)
Gruß, Joachim
Zitat von: EinEinfach am 09 Juli 2020, 10:16:10
Wenn man mit seiner gesamten Installation (ohne neue Aufsetzen) von der SD-Karte auf USB/SSD umziehen will. Hier ist eine super Anleitung, hat bei mir ohne Probleme funktioniert
https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/ (https://bitreporter.de/raspberrypi/raspberry-pi-os-von-sd-karte-auf-usb-stick-uebertragen-und-booten/)
Sehr kompliziert. Wenn dann, lieber rpi-clone (http://"https://github.com/billw2/rpi-clone") nutzen. Der macht alles selbst (Partitionen, rsync, partitionID, usw) bis auf rpi-update (was ich sowieso nicht empfehlen würde) mit einem einzigen Befehl:
sudo rpi-clone sda Und zwar ohne UI, nur über die console, und mit einer sauberen "Exclude"-Liste
ZitatWenn dann, lieber rpi-clone nutzen.
Wenn das tatsächlich so einfach geht, dann mal wieder was gelernt! Probiere ich nächstes mal aus.
Danke
Hallo zusammen,
ich habe auch einen Pi4 mit einer SSD bereits angeschlossen, jedoch habe ich es bisher noch nicht geschafft von dieser USB zu Booten.
@MadMax-FHEM koenntest Du mir mal einen Link zum PI4 mit boot von SSD geben, der auch zum Erfolg fuehrt?
Gruss
Christian
Zitat von: ch.eick am 13 Juli 2020, 13:58:10
Hallo zusammen,
ich habe auch einen Pi4 mit einer SSD bereits angeschlossen, jedoch habe ich es bisher noch nicht geschafft von dieser USB zu Booten.
@MadMax-FHEM koenntest Du mir mal einen Link zum PI4 mit boot von SSD geben, der auch zum Erfolg fuehrt?
Gruss
Christian
Selbst getestet: nein.
Mein PI4 macht noch "Dual-Platte" ;)
Also /boot auf SD
und /rtfs auf SSD
Aber soweit ich das verfolgt habe: bis vor kurzem musste ein "Entwickler" EEPROM genommen werden, soll aber im aktuellen jetzt stable sein.
Heißt: sudo rpi-update -> neueste FW/EEPROM sollte eigentlich mit Buster (gelesen) und dem neuen PI-OS dann booten.
Leider kann ich da nur auf die üblichen Kanäle verweisen: goolge Suche oder bei Raspberry PI schauen...
EDIT: bzw. beim PI4 wohl (auch) sudo apt install rpi-eeprom und sudo rpi-eeprom-update
EDIT: vcgencmd bootloader_version zeigt die Version und die muss wohl 15.06. oder neuer sein...
Gruß, Joachim
Danke fuer den Update, das ging ja super schnell.
i@raspberrypi:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Do 16. Apr 17:11:26 UTC 2020 (1587057086)
LATEST: Do 16. Apr 17:11:26 UTC 2020 (1587057086)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad
pi@raspberrypi:~ $ vcgencmd bootloader_version
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086
Noch ein update:
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.
Gruß, Joachim
Zitat von: MadMax-FHEM am 13 Juli 2020, 14:26:36
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 :-)
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?
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
Zitat von: MadMax-FHEM am 13 Juli 2020, 17:01:40
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....
## 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
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
vcgencmd otp_dump | grep 17:
17:3020000a
2.) Raspberry PI heruntergefahren 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 (https://www.ubackup.com/de/klonen/sd-karte-auf-groessere-kopieren.html)
6.) USB SSD an RPI angesteckt
7.) Stromversorgung RPI "aktiviert"
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
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).
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
Ric
Zitat von: MadMax-FHEM am 11 Dezember 2020, 16:39:41
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 (https://www.amazon.de/UGREEN-Festplattengeh%C3%A4use-Geh%C3%A4use-unterst%C3%BCtzt-werkzeugfreie/dp/B07D2BHVBD/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1FHV9I8ETXAQM&dchild=1&keywords=ugreen+festplattengeh%C3%A4use+2%2C5+zoll&qid=1607701895&s=computers&sprefix=ugreen%2Ccomputers%2C186&sr=1-1-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUExMkhRVUsyWUg0WUs2JmVuY3J5cHRlZElkPUEwODk4MzM5M1ZHNUo0Szk2NVFZMCZlbmNyeXB0ZWRBZElkPUEwNjE2OTAwMUszVElNVENYMjM1OSZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU=) 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.
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:
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
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
Wenn die SSD am Linux-Mint-Notebook hängt kann ich folgendes auslesen:
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
console=serial0,115200 console=tty1 root=PARTUUID=a8c25ad2-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
/etc/fstab/
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
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?
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://forum.openmarine.net/showthread.php?tid=2648)
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931&sid=3c0ef7eba15d4c60f6d19017224abf16 (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931&sid=3c0ef7eba15d4c60f6d19017224abf16)
Gruß
Christian
@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
Zitat von: MadMax-FHEM am 11 Dezember 2020, 17:24:51
@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?
Zitat
@ch.eick: hier geht es allerdings um einen PI3...
Sorry, die Begeisterung ist mit mir durchgegangen...bin schon wieder weg :-)
Zitat von: ch.eick am 11 Dezember 2020, 17:36:04
Sorry, die Begeisterung ist mit mir durchgegangen...bin schon wieder weg :-)
War nicht so gemeint...
Wollte nur vermeiden, dass "irgendwas" in cmdline.txt eingetragen wird was es (verm.) nicht "besser" macht... ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 11 Dezember 2020, 17:24:51
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...
SSD an per SDCard gebooteten PI zeigt folgendes "sudo blkid"
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="a8c25ad2-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4" PARTUUID="a8c25ad2-02"
/dev/mmcblk0: PTUUID="a8c25ad2" PTTYPE="dos"Ist die SSD nicht wirklich bei - oder?
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 59,5G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 59,2G 0 part /Kann ich die jetzt einfach abstecken oder sollte ich die dennoch vorher irgendwie "auswerfen"?
Heißt das der Adapter tuts nicht oder zumindest nicht in Kombination mit dem RPI3b?
Scheint wohl nicht dabei zu sein.
Würde daher auch vermuten, dass der Adapter nicht tut...
Kannst einfach abstecken.
War ja nicht mal gemounted (und selbst wenn, wurde ja nichts damit gemacht)...
EDIT: Spannungsversorgung ist aber ausreichend/gut!?
Gruß, Joachim
Wie merke ich das? LED auch der SSD bzw. des SSD-Gehäuses leuchtet.
Netzteil ist eins vom Samsung Smarthone 2A glaube ich.
Man nimmt doch kein Handy-Ladegerät!
Naja, entweder lässt man sich "throddelt" ausgeben oder man schaut auf die rote LED.
Die darf nicht "blinken"...
vcgencmd get_throttled
https://www.raspberrypi.org/documentation/raspbian/applications/vcgencmd.md
Nimm lieber ein richtiges Netzteil!
Gruß, Joachim
Hmm.. rot blinken tut da nichts ... nur grün und die zweite led ist aus (mit und ohne angesteckte SSD).
Hab SSD jetzt nochmal angesteckt.
vcgencmd get_throttled
throttled=0x50005
EDIT: Bin zu blöd oder zu müde die Übersetzung binar + Tabelle und so zu verstehen :(
Was meinst du mit 2te LED is aus?
Keine rote LED?
Dann ist das wohl ein Spannungsproblem...
Bzgl. 0x50005 steht ja beschrieben.
Müsste ich auch erst mal schauen...
EDIT: 0x50005 -> under voltage und throtteld (wenn ich mich nicht verkuckt hab). Da hast du's ja...
EDIT: ich bin mit denen ganz zufrieden https://www.amazon.de/Aukru-Micro-USB-Ladeger%C3%A4t-Stromversorgung-Raspberry/dp/B01566WOAG/
EDIT: wie kann man einen "wichtigen" Server, der 24/7 laufen soll mit einem Handy-Ladegerät (und noch dazu "nur" 2A) betreiben ;)
Gruß, Joachim
Alles klar - da hattest Du noch einen guten Gedanken. DAnn könnte das SSD Gehäuse doch noch passen (falls nicht auch das dennoch problematisch ist).
Was für ein Netzteil ist denn zu empfehlen? Das offizielle hat 2,5 A tuts aber vermutlich. Inoffizielle mit 3A sind vermutlich nicht zwingend besser - oder?
Zitat von: Sammy51 am 11 Dezember 2020, 20:29:41
Was für ein Netzteil ist denn zu empfehlen? Das offizielle hat 2,5 A tuts aber vermutlich. Inoffizielle mit 3A sind vermutlich nicht zwingend besser - oder?
Hab oben editiert.
Ich habe an (fast) allen PIs dieses dran und keine Probleme...
Nicht nur wegen der 3A somdern halt Preis/Leistung :)
Ja, ich würde auch erst noch mal mit dem SATA-USB den du hast probieren...
...kann man immer noch tauschen ;)
Gruß, Joachim
Ob das konstant tauglich gebaut wurde - Dein NEtzteil? Gibt dazu zuletzt etliche schlechte Bewertungen - es würde nicht funktionieren sobald man USB Festplatten anschließt.
Also ich hab meine zuletzt vor knapp 2 Jahren gekauft.
UND: du hängst ja KEINE Festplatte sondern eine SSD dran!
Festplatte zieht ja deutlich Strom! Das hat dann nichts mehr mit dem Netzteil zu tun, sondern da liefert der USB-Anschluss des PI nicht genug...
Also bei mir gab es noch nie Probleme.
Ich hatte 3 PI mit SSD damit laufen.
1 habe ich auf POE umgestellt, lief aber bis dahin auch problemlos...
Und aktuell noch 3 ohne SSD (mit SD, sind nur Testsysteme bzw. mein Magic Mirror) damit laufen...
Aktuell habe ich noch einen PI3 als tvheadend mit SSD und diesem Netzteil...
EDIT: aber besser als dein Ladenetzteil ist es allemal ;) Du kannst nat. auch ein Original PI-Netzteil nehmen... Ich hab ja nix davon wenn du genau DIESES nimmst ;)
Gruß, Joachim
Gut dann tuts meiner ab Montag/Dienstag auch damit vermutlich :)
BTW - ist es bei Bedarf, wenn der 3b doch mal zu langsam wird oder seinen Geist aufgibt einfach möglich die Platte /SD-KArte an einen RPI4 zu stecken? Oder ginge das nicht ohne weiteres?
Das neue Netzteil ist da ... folgende Verbesserung:
1.) vcgencmd get_throttled
throttled=0x0
2.) Wenn ich im laufenden Betrieb die SSD anstecke wird diese zusätzlich erkannt
3.) sudo shutdown now - funktioniert dann aber nur "halb" wirklich aus geht das Ding nicht.
4.) Neustart ohne SD mit SSD gelingt nicht ... dann rote lampe durchgängig ... grüne blinkend
5.) Neustart wieder mit SD geht weiterhin
Was nun? Nochmal neu duplizieren von SD auf SSD mit anderem Tool?
(versuche parallel dualboot auf dem macbook einzurichten mit linux .. das scheitert bislang inbesondere am Wlan treiber)
Wenn die SSD steckt poste doch mal ein "sudo blkid"...
Und bitte noch mal (damit ich leichter vergleichen.kann :) ) /boot/cmdline.txt und /etc/fstab
Eigentlich ja von der SSD aber weil geclont sollte das passen...
...bzw. gleich sein...
Gut, eigentlich auch blkid... ;)
Ganz aus geht der PI eh nie!
Und somit auch angesteckte USB-Zeugs nicht (wirklich)...
Wie lange hast du gewartet?
Also nach shutdown.
Dann Spannung weg, SD raus und Spannung wieder dran...
Und dann warten...
Mit SSD dauert es etwas...
Bei mir blinkt abwechselnd (oder so) die grüne PI-LED und die "Zugriffs-LED" des SATA-USB-Adapters...
Wenn die SSD schon steckt und erkannt wird?
Dann kannst du sie ja mal mounten und schauen was drauf ist...
EDIT: zumindest hast du ja schon mal ein vernünftiges Netzteil... ;)
Gruß, Joachim
Ok - das gucke ich jetzt genauer an. Jetzt gar mit Linux auf dem alten Mac (Wlan broadcom running).
Vielleicht hab ich auch schlicht nicht lange genug gewartet wenn Du sagst das dauert lange.
Hätte gedacht ssd wäre trotz usb2 des RP3b nicht langsamer als SD.
Wie kann ich denn über ssh am einfachsten die /boot/cmdline.txt und /etc/fstab von der SSD am Raspi auslesen / einsehen?
IDs scheinen nicht ganz gleich:
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4AD7-B4D5" TYPE="vfat" PARTUUID="a8c25ad2-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2887d26c-6ae7-449d-9701-c5a4018755b0" TYPE="ext4" PARTUUID="a8c25ad2-02"
/dev/mmcblk0: PTUUID="a8c25ad2" PTTYPE="dos"
/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"
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
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?
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:
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:
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
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
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)
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
Zitat von: MadMax-FHEM am 15 Dezember 2020, 21:27:06
Ansonsten am PI mounten und die Dateien bearbeiten:
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
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.
/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
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
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 ::)