Benutzung eines USB Sticks oder einer USB Platte für die Rootpartition

  • Hi,

    ich draenge mich mal dazwischen.

    Kurze Hinweise:
    Dein link zum Backup, verweist zu " The requested page cannot be found.".

    (vllt auch schon erwaehnt):
    sudo gdisk /dev/sda
    SPOILER:
    root@jessie:/backup# gdisk /dev/sdc
    Die Endungen sind unterschiedlich. Vllt nicht fuer jeden verstaendlich.

    Ich bin die step bei step Anleitung durch gegangen.
    Erst mal vorweg, die Anleitung ist gut Beschrieben. Mittlerweile...
    Als ich es vor ca 3 monaten es mal ausprobiert habe, hatte ich ueberhaupt ka. Ist zwar immer noch so aber ist nicht ganz hoffnungslos.

    Der wohl sinnigste Hinweis ist,
    "sudo cp /boot/cmdline.txt.sd /boot/cmdline.txt".
    Damit ist es sehr schnell wieder zurueck gesetzt.
    Und wenn keiner einen usb sd karten dingens hat, der koennte es auch per Linux am PC umaendern. Oder Windows.

    Nach dem Start vom USB hatte ich viele "failed" beim booten. VPN, Samba, Seafile und weiss der kuckuck was noch. Also bin ich wieder zurueck.
    Folgende Fehlermeldungen, bekomme ich beim kopier vorgang:

    Ich habe meine externe Festplatte unter /home/username/externe eingebunden und die ebenfalls ausgeschlossen.


    Da der USB Stick unter sdb1 ausgegeben wird und ich eine USB Festplatte noch Angeschlossen habe, habe ich das in der "cmdline.txt" und "fstab" mit "root=PARTUUID=7C32EB25-0462-429F-BF92-90FFD81FC8FE" eingebunden.

    Wie gesagt, der Start funktioniert. Nur mit saemtlichen Fehlermeldungen. Habe versucht, zB die ccnet.sock manuell zu kopieren. Das funktionierte allerdings nicht, da .. "cp ccnet.sock /mnt/

    cp: cannot open ‘ccnet.sock’ for reading: No such device or address" ... ka, wieso er das nicht kopieren moechte.

    Ich kucke mal weiter, und warte auf Antwort.

    Vielen Dank!

    Edit:
    In der fstab, habe ich es ohne "root=" eingefügt.

    Einmal editiert, zuletzt von DanSman (27. Mai 2016 um 13:35)

  • Benutzung eines USB Sticks oder einer USB Platte für die Rootpartition? Schau mal ob du hier fündig wirst!


  • Danke für den Hinweis. Habe ich beides eben korrigiert.

    Zitat

    Nach dem Start vom USB hatte ich viele "failed" beim booten. VPN, Samba, Seafile und weiss der kuckuck was noch. Also bin ich wieder zurueck.

    Du solltest besser alle Services die autf Deiner Pi laufen vor dem kopieren stoppen. Also samba, vpn, seafile, und alle anderen Kuckucks :lol: .

    Zitat


    Folgende Fehlermeldungen, bekomme ich beim kopier vorgang:

    Die ganzen Socker Dinger existieren weil Deine Kuckucks (s.o.) laufen. Die solltest Du wir schon gesagt vorher stoppen. Das nehme ich gleich noch ins Tut mit auf.

  • Da ich nicht genau weiß, was ich alles ausstellen muss, werde ich das mal an einem PC ausprobieren. Müsste ja auch gehen.

    Stick und SD Karte an den PC und alles rüber schicken.

    Melde mich dann nochmal.

    PS. In einem spoiler ist noch sdc [FACE SAVOURING DELICIOUS FOOD]

  • Klingt sehr merkwürdig :s


    Habe es jetzt am PC gemacht.

    Was hast Du genau gemacht?

    Zitat

    Kommen die gleichen Fehlermeldungen.

    Beim Kopieren oder beim Starten nach der Umstellung?

    Zitat

    Habe auch dann keine sudo Berechtigungen mehr, für mein User.

    Nach dem Starten nach der Umstellung? Dann wurde nur unvollständig kopiert.

  • Da bin ich noch einmal.
    Habe einige male das Script laufen lassen und das läuft auch vollständig ohne eine Fehlermeldung durch.
    Das Ergebnis ist immer das gleiche. Bootet zum Schnarchen langsam und die /-Partition ist nur lesbar.
    Habe das PiDrive auch vollständig am RasPi partitioniert und formatiert, keine Besserung.

    Habe ein Foto vom RasPi gemacht und die Laufwerke an meinen Laptop gepackt und einige Protokolle eingetütet (s.Anhang)

    Ich weiß nicht was bei mir falsch läuft.
    Das Script läuft fehlerfrei aber dennoch werde ich so nicht glücklich.

    :helpnew: Bitte hilf mir. :helpnew:


    Gruß reinhard

  • Sehr gut das Du alle wichtigen Infos geliefert hast :thumbs1:

    In der cmdline.txt.hdd steht

    Code
    root=PARTUUID=BE9E2BE4-36E8-494E-A025-E3AA4A3F6B0D

    In der /etc/fstab steht

    Code
    PARTUUID=F89B1E92-CB3E-4BF3-843E-A7C731F62CDF

    Die PARTUUID muss identisch sein. Du bekommst sie mit

    Code
    sudo sgdisk -i 1 /dev/sda | grep unique | cut -d ' ' -f 4

    heraus. Welche UID bekommst Du raus? Das solltest Du korrigieren und noch mal versuchen Deine Pi zu starten.

    c64emulator hat hier von Problemen mit einer read only gemounteten SD Platte berichtet. Seine Lösung war UUID und nicht PARTUUID zu benutzen. Mir scheint Du hast ein ähnliches Problem. Keine Ahnung warum ich das bei mir nicht nachvollziehen kann :s

    Hier habe ich noch den rootdelay Parameter erwähnt. Den würde ich auch noch mal mit aufnehmen.


  • Klingt sehr merkwürdig :s

    Was hast Du genau gemacht?

    Beim Kopieren oder beim Starten nach der Umstellung?

    Nach dem Starten nach der Umstellung? Dann wurde nur unvollständig kopiert.

    Soooo...

    Hatte es als erstes mit deiner Variante probiert.
    Danach habe ich es per cp -r auf den Stick gezogen, auf dem PC.
    3er versuch war mit Gparted am PC, die Partition von der sd karte auf den usb stick.

    Da ich noch eine Festplatte benutze, habe ich "PARTUUID=...." benutzt.
    Da kam wieder die gleiche Fehlermeldung. Dann habe ich es in /dev/sdb1 umgenannt.
    Klappte wunderbar. ;)
    Ich gehe davon aus, das alle drei Varianten geklappt haetten, wenn ich es gleich in "/dev/sdb1" genannt haette.

    Laeuft jetzt also alles. Habe nur das Gefuehl, das es laenger beim Booten braucht. Kann aber auch am Stick liegen.

    Jetzt muss ich nur noch dein Backup-Programm in gang kriegen. Das habe ich auch mal versucht. Habe es nie hinbekommen.

    Da ich jetzt Theoretisch immer die SD Karte und den Stick ein Image erstellen muss, wuerde ich es gerne anders machen. Zuvor habe ich die SD Karte immer am PC rein geschoben und per dd ein Image erstellt. Koennte jetzt auch sd karte und stick in einen Ordner mounten aber eigentlich, moechte ich dein raspibackup benutzen. Damit jedes Wochenende Sonntags ein Backup erstellt wird.
    Inwiefern, aendern sich denn die Boot Dateien/Partition? Wenn sich da nichts aendert, dann wuerde ja auch nur der Stick reichen.
    Der Kernel liegt doch auf dem Stick oder?

    Da die boot partition im /boot liegt, waere es ja jetzt am besten im Betrieb das Backup zu machen oder?


    Danke dir, fuer diese Anleitung!

  • Die Bootpartition braucht man prinzipiell nur einmal zu sichern da sie sich so gut wie nie ändert. Allerdings kann es durch einen Firmwareupdate doch manchmal vorkommen :fies:
    raspiBackup sichert sowohl die Bootpartition als auch eine externe root Partition ;) . In der nächsten Version werden auch Hardlinks benutzt um die Bootpartitionen nicht jedesmal sichern zu müssen. Ob man ein laufendes System sichern soll ist immer wieder Diskussionsthema. Wenn man allerdings vorher alle aktiven Services wie sql, apache, samba, seafile, ... stoppt habe ich bislang noch nie ein Problem beim Restore gehabt. Der sicherste Backup ist aber definitiv immer noch ein Offlinebackup.
    Das Thema ist jetzt aber OT. Bitte einen neuen Thread aufmachen wenn Du weitere Fragen zu raspiBackup hast :)


  • In der cmdline.txt.hdd steht

    Code
    root=PARTUUID=BE9E2BE4-36E8-494E-A025-E3AA4A3F6B0D

    In der /etc/fstab steht

    Code
    PARTUUID=F89B1E92-CB3E-4BF3-843E-A7C731F62CDF

    Das war ein Fehler von mir. Waren zu dem Zeitpunkt identisch. Sorry! aber hier steckt das Problem mit der Schreibberechtigung.

    Die PARTUUID muss identisch sein. Du bekommst sie mit

    Code
    sudo sgdisk -i 1 /dev/sda | grep unique | cut -d ' ' -f 4

    heraus. Welche UID bekommst Du raus? Das solltest Du korrigieren und noch mal versuchen Deine Pi zu starten.

    c64emulator hat hier von Problemen mit einer read only gemounteten SD Platte berichtet. Seine Lösung war UUID und nicht PARTUUID zu benutzen. Mir scheint Du hast ein ähnliches Problem. Keine Ahnung warum ich das bei mir nicht nachvollziehen kann :s

    Habe übers Wochenende mal etliches probiert und folgendes herausgefunden:

    Es ist nicht egal, mit welchem Rechner du die UUID ermittelst (Laptop, Lenovo W520 mit Mint 17.3 oder dem RasPi). Und es spielt eine Rolle wie du sie ermittelst (mit 'blkid' oder 'sgdisk'). Weiter spielt die Groß-/Kleinschreibung eine Rolle.

    Habe alle möglichen Kombinationen durchexerziert. :geek:

    Ergebnis:

    In der 'cmdline.txt' steht die mit

    Code
    sudo sgdisk -i 1 /dev/sda | grep unique | cut -d ' ' -f 4

    ermittelte UUID als PARTUUID benannt in Großbuchstaben.

    Code
    ... root=PARTUUID=F89B1E92-CB3E-4BF3-843E-A7C731F62CDF ...

    In der 'fstab' steht die auf dem RasPi mit

    Code
    blkid | grep sda1 | cut -d ' ' -f 4

    ermittelte PARTUUID ohne "" in Kleinbuchstaben.

    Code
    proc                                           /proc    proc    defaults             0   0
    /dev/mmcblk0p1                                 /boot    vfat    defaults             0   2
    #
    # PARTUUID= mit 'blkid' auf dem Pi ermittelt
    # /dev/sda2
    PARTUUID=49bb85a7-d5a8-4f9a-920c-de82d6cfc6af  none     swap    sw                   0   0
    # /dev/sda1
    PARTUUID=f89b1e92-cb3e-4bf3-843e-a7c731f62cdf  /        ext4    defaults,noatime     0   1
    # /dev/sda3
    PARTUUID=228dde32-5511-45c3-beb9-235482ebc5c6  /home    ext4    defaults,noatime     0   0

    In dieser, und nur in dieser Kombination habe ich ein bescheibbares System. :bravo2:


    Hier habe ich noch den rootdelay Parameter erwähnt. Den würde ich auch noch mal mit aufnehmen.

    Den Parameter 'rootdelay' habe ich probiert aber ohne spürbares Ergebnis und darum erst einmal weggelassen.

    :thumbs1: Erstmal einen ganz, ganz herzlichen Dank für die bis hierher geleistete Hilfe und Unterstützung! :thumbs1:

    Ein ebenso großes Problem ist aber geblieben :mad_GREEN: unabhängig von meinen Versuchen mit dem Schreibschutz.

    Das Teil ist nach dem Umstieg auf das USB-Laufwerk lahm wie eine Schnecke geworden.

    Start mit reiner SD-Card < 10 sec.
    Jetzt mit USB-HDD bei 1Min 38 sec bis zum Prompt.
    Der Aufruf der GUI dauert, nach Eingabe von 'startx' geschlagene 3Min, bis das Menü bedienbar ist.
    Der Aufruf von 'shutdown' dauert von Menü-Anklicken bis zum Dialog 'End Session' 20 sec.
    Beim Start von OpenOffice kann man einen Kaffee trinken gehen.

    Leider kann ich nicht sehen, was der Rechner die ganze Zeit macht und ich habe auch keine Ahnung, wie dem bei zu kommen ist.
    Nach der Beendigung der GUI zum Prompt habe ich den Bildschirm fotografiert. Das Bild und das benannte Protokoll habe ich mal im Anhang angefügt.

    Über Hilfe zu diesem Problem würde ich mich seeeehr freuen.

    Gruß reinhard

    PS.: Mir ist aufgefallen, dass immer nur der 1. Aufruf eines Programmes so zeitintensiv ist. Werden denn bei jedem Programmstart Daten im Cach angelegt?
    Ist das auf der SD auch oder erst mit der USB-HDD? Wenn ja, warum? Kann man das Abschalten? Wenn das auf der SD nicht aktiv ist braucht man es auf der HDD genau so wenig. Gilt das auch für den Systemstart? Ist deswegen das booten so langwierig?
    Frage, Fragen, Fragen ....


  • ...Habe alle möglichen Kombinationen durchexerziert. :geek: ...


    :thumbs1: Erstmal einen ganz, ganz herzlichen Dank für die bis hierher geleistete Hilfe und Unterstützung! :thumbs1:


    Der Dank geht zurück denn Deiner Erkenntnisse sind sehr wertvoll :thumbs1: . Diese Abhängigkeiten waren mir nicht bewusst. Ich werde sie in raspiSD2USB sowie der Beschreibung berücksichtigen.

    Zitat

    ...Ein ebenso großes Problem ist aber geblieben :mad_GREEN: unabhängig von meinen Versuchen mit dem Schreibschutz.
    ...
    PS.: Mir ist aufgefallen, dass immer nur der 1. Aufruf eines Programmes so zeitintensiv ist. Werden denn bei jedem Programmstart Daten im Cach angelegt?
    Ist das auf der SD auch oder erst mit der USB-HDD? Wenn ja, warum? Kann man das Abschalten? Wenn das auf der SD nicht aktiv ist braucht man es auf der HDD genau so wenig. Gilt das auch für den Systemstart? Ist deswegen das booten so langwierig?

    Jetzt wird es ein wenig Offtopic. Ich schlag vor Du erstellst noch mal einen neuen Thread wo Du auf diesen verweist damit die Leser den Hintergrund haben. Auch wäre ein Link darauf hier im Thread hilfreich. Der Vorteil ist dass sicherlich mehr Leute reinsehen und eine Idee haben was die Ursache sein kann. Denn zugegebenermassen muss ich sagen dass ich da keine Antwort parat habe.

    Was mir aufgefallen ist in Deinem vorherigen /var/log/messages:

    Findest Du diese immer noch in Deinem Log?


  • Jetzt wird es ein wenig Offtopic. Ich schlag vor Du erstellst noch mal einen neuen Thread wo Du auf diesen verweist damit die Leser den Hintergrund haben. Auch wäre ein Link darauf hier im Thread hilfreich. Der Vorteil ist dass sicherlich mehr Leute reinsehen und eine Idee haben was die Ursache sein kann. Denn zugegebenermassen muss ich sagen dass ich da keine Antwort parat habe.

    Das habe ich mir schon gedacht. Werde es wie von Dir vorgeschlagen machen.

    Was mir aufgefallen ist in Deinem vorherigen /var/log/messages:

    Findest Du diese immer noch in Deinem Log?

    Nein! :) Da scheint das System wohl aus dem Takt geraten zu sein. Ich kann mich nicht erinnern, ob ich das 'was gemacht habe (65 ;) ).

    Die Zeilenanfänge sind wohl Zeitstempel und die Zahl in den '[]' zeigt die vergangene Zeit in Sekunden.

    Code
    z.B.: May 27 14:11:22 elli kernel: [ 1498.605731]


    Gruß reinhard

  • Muss ich hier und jetzt noch loswerden:

    ES LÄUFT!! :bravo2:

    Bin auf der Suche nach möglicherweise schon existierenden Treads zu meinem neuen Thema: "RasPi läuft sehr langsam nach Umstieg auf USB-Boot" auf einen Beitrag gestoßen, in dem es auch unter anderem um USB-Laufwerke ging und der Eintrag

    Code
    max_usb_current=1

    in der 'config.txt' ging.
    Fix duckduckgo gefragt und diesen Link gefunden.
    Hatte bis eben den RasPi mit einem 3A Netzteil betrieben und weil die HDD nicht laufen wollte einen USB-Hub mit einem 1A Netzteil betrieben. Ich hatte gedacht, dass ist sooo OK.
    Falsch! :blush:
    Nach eingabe von

    Code
    max_usb_current=1

    in die 'config.txt' ging es ab wie gewünscht. Schnelles booten und schneller Start der GUI. Der Start von LibreOffice ist auch schnell.
    Der RasPi läuft jetzt inkl. USB-HDD an einem Netzteil. :D
    Mein Problem ist behoben. :bravo2:

    PS.: Soll ich denn jetzt noch ein neues Thema aufmachen?

    Gruß reinhard

    Einmal editiert, zuletzt von REllebracht (1. Juni 2016 um 00:35)

  • Ich habe es erst einmal wieder ändern müssen. Zurück zur SD Karte.

    Wenn ich ein Programm installieren wollte, hat es ewig gedauert bzw bekam einen connection lost.

    Kann sein, das der Stick einfach zu lahm ist. Oder es fehlen weitere Einstellungen?!

    Einmal editiert, zuletzt von DanSman (1. Juni 2016 um 09:19)

  • ...ES LÄUFT!! ::bravo2:..


    :thumbs1: Du hast Dich zwar durchbeissen müssen - aber umso schöner ist dann der Erfolg :D

    Zitat

    ...Nach eingabe von

    Code
    max_usb_current=1

    in die 'config.txt' ging es ab wie gewünscht. Schnelles booten und schneller Start der GUI. Der Start von LibreOffice ist auch schnell.

    Da wäre ich so schnell wirklich nicht draufgekommen. Zumal ich auch keine Raspi 3 habe. Ist aber gut dass Du uns noch die genaue Ursache berichtet hast.

    Zitat

    PS.: Soll ich denn jetzt noch ein neues Thema aufmachen?


    Warum noch? Dein Problem hast Du doch selbst gelöst. :shy:
    Automatisch zusammengefügt:

    Kann sein, das der Stick einfach zu lahm ist. Oder es fehlen weitere Einstellungen?!

    Auch bei Dir. Ich würde einen neuen Thread mit entsprechendem Subject aufmachen und den mit diesem Crosslinken. Dann werden die Erfolgsaussichten wesentlich größer. BTW: Dasselbe Problem hat REllebracht gehabt und mit

    Code
    max_usb_current=1

    gelöst.

  • mattesflower hat ein Problem mit raspiSD2USB.py gemeldet :-/

    In älteren Versionen konnte man auch eine Partition als Ziel angeben welches genügend Platz hat für die Rootpartition. Das ging mit einer neueren Version nicht mehr. Da wurde strikter geprüft :) Die prüft ob die Zielpartition wenigstens so gross ist wie die Quellpartition.

    Wenn man beim Aufruf die Option -f oder --force angibt kann man nun auch bei der neuesten Version auf eine Partition umziehen die kleiner ist als die SD Root Partition aber noch genug freien Platz hat.

    Vielen Dank an mattesflower für seine Tests der Funktionserweiterung von raspiSD2USB.py.

  • Hallo

    Ich versuche deine Anleitung mit einem alten Raspberry Pi B+

    Leider bleibe ich hängen.

    Nachdem ich folgendes gemacht habe:

    Code
     sudo tar cf - --one-file-system --exclude=/mnt/*  --exclude=/proc/* --exclude=/lost+found/* --exclude=/sys/* --exclude=/media/* --exclude=/dev/* --exclude=/tmp/* --exclude=/boot/* --exclude=/run/* / | ( cd /mnt; sudo tar xfp -)

    kommen folgende Meldungen

    Code
    tar: Entferne führende „/“ von Elementnamen
    tar: Entferne führende „/“ von Zielen harter Verknüpfungen
    tar: /home/pi/.pm2/rpc.sock: Socket ignoriert
    tar: /home/pi/.pm2/pub.sock: Socket ignoriert

    Wenn ich dann in die fstab reinschaue, sehe ich folgendes:

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

    Mache ich was falsch, bzw. wie komme ich weiter?

    Linux raspberrypi 4.19.42+ #1219 Tue May 14 21:16:38 BST 2019 armv6l

    Danke sehr.

  • Du machst nichts falsch ;). Das Problem ist dass die Anleitung schon alt ist und fuer Wheezy gilt. Bei Stretch musst Du die PARTUUID fuer / anpassen.

    Dazu benutzt Du

    Code
    sudo blkid

    Ich bekomme da bei mir z.B. folgende Antwort:

    Code
    /dev/mmcblk0p1: LABEL="boot" UUID="A365-6756" TYPE="vfat" PARTUUID="d888a167-01"
    /dev/mmcblk0p2: UUID="ea98d3bf-9345-4bd7-b365-5cc7c543079f" TYPE="ext4" PARTUUID="d888a167-02"/dev/sdc1: LABEL="black" UUID="76e7d7d4-f6e9-4867-83a7-03eaa3fc878d" TYPE="ext4" PARTUUID="eb5b9646-01"
    /dev/sdd1: LABEL="silver" UUID="8095dbdf-9b0a-4dda-9352-d56366af43c8" TYPE="ext4" PARTUUID="001a1bf8-01"
    /dev/mmcblk0: PTUUID="d888a167" PTTYPE="dos"

    Fuer /boot laesst Du alles wie es ist und fuer / aenderst Du die PARTUUID so dass sie deine externe Rootpartition repraesentiert. D.h. wenn es z.B. bei mir /dev/sdd1 ist aendere ich

    Code
    PARTUUID=06b49ab7-02  /               ext4    defaults,noatime  0       1

    in

    Code
    PARTUUID=001a1bf8-01  /               ext4    defaults,noatime  0       1
  • Hallo

    Danke für deine Hilfe.

    Also blkid zeigt mir an:

    Code
    /dev/mmcblk0p1: LABEL="boot" UUID="27D9-A951" TYPE="vfat" PARTUUID="06b49ab7-01"
    /dev/mmcblk0p2: LABEL="rootfs" UUID="db9fbdec-9f10-4008-95da-5062491e0659" TYPE="ext4" PARTUUID="06b49ab7-02"
    /dev/sda1: UUID="bd0432ce-6249-4f99-9085-93859f4b9400" TYPE="ext4" PARTUUID="06b49ab7-01"

    Dementsprechend sieht fstab und cmdline.txt aus:

    Code
    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=06b49ab7-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

    Leider bekomme ich jetzt ein Kernel Panic

    Hast du noch eine IDee für mich?

    Danke für deine Hilfsbereitschaft :)

    EDIT: Mir fällt gerade auf, dass die PARTUUID bei dem ersten und letzten Eintrag gleich ist.

    EDIT2: Leider lässt mich tune2fs die ID nicht ändern :(

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!