Raspberry Pi4 mit OpenSuSE SD-Karte maximieren und ein Entwicklersystem installieren

Hallo,

seit SuSE6 für i586 (mit Ausnahme der Version 9+) bin ich trotz einiger Versuche andere System auszuprobieren immer wieder bei einer SuSE gelandet und es ist klar, daß ich nachdem ich andere Distribuntionen ausprobiert (und gelacht und gelöscht) habe, auch wieder zu OpenSuse zurückgekehrt.

So nun will ich für den Raspberry Pi4 4GB auf dem Raspberry Pi4 und OpenSuse Software entwickeln, wenn möglich mit zwei Bildschirmen.

- Ich denke ich brauche dafür folgendes

(1) den verlustfreien Umzug von einer 32GB SD auf eine 128GB C10 SD-Karte ohne Neuinstallation - denn es passt nicht alles drauf
(2) eine lauffäige GTK+ Umgebung mit allen denkbaren Tools C/C++ und GitGui (Git-Buch ist da)
(3) Doxygen mit webdot - das SuSE-Paket läuft nicht weil im Susepaket die LaTeX-Abhänigigkeiten nicht richtig gesetzt wurden (u.a. hanging.sty fehlt)
(4) Samba, um TortoiseGit und Cygwin über Windows zu nutzen - das will ich für den Windowsport unterstützen.
(5) Webserver mit libuncgi().
(6) am Ende ein Metapaket, welches vom OpenSuSe-Grundimage mit nur einen rpm --install alles fertig installiert, also ein "ready to use - developer - Image mit funktionierendem Grub2" - damit JEDER nicht erst durch das Unterholz kriechen muss, um alles Notwendige für die Programmentwicklung lauffähig zu haben - samt Doku und Manuals. Also Image über FDM laden, install.sh aufrufen, neu booten - aus die Maus
(7) ein Test von rpm zu deb für Debian, um nicht alles auch für Debian pflegen zu müssen.

Zu (1) eine 128GB Karte für 4€ kam heute OVP aus China an - ich hoffe ohne Viren.

Jetzt ist die Frage wie bekomme ich Punkt 1 mit Bootlader erledigt.

Der Plan ist folgender:
- Ich würde irgendwas mit dd und Bootsektor der 32GB-Karte versuchen wollen, um den Bootsektor zu kopieren, aber zur Sicherheit die originale 32er SD Karte unverändert im HW-Slot belassen, dann mit "cp -Rapd quellpath zielpath" alle Dateien kopieren. (cross the fingers)
- die zukünftige 128er SD-Karte per Kartenleser an USB anschließen und so lange wie möglich darin belassen.
- dann muss sich sicherlich das Bootimage anpassen, damit der Kernel der großen Karte die richtige initrd lädt.
- dann erst die 32 Karte gegen die 128er Karte austauschen und ein Art diff laufen lassen, um zu prüfen ob alles sauber gelaufen ist.
- dann die 32 Karte raus und testen ob alles geht. Punkt 2-7 auf der großen Karte abarbeiten.

Wer kennt sich mit dem Boot-System und dd so gut aus, daß wir Punkt 1 abhaken könnten.

Also ich bin bereits auf dem Raspi mit dem händisch teilinstallierten OpenSuSE, aber es ist schon recht kuschelig - ich brauch mehr Platz - TeTex passte schon mal nicht drauf, weswegen Doxygen vermutlich auch nicht sauber durchläuft (so eine Vermutung)

Das Installieren war ein buggl - nun will ich das nicht jedes mal machen müssen, andere Entwickler sicherlich auch nicht. Also das Grundsystem und dann ein rpm --install eines Metapaketes - alles fertsch, für git checkout und dann ./configure | make install - das ist das Ziel.

fdisk -l
Disk /dev/mmcblk0: 28.99 GiB, 31104958464 bytes, 60751872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: nul

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 34815 32768 16M c W95 FAT32 (LBA)
/dev/mmcblk0p2 34816 1058815 1024000 500M 82 Linux swap / Solaris
/dev/mmcblk0p3 1058816 60741764 59682949 28.5G 83 Linux

Disk /dev/sda: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: Basic Line
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: nul

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2784 61439999 61437216 29.3G c W95 FAT32 (LBA)

racoon:/develop/git #

Zitat von sterun

Welche Dateisysteme:
ext4 - xfs - btrfs ...
Falls ext4, würde ich Clonezilla nehmen.
Einfach von der 32 GB SD ein Clonezilla-Image erstellen und auf der 128 GB SD zurück spielen.
So wäre auch der Bootloader unverändert vorhanden.
Danach offline die Partitions-Größen anpassen - fertig.
So mache ich es bei ext4 - ohne Verschlüsselung.
Bei btrfs z.B. sieht es jedoch anders aus

Alles anzeigen

Die Dateitypen lassen sich mit blkid ermitteln - sda1 ist ein USB-Stick am Raspi - vorgesehen für das später fertig zu konfigurierende samba-laufwerk (hängt jetzt nur provisorisch dran) Das ist nützlich für die Win7-Toolchain über TortoiseGit, um zu testen ob das Paket auch auf Cygwin64 sauber gebaut wird. Das ist sehr wichtig, weil viele nicht umsteigen können, aber einen Raspi unter Linux laufen haben.

Außerdem ist es eine halbrussische Zwischenablage, um Code oder Consolenoutput zwischen Windows und Linux hin- und her zu schieben. Damit das hier rauskommt.

racoon:~ # blkid -ps TYPE /dev/mmcblk1p1
/dev/mmcblk1p1: TYPE="vfat"
racoon:~ # blkid -ps TYPE /dev/mmcblk1p2
/dev/mmcblk1p2: TYPE="swap"
racoon:~ # blkid -ps TYPE /dev/mmcblk1p3
/dev/mmcblk1p3: TYPE="ext4"
racoon:~ # blkid -ps TYPE /dev/sda1
/dev/sda1: TYPE="vfat"
racoon:~ #

Zitat von Sauerland

Bitte für Konsolenausgaben Code-Tags benutzen!!

Ok, für die Zukunft. Ich kann es im o.g. Posting selbst nicht mehr korrgieren. Es war schließlich eurer erklärter Wille die nachträglichen Korrektur zu sperren, also lebt auch mit den Nachteilen oder korrigiert es bitte selbst, wenn es ein Problem ist - ich sehe aber in dieser konkreten Ausgabe kein HTML und keine shellkritischen Zeichen.

Ich habe dd nehmen wollen, um nicht mein Win7System jedes mal runterkrachen zu müssen mit den hundert aktiven Fenstern.

Obwohl im Netz steht, daß man bei dd unter Linux keine Blockgroße angeben braucht, habe ich festgestellt, daß es ohne Angabe langsamer geht - warum auch immer. Jedenfalls meint man bei dd wird der Bootsektor immer sauber kopiert - ich hoffe mal das stimmt so. Also war dann folgendes zu machen.

dd if=/dev/dev/mmcblk0 of=/dev/sda bs=1M

Dabei kam raus, daß die billig gekaufte SD-Karte vermutlich ein Fake ist und das ist immer eine gute Gelegenheit für die Methode "Echtes vom Faker als Betatester" - also Originalaktikel ohne Aufwand der Rücksendung des Fakes exakt zu dem Preis vorher mit H2testw getestet sonst Kripo knock knock und Händleraccount futsch, so bekommt man gut ausgebildete Betatester zum Nulltarif - nimmt man die KP China als Aufsichtsbehörde, dann wirkt das auch in China Wunder. Auserdem hat man dabei einen SD-Adapter übrig, die Lieferzeiten sind halt länger.

Der Timer lässt wieder mal keine Nachbearbeitung zu :-|

Bis die neuen Karten da sind werde ich mal das Grundsystem abspecken und alles löschen was für die Programmierei eh nicht von Nutzen ist, wobei ich beim Paketbau sed als Handschwein für die Konfigurationsbearbeitung nutzen würde, allen voran bei doxygen. Es muss ja eh vieles noch passend gemacht werden. Also besorge ich mir eine zweite 32GB SD-Sim damit ich die letzte Änderung noch habe und dann Git noch einspannen für die Branches.

Wir brauchen also ein Cleanup-RPM-Paket und schreiben alles uninstall zum Grundpaket rein, was wir nicht in einem Developerminimalsystem haben wollen und das ist dann die Grundkonfiguration für ein 32GB-Optimal-System. Anschließend kann man das dann als ein neues 32GB-Grundsystem definieren und von dort aus in Richtung Maximalsystem weitermachen.

Die Frage wo kriege ich eine tagesaktelle Paketliste des OpenSuse-Grundpaketes her? Diese würde ich mit sed bearbeiten und dann als Ausgangspunkt nehmen.

Es fehlten gegenüber der Pristine-Version IMHO

• mc
• einige verhasste, aber notwendige X-Biliotheksbauwerkzeuge (ua. xlib header xmkmf, autoconf)
• emiclock (never miss a good alarm clock)
• fte (unendlich lange Files mit syntax, tools und guter hex/bin-Statusleiste)
• GTK-Toolchain
• samba modifkation wegen Cygwin, um von Win7 aus das Cygwin-Repository zu updaten (es ist noch etwas krank das über Win7 zu machen - funktioniert aber gut, später muss dann noch eine saubere Lösung her)
• Compilerbauwerkzeuge (bison, flex, awk)
• was vergessen?