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.
Alles anzeigenWelche 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:~ #
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 #
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.
