pvgrub2 mit blscfg

[fansari]

Wenn ich eine nicht von JiffyBox direkt unterstütze Linux Distribution "zu Fuß" installiere bootet mein Linux nicht, da der von Jiffybox verwendete pvgrub2 Bootloader des Xen Hypervisors kein blscfg.mod Modul lädt und demenstprechend das blscfg Kommando nicht zur Verfügung steht. Dieses wird aber von den automatisch erstellten Bootkonfigurationen benötigt.

Ob und wie ich das auf Guest VM seitig lösen könnte ist mir unklar (für Xen kompilierte Module stehen mir ja nicht zur Verfügung).

Hat jemand das Problem bereits gelöst oder bsteht die einzige Möglichkeit darin, dass DomianFactory das auf Hypervisor Ebene löst?

[Nils Dornblut]

Hallo fansari,

ich lasse Ihre Fragestellung intern einmal prüfen ob wir da etwas beitragen können.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Hallo fansari,

das sollte nun erledigt sein und Sie können das nutzen. Wir haben es bei uns gelöst.

Mit freundlichen Grüßen

Nils Dornblut

[fansari]

Davon kann leider keine Rede sein. Die letzte Antwort die ich am 02.11.2020 erhalten habe war wie folgt:

"Leider konnten wir blscfg aufgrund von Inkompatibilitäten zum zugrunde liegenden System nicht aktivieren. Da pvgrub chainload nur unter debian möglich ist, weil dort grub die platform xen integriert hat."

Praktisch bedeutet das, dass ich CoreOS nach jedem Update mit Hilfe des Recoverysystems wieder zum Leben erwecken muss, um eine Bootconfig zu erzeugen, dass Ihr Xen Hypervisor versteht.

[Nils Dornblut]

Hallo fansari,

tut mir leid, wenn dem nicht so war für Ihr Problem. Wie erklärt ist das leider in der fehlenden Implementierung innerhalb des Betriebssystems zu suchen Wenn es da in der Zukunft eine Weiterentwicklung gibt, schauen wir gerne erneut nach.

Mit freundlichen Grüßen

Nils Dornblut

[fansari]

Für mich ist das Fehlen des Moduls blscfg in grub nicht akzeptabel. Ich habe daher meine JiffyBox gelöscht und mir einen anderen Anbieter gesucht, der diese Probleme nicht hat.

Dort wird KVM als Hypervisor eingesetzt und das grub des von mir installierten OS verwendet und nicht das grub des Hypervisors. Diese Vermischung führt offensichtlich zu dem Problem.