RM 'generic-aarch64' im Virtual Manager... auf Pi5B unter Raspbian OS (Desktop-Version)

[Baxxy13]

Wenn man nix zu tun hat sucht man sich was... und da ich mit dem RM-LXC durch bin (nix mehr zu meckern 😉 ) habe ich mir die generic-aarch64 - Version geschnappt.

Setup: Pi5B-8GB mit dem Standard Raspbian OS (Desktop - Version), Virtual-Manager installiert

Grundsätzlich bin ich erstmal dem Wiki: Installation QEmu bis Step 4 gefolgt, hat grundsätzlich funktioniert auf wenn die generic-aarch64 - Version als .img daherkommt und nicht als .vmdk.
Egal, letztlich war die Kuh (.qcow2) verfügbar und auf ~6GB vergrößert.

Die Kuh (.qcow2) dann als neue VM mit dem Virtual Manager eingerichtet (mit quasi Standarteinstellungen) und beim ersten Start im "UEFI-Bios" den SecureBoot deaktiviert. Danach startete die RM sauber durch und ließ sich ersteinrichten.
(erstmal nackt, also ohne irgendeinen Funkmodul-Passthrough)

Erfreulich einfach, hätte ich nicht gedacht.

Es gibt aber aktuell 3 Sachen dir mir aufgefallen sind:

• 1: Der Virtual Manager zeigt ja auch die Konsole, hier sieht man aber leider nur "Booting 'RaspberryMatic'". Mit nem VNC-Viewer komme ich drauf, scheitere aber am übermitteln von "Alt+F2" und somit sehe ich quasi nix. Kann man irgendwie den "Boot-Output" auf die Konsolenansicht des Virtual Manager umleiten? Homeassistant-OS schafft da auch teilweise.

• 2: Die RM neustarten klappt über die WebUI problemlos, mit dem "Neustart-Button" des Virtual Manager hingegen nicht. Hier verbleibt die RM im Status "Ausgeschaltet (Heruntergefahren)

• 3: Die "Hilfe-Seite" der RM gab nach dem ersten Start 4,7MB freien Speicher für /rootfs aus. Nachdem ich nun das erste Update über die WebUI gemacht habe sind es nur noch rootfs Free Space: 0 B [0.0%] / 973.4 MB.
  Monit sagt auf der Statusseite: SPACE USAGE: 93.6% [911.3 MB]
  Und die Konsole sagt...

root@homematic-raspi:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               973.4M    911.3M         0 100% /
devtmpfs                675.6M         0    675.6M   0% /dev
tmpfs                   696.3M     36.0K    696.2M   0% /tmp
tmpfs                   696.3M         0    696.3M   0% /dev/shm
tmpfs                   696.3M      1.1M    695.2M   0% /var
tmpfs                   696.3M         0    696.3M   0% /media
/dev/vda3                 4.8G      1.6M      4.6G   0% /usr/local
/dev/vda1               255.7M    100.5M    155.2M  39% /boot

Sehr merkwürdig.

Grundsätzlich ging's primär darum das mal zu testen. Und der Ehrgeiz sagt das kann man verbessern.
Bin für Ideen, Vorschlage und Test's bereit. 😉

[BenjaminT2025]

Hallo Baxxy:

ich habe ja auch mal getestet, wie schon im forum kunt getan ;-)

1: ALT-F2 geht in meiner Test umgebung

2: Reboot über den Virtuell Manager Proxmox geht auch.

3: einzig das mit dem RootFS kann ich so bestätigen
Habe mir die Partition testweise vergrößert, danach geht aber ein normales Raspberrymatic Update nicht mehr, da er die Partitionsgröße prüft.
[5/5] Checking for image file... found, flashing bootfs...OK, ERROR: rootfs partition has different size than provided image

[jens-maus]

Wenn man nix zu tun hat sucht man sich was... und da ich mit dem RM-LXC durch bin (nix mehr zu meckern 😉 ) habe ich mir die generic-aarch64 - Version geschnappt.
...

• 3: Die "Hilfe-Seite" der RM gab nach dem ersten Start 4,7MB freien Speicher für /rootfs aus. Nachdem ich nun das erste Update über die WebUI gemacht habe sind es nur noch rootfs Free Space: 0 B [0.0%] / 973.4 MB.
  Monit sagt auf der Statusseite: SPACE USAGE: 93.6% [911.3 MB]
  Und die Konsole sagt...

root@homematic-raspi:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               973.4M    911.3M         0 100% /
[...]
Sehr merkwürdig.

In der Tat. Ist das denn wirklich schon out-of-the-box 100% voll oder was füllt hier das rootfs? Leider ist und wird das rootfs ja schon seit einigen versionen sukzessive immer voller und ich hab auch schon probiert hier+da Verbesserungen einzuführen um generell die speicherauslastung runter zu bringen. Ärgere mich aber auch schon bereits das ich damals nicht gleich auf 2GB für rootfs gegangen bin als das alles noch in den Kinderschuhen war. Nun wird es schwierig das rootfs auf 2GB hochzusetzen – zumindest nicht ohne den Weg eines Downgrades zu versperren. Aber vielleicht muss ich da doch nochmal ran und methoden mir ausdenken wie man das auf 2GB vergrößern könnte um für die weitere Zukunft dann wieder "mehr Luft" zu haben.

[Baxxy13]

Wo ist das Problem? 😉
Breaking-Change machen wo alle das OS frisch flashen müssen.
Backup drauf und gut ist's.
Ne Sache von 5 - 50 Minuten.

Zu meiner Test-VM.
Das war/ist ein nacktes System.
Mir kamen da eher die unterschiedlichen Angaben spanisch vor, kann mir nicht vorstellen das /rootfs wirklich voll war.
Ich gucke mal ob ich das Setup noch irgendwo rumliegen habe.

[jens-maus]

Wo ist das Problem? 😉 Breaking-Change machen wo alle das OS frisch flashen müssen. Backup drauf und gut ist's. Ne Sache von 5 - 50 Minuten.

Naja... Ich hab da etwas anderes Ansprüche bzw. Ehrgeiz ;-)

Zu meiner Test-VM. Das war/ist ein nacktes System. Mir kamen da eher die unterschiedlichen Angaben spanisch vor, kann mir nicht vorstellen das /rootfs wirklich voll war. Ich gucke mal ob ich das Setup noch irgendwo rumliegen habe.

Danke.

[BenjaminT2025]

Ich habe gerade mal eine neue VM ertstellt.

direkt ein df -a
root@homematic-raspi:~# df -a
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 996780 947376 0 100% /
devtmpfs 465636 0 465636 0% /dev
proc 0 0 0 0% /proc
sysfs 0 0 0 0% /sys
tmpfs 487460 36 487424 0% /tmp
devpts 0 0 0 0% /dev/pts
tmpfs 487460 0 487460 0% /dev/shm
tmpfs 487460 1124 486336 0% /var
tmpfs 487460 0 487460 0% /media
/dev/sda1 261868 109640 152228 42% /boot
/dev/sda3 4817532 61320 4490796 1% /usr/local

[Baxxy13]

Hab die SD-Karte von dem damaligen Test gefunden.
Die RM ist ein alter Snapshot: 3.79.1.20240827

root@homematic-raspi:~# df -a
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               996780    933168         0 100% /
devtmpfs                940632         0    940632   0% /dev
proc                         0         0         0   0% /proc
sysfs                        0         0         0   0% /sys
tmpfs                   961816        36    961780   0% /tmp
devpts                       0         0         0   0% /dev/pts
tmpfs                   961816         0    961816   0% /dev/shm
tmpfs                   961816      1096    960720   0% /var
tmpfs                   961816         0    961816   0% /media
/dev/vda3              5077472      1808   4796988   0% /usr/local
/dev/vda1               261868    102956    158912  39% /boot

[jens-maus]

Dann bitte dafür mal ein Ticket aufmachen damit das nicht in Vergessenheit gerät und ich mir das anschauen kann und ggf. schauen das ich da noch ein paar MB platz schaffe im rootfs. Keine Ahnung warum das generic-aarch64 soviel mehr platz frist als generic-x86_64 oder so. Sollte eigentlich nicht passieren...

[jens-maus]

Hab die SD-Karte von dem damaligen Test gefunden. Die RM ist ein alter Snapshot: 3.79.1.20240827

Aha? Dann war das schon immer so? Warum ist das keinem aufgefallen? tztztz ;-)

[Baxxy13]

Guck wann ich die Diskussion eröffnet habe, dann weißt du wer's verschlafen hat. 😁

[BenjaminT2025]

Ich hatte bisher nen PI3B am laufen und hatte jetzt edlich eine HB-RF-ETH bekommen ;-)
Daher das Projekt Raspberrymatic zu virtualisieren.
Wollte mir im nächsten schritt dann auch HomeAssistant und ioBrocker mal ansehen.

[Baxxy13]

Auf jeden Fall ist das buggy und nur die Anzeige in der Monit-Übersicht stimmt.
Ich kann problemlos ne 50MB - Datei auf dem /rootfs erzeugen, obwohl es angeblich (außer bei Monit) voll ist.

[jens-maus]

Nene, das ist ratzbutz voll:

/dev/loop11p2               974M  915M     0 100% /mnt/p2

Wie gesagt, macht nen Ticket auf und ich schau mir das zeitnah an...

[Baxxy13]

Also ich konnte das System nun problemlos auf den letzten Nightly aktualisieren, trotz angeblichem "ratzbutz voll".
Ziemlich eng aber nicht ganz voll sieht das nun so aus:

Um's Ticket darf sich jemand kümmern der das auch aktiv nutzen möchte.
Ich bleibe bei den "großen" (x86) VM's. 😉

[BenjaminT2025]

Dann werd ich mal mein erstes Ticket aufmachen 😉

Schönen Abend euch

Gruß
Benjamin

[Baxxy13]

So, Punkt 3 meiner Liste ist ja nun erledigt.
Was ist mit 1. & 2.?
Gibt's da auch irgendwelche Ideen oder Vorschläge?

[BenjaminT2025]

Wenn ich unter Proxmox auf die Console gehe, zeigt er mir:

ALT+F2 gedrückt und ich sehe die Console

Auch der reboot über die Proxmox Console geht.

Fährt normal runter, bleibt an und startet auch wieder.
Nur, die vorher geöffnete, Proxmox Console bleibt auf "Guest not Running"

Die VM läuft aber und wenn ich die Proxmox Console neu öffne ist das RaspberryMatic Bild auch da.

[Baxxy13]

Danke, aber das das mit Proxmox geht weiß ich doch. 😉
Ich traue aber diesem Proxmox-Port nicht so recht und daher wollte ich das eigentlich mit nativen Mitteln auf einem RaspberryPi-OS mal testen. Dieser "Virtual Manager" ist ja auch ein Hypervisor und grundsätzlich läuft ja auch alles.

Vom Prinzip habe ich das hier: hypervisor-specific-configuration
mit der Methode "KVM (virt-manager)" statt mit HA-OS eben mit RaspberryMatic gemacht.