Bananian Update auf SATA

Hallo Bjoern, einen schönen Blog hast du hier!

Beim neuen Bananian 15.08 ist das Prozedere etwas anders als bisher (mit 15.04 oder älter):

Anstelle einer uEnv.txt existieren die Dateien boot.cmd und boot.scr.

1. Die Boot-Partition wie vom Autor beschrieben mit
mount /dev/mmcblk0p1 /mnt/
mounten und per
cd /mnt
in das Verzeichnis wechseln.

2. Die Boot-Einträge anpassen. Dazu mit
nano boot.cmd
die entsprechende Textdatei öffnen (hier jetzt also boot.cmd statt uEnv.txt)
und alle root=/dev/mmcblk0p2-Einträge zu root=/dev/sda1 ändern.
(Dieser Eintrag dürfte zweimal vorhanden sein, und zwar irgendwo in den langen Textzeilen. Evtl. ändert sich das aber in zukünftigen Bananian-Versionen wieder, sodass nur noch ein root-Eintrag nötig ist - das hängt davon ab, welche Kernel-Versionen der Bananian-Entwickler supporten will.)
Datei speichern (Strg+O) und schließen (Strg+X).

3. Jetzt muss aus der boot.cmd eine neue boot.scr generiert werden.
Mit
cp boot.scr boot.scr_old
zunächst ein Backup der bestehenden Datei erstellen.
Mit
apt-get install u-boot-tools
wird noch die für diesen Schritt notwendige Software u-boot-tools nachinstalliert.
Anschließend kann mit
mkimage -C none -A arm -T script -d boot.cmd boot.scr
eine neue boot.scr-Datei aus unserer abgewandelten boot.cmd generiert werden.

4. Sicherheitshalber einmal mit
sync
den Schreibcache leeren und dann neustarten:
shutdown -r now
Jetzt sollte das System von der Festplatte statt der SD-Karte geladen werden. Das kann mit
df -h
kontrolliert werden - bei /dev/root sollte die Größe der Festplatte angegeben sein, statt der der SD-Karte.

Ich habs jetzt mal ganz haarklein beschrieben, sodass auch Linux-Anfänger damit was anfangen können...
Anzumerken wäre noch, dass der Bootvorgang u. U. schiefgehen kann, wenn mehrere Festplatten oder zusätzliche USB-Sticks angeschlossen sind an den Pi, da die Laufwerkskennungen à la sda, sdb, sdc, usw. mehr oder weniger zufällig vergeben werden.

Viele Grüße
Roman

Noch eine Ergänzung:
Ich lese gerade, dass boot.cmd auch PARTUUIDs unterstützt, damit kann also ausgeschlossen werden, dass der bananaPI auf der falschen Festplatte/USB-Stick nach dem System sucht.
Folgendes habe ich nicht getestet, sollte aber funktionieren:

1. PARTUUID (d.h. eindeutige Partitions-Identifikationsnummer) ermitteln. Dazu aus der Liste, die man mit
blkid
erhält, die PARTUUID der gewünschten Festplatte bzw. der richtigen Partition aufschreiben oder herauskopieren. ACHTUNG: Nicht die UUID, sondern die PARTUUID! Verwendet man aus Versehen die UUID, startet das System anschließend nicht mehr. Deshalb ist das in meinem vorigen Post erwähnte Backup der boot.scr nützlich - das kann man dann notfalls über einen SD-Kartenleser an einem anderen Rechner wiederherstellen.

2. Der Anleitung wie in meinem vorigen Post beschrieben folgen, statt root=/dev/sda1 jedoch root=UUID=123-456-789-0 eintragen, wobei ihr statt 123-456-789-0 natürlich eure jeweilige PARTUUID verwendet.

Auch hierzu eine Anmerkung: Jetzt kann der BananaPi auch stets korrekt booten, selbst wenn ein Dutzend USB-Sticks und Festplatten angeschlossen sind. Will man seine Betriebssystem-Festplatte allerdings künftig austauschen (z.B. wegen Defekt oder Ersatz durch größere Platte), muss auch die PARTUUID auf die neue Platte angepasst werden...

Danke für die Anleitung. Wurde schon sehnlich erwartet :-)

Gruß Bjoern

Hey Roman, das ist echt eine super Sache von dir. Vielen Dank!

Hey Bjoern und Roman, vielen Dank. Durch Euch läuft meine Banane wieder. Muss dass jetzt eigentlich bei jedem 'bananian-update' gemacht werden?

Hey Nico

Super, dass es geklappt hat.
Und vermutlich musst du da jetzt bei jedem 'bananian-update' drauf achten .. aber du musst ja nicht jedes 'bananian-update' machen. Wenn da nicht deutliche Vorteile oder Features enthalten sind, musst du das nicht.

Wenn dein System also rund läuft und alles tut, was es soll, reicht es ja, wenn du die Security-Updates über diie Paketverwaltung einspielst mit
apt-get update
und
apt-get upgrade

Da das ein Debian-System ist, werden die Pakete dort noch ein paar Jahre aktuell gehalten.

Gruß vom Bjoern

Hallo Robert, vielen Dank für deine Ergänzung. Mit ihr hab ich trotz der Sata-Warnung das update durchgezogen - und es läuft!

Hallo Bjoern,

ich habe es mit der neuen Anleitung versucht, interessanterweise weigert sich aber meine Banane (scheinbar) nach der Umstellung zu booten.
Vorher gibt es keine verdächtigen Meldungen und das gerettete Boot-Image tut auch immer noch seinen Dienst, allerdings scheint der Bootvorgang von der Festplatte nicht zu klappen, zumindest kriege ich keine Verbindung zum B-Pi. Hatte erst gedacht, es könnte vielleicht wirklich an der Benennung der Festplatten liegen, deshalb habe ich auch mal den PARTUUID-Trick ausprobiert, aber leider Fehlanzeige. Ideen?

Hey Martin

Leider habe ich dazu so erstmal keine Ideen, da ich das selber noch nicht nach der neuen Version versucht habe.
Tut mir Leid.

Vielleicht schaut aber hier nochmal einer vorbei, der es nach der neuen Anleitung geschafft hat. Vielleicht hat ja einer von denen eine Idee.

Gruß Bjoern

Hallo Bjoern,

ich melde mich noch mal. Das Problem hat sich mittlerweile gelöst und es funktioniert super! Ich hatte es zwischenzeitlich noch mal mit Version 15.04 versucht, da lief alles einwandfrei. Dann habe ich noch mal eine zweite SD-Karte mit 15.08 beschrieben und wiederholt einen Versuch gemacht. Da ich annahm, dass mein erstes Image möglicherweise irgendwo fehlerhaft war, habe ich mir Bananian frisch von der Website gezogen. Das ist für mich zur Zeit die einzige logische Erklärung, weil es jetzt auf Anhieb funktionierte.
Könnte es irgendwie sein, dass man nur(!) nach dem FirstBoot bei einem frischen 15.08 (also keinem Upgrade von 15.04) die Festplattenumstellung vornehmen kann? Also vor einem ersten Neustart? Klingt zwar seltsam, wäre aber die einzige Alternative, die ich zum beschädigten Image als Theorie anbieten könnte.

Gruß Martin

"statt root=/dev/sda1 jedoch root=UUID=123-456-789-0 eintragen, wobei ihr statt 123-456-789-0 natürlich eure jeweilige PARTUUID verwendet."

Das kann ich so nicht bestätigen. Hat bei mir nicht funktioniert.
Ich benutze einen Mainlinekernel mit Systemd. Mit /dev/sda1 ging es wieder.
Ist /dev/sda1 möglicherweise noch woanders hinterlegt?
Geht doch eigentlich garnicht, oder? Das kommt in der Bootsequenz doch alles nachher..