Category: arch_based

VBox 6.0.13 laeuft mit Kernel 5.3 im Host

axt

Vor zwei Tagen ist Kernel 5.3 erschienen, die ersten Distributionen beginnen, ihn auszuliefern. Klar, keine verstaubten á la Long Term Sleeping, sondern die, die stets vorn dran sind, so arch bzw. arch-basierte.

Mit VirtualBox hat man bis gestern auch keine 5.3rc nutzen können. Mit Testbuild VirtualBox-6.0.13-133347-Linux_amd64.run (GA 6.0.13-133316, EP 6.0.13-133347) wird nun ordentlich gebaut, VMs starten und laufen. Tests arch-based und mit siduction als Hosts.

Btw., VBox 6.1.0b1 ist erschienen (dev-snapshots auf der testbuilds-site sind bereits höher, mehr bleeding edge geht dann aber nicht). Wie ich vor 4 Wochen schon geschrieben habe, VBoxVGA ist nun entfernt worden, es ist also auf VBoxSVGA oder, dort, wo es nicht crashed, VMSVGA zu wechseln.

VirtualBox: Kernel 5.0 nun auch im Guest

axt

VirtualBox 6.0.4 kommt mit Kernel 5.0.x zurecht – aber nur im Host. In einer Linux-VM bislang nur ohne GuestAdditions, auch nicht mit 6.0.5er Testbuilds oder auch 6.0.97er Development Snapshots – bis heute.

Endlich (und wir sind schon bei Kernel 5.0.4, 5.1 liegt bereits als rc2 vor) werden mit VBoxGuestAdditions_6.0.5-129577.iso die Module gebaut (Nachtrag: mittlerweile sind höhere Testbuilds erschienen). Es können damit aktuelle Kernels in Virtual Machines bzw. auch entsprechend aktuelle Linux-Distributionen (antergos, siduction) in VMs genutzt oder getestet werden (selbst LDisco ist seit kurzer Zeit nach ewigem Stillstand auf aktuellen Kernel gewechselt – mit 5.1 wird das allerdings bis zum Release nichts mehr).

Die GA allein sollten zwar genügen, ich setze freilich seit langem insgesamt aktuelle Testbuilds von VBox, GA und EP ein (so nicht gerade mal ein Release aktueller sein sollte…für einen kurzen Zeitraum).

Update 2019-04-16: VBox 6.0.6 ist erschienen.

SystemRescueCd mit archlinux-Unterbau

axt

SystemRescueCd Menu

Live-Systeme wie SystemRescueCd sollten in keinem IT-Werkzeugkasten fehlen. Mit der heute erschienenen v6.0.0 (Update) wechselt SysRescCd die Basis von bisher Gentoo auf archlinux. Ein Schritt, den ich persönlich begrüße, obgleich ich die Gründe zwar nicht kenne, jedoch hauptsächlich begrenzte Manpower vermute.

Das könnte übersehen, wer gewohnt startx oder ein Tool wie z.B. testdisk ausführt.

Read more “SystemRescueCd mit archlinux-Unterbau”

VirtualBox: Installation ueber .run

axt

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 7.0.16 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren: 
    1

    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren: 
    1
2

    killall -9 virtualbox 
sudo apt purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren: 
    1

    sudo apt install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen: 
    1
2

    cd ~/Downloads/
wget https://download.virtualbox.org/virtualbox/7.0.16/Oracle_VM_VirtualBox_Extension_Pack-7.0.16.vbox-extpack
  5. Aktuelle VBox-Version installieren: 
    1

    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1

sudo sh Virt* uninstall

.

Update 2024-04-16: Aktualisiert auf v7.0.16.
Update 2024-01-16: Aktualisiert auf v7.0.14.
Update 2023-10-17: Aktualisiert auf v7.0.12.
Update 2023-07-18: Aktualisiert auf v7.0.10.
Update 2023-04-17: Aktualisiert auf v7.0.8.
Update 2023-01-17: Aktualisiert auf v7.0.6.
Update 2022-11-18: Aktualisiert auf v7.0.4.
Update 2022-10-19: Aktualisiert auf v7.0.2.
Update 2022-10-10: Aktualisiert auf v7.0.0, VBox-6.x-Schiene entfernt.
Update 2022-09-29: VBox-7.0-Schiene hinzugefügt.
Update 2022-09-01: Aktualisiert auf v6.1.38.
Update 2022-07-20: Aktualisiert auf v6.1.36.
Update 2022-04-19: Aktualisiert auf v6.1.34.
Update 2022-01-18: Aktualisiert auf v6.1.32.
Update 2021-11-22: Aktualisiert auf v6.1.30.
Update 2021-10-19: Aktualisiert auf v6.1.28.
Update 2021-07-28: Aktualisiert auf v6.1.26.
Update 2021-07-20: Aktualisiert auf v6.1.24.
Update 2021-04-29: Aktualisiert auf v6.1.22.
Update 2021-04-20: Aktualisiert auf v6.1.20.
Update 2021-01-19: Aktualisiert auf v6.1.18.
Update 2020-10-20: Aktualisiert auf v6.1.16.
Update 2020-09-04: Aktualisiert auf v6.1.14.
Update 2020-07-14: Aktualisiert auf v6.1.12.
Update 2020-06-05: Aktualisiert auf v6.1.10.
Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.

antergos: HDD-Mindestkapazitaet mit cnchi

axt

Da die Installationsroutine in antergos 18.9 einen verhindernden cnchi-Fehler gehabt hat – natürlich genau in dem Moment, als ich es habe installieren wollen – checke ich das aktuelle Image kurz, um nicht mehrere nun veraltete zusätzlich aufheben zu müssen (denn die Mirrors haben auch stets nur die monatlich aktuelle Version vorliegen…und sei sie auch kaputt…). Kurzerhand habe ich eine bereits vorhandene VM ohne installiertes OS nutzen wollen. Diese hat eine 10 GiB große virtuelle Harddisk, eigentlich für den Test kein Problem.

cnchi hat in 0.16.1 (aktuell in antergos 18.12 ist mittlerweile 0.16.21) jedoch “set MIN_SIZE” von ehedem 8 GiB auf 16 GiB angehoben (“has at least 16.0GB available storage space.”) und läßt sich auch nicht wie bei Lubuntu mit ehedem ubiquity simpel austricksen, indem man bspw. einen freien USB-Stick für in Summe mindestens 8 GiB steckt oder in der VM eine zweite Harddisk anhängt.

Man kann aber die Routine beenden und in LXTerminal (zweites Icon in der Leiste oben) den Check disablen, allerdings insgesamt, nicht nur die Mindestkapazität:

1

cnchi -n