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

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Raspberry Pi4 mit OpenSuSE SD-Karte maximieren und ein Entwicklersystem installieren gibt es 13 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • 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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Chartwalker ()

    Für den Inhalt des Beitrages 139872 haftet ausdrücklich der jeweilige Autor: Chartwalker

  • 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 :(

    Für den Inhalt des Beitrages 139874 haftet ausdrücklich der jeweilige Autor: sterun

  • Ich würde schlicht eine USB Platte dranhängen und den Bootloader vom Raspi dorthin umbiegen.
    Um eine komplette Neuinstallation kommst du eh nicht herum, da der Raspi ja ein ARM Gerät ist.

    (Am Rande: Die Raspi NOOBs Variante erledigt das Resizen des Filesystems auf den microSD Karten von ganz alleine.)
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 139876 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • 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 #

    Für den Inhalt des Beitrages 139879 haftet ausdrücklich der jeweilige Autor: Chartwalker

  • sterun schrieb:

    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 :(
    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:~ #

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Chartwalker ()

    Für den Inhalt des Beitrages 139884 haftet ausdrücklich der jeweilige Autor: Chartwalker

  • Sauerland schrieb:

    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.

    Für den Inhalt des Beitrages 139893 haftet ausdrücklich der jeweilige Autor: Chartwalker

  • Code-Tags erhält die Formatierung der Konsole, nachträgliches Korrigieren wäre zu viel Zeitverschwendung......

    Quellcode

    1. fdisk -l
    2. Festplatte /dev/nvme0n1: 477 GiB, 512110190592 Bytes, 1000215216 Sektoren
    3. Disk model: WDC PC SN520 SDAPNUW-512G-1006
    4. Einheiten: Sektoren von 1 * 512 = 512 Bytes
    5. Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
    6. E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
    7. Festplattenbezeichnungstyp: gpt
    8. Festplattenbezeichner: 9450C6A7-B796-491B-946A-DE35167CA8EB
    9. Gerät Anfang Ende Sektoren Größe Typ
    10. /dev/nvme0n1p1 2048 616447 614400 300M EFI-System
    11. /dev/nvme0n1p2 616448 126445567 125829120 60G Linux-Dateisystem
    12. /dev/nvme0n1p3 126445568 144271359 17825792 8,5G Linux Swap
    13. /dev/nvme0n1p4 144271360 1000215182 855943823 408,1G Linux-Dateisystem
    Alles anzeigen

    Sieht ein wenig anders aus als von Dir:

    Quellcode

    1. disk -l
    2. Disk /dev/mmcblk0: 28.99 GiB, 31104958464 bytes, 60751872 sectors
    3. Units: sectors of 1 * 512 = 512 bytes
    4. Sector size (logical/physical): 512 bytes / 512 bytes
    5. I/O size (minimum/optimal): 512 bytes / 512 bytes
    6. Disklabel type: dos
    7. Disk identifier: nul
    8. Device Boot Start End Sectors Size Id Type
    9. /dev/mmcblk0p1 2048 34815 32768 16M c W95 FAT32 (LBA)
    10. /dev/mmcblk0p2 34816 1058815 1024000 500M 82 Linux swap / Solaris
    11. /dev/mmcblk0p3 1058816 60741764 59682949 28.5G 83 Linux
    12. Disk /dev/sda: 29.3 GiB, 31457280000 bytes, 61440000 sectors
    13. Disk model: Basic Line
    14. Units: sectors of 1 * 512 = 512 bytes
    15. Sector size (logical/physical): 512 bytes / 512 bytes
    16. I/O size (minimum/optimal): 512 bytes / 512 bytes
    17. Disklabel type: dos
    18. Disk identifier: nul
    19. Device Boot Start End Sectors Size Id Type
    20. /dev/sda1 * 2784 61439999 61437216 29.3G c W95 FAT32 (LBA)
    Alles anzeigen
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 139911 haftet ausdrücklich der jeweilige Autor: Sauerland

  • 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.


    Quellcode

    1. 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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Chartwalker ()

    Für den Inhalt des Beitrages 139954 haftet ausdrücklich der jeweilige Autor: Chartwalker

  • 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?

    Für den Inhalt des Beitrages 139955 haftet ausdrücklich der jeweilige Autor: Chartwalker