Openvz-Squeeze Kernel unter Wheezy?

[maxh]

Servus miteinander,

habe eine kleine Frage. Bei der Installation des OpenVZ-Kernels (linux-image-2.6.32-openvz-042stab081.8-amd64) aus dem Repository von OpenVZ für Wheezy kommt es immer zu Fehlern.
Ist es (unabhängig von OpenVZ) möglich den alten Squeeze Kernel unter Wheezy weiterzuverwenden?
Die alte Version ist: linux-image-2.6.32-5-openvz-amd64

Danke euch!

Code: Alles auswählen

server01:/usr/src# apt-get install linux-image-2.6.32-openvz-042stab081.8-amd64
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Vorgeschlagene Pakete:
  fdutils linux-doc-2.6.32-openvz-042stab081.8-amd64 linux-source-2.6.32-openvz-042stab081.8-amd64 ksymoops linux-image-2.6.32-openvz-042stab081.8-amd64-dbg
Die folgenden NEUEN Pakete werden installiert:
  linux-image-2.6.32-openvz-042stab081.8-amd64
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
Es müssen noch 0 B von 44,0 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 132 MB Plattenplatz zusätzlich benutzt.
Vorkonfiguration der Pakete ...
Vormals nicht ausgewähltes Paket linux-image-2.6.32-openvz-042stab081.8-amd64 wird gewählt.
(Lese Datenbank ... 59909 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacken von linux-image-2.6.32-openvz-042stab081.8-amd64 (aus .../linux-image-2.6.32-openvz-042stab081.8-amd64_1_amd64.deb) ...
Done.
linux-image-2.6.32-openvz-042stab081.8-amd64 (1) wird eingerichtet ...
[b]
 Hmm. There is a symbolic link /lib/modules/2.6.32-openvz-042stab081.8-amd64/build
 However, I can not read it: Datei oder Verzeichnis nicht gefunden
 Therefore, I am deleting /lib/modules/2.6.32-openvz-042stab081.8-amd64/build


 Hmm. The package shipped with a symbolic link /lib/modules/2.6.32-openvz-042stab081.8-amd64/source
 However, I can not read the target: Datei oder Verzeichnis nicht gefunden
 Therefore, I am deleting /lib/modules/2.6.32-openvz-042stab081.8-amd64/source

Running depmod.
WARNING: could not open /lib/modules/2.6.32-openvz-042stab081.8-amd64/modules.builtin: No such file or directory[/b]
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-openvz-042stab081.8-amd64 /boot/vmlinuz-2.6.32-openvz-042stab081.8-amd64
update-initramfs: Generating /boot/initrd.img-2.6.32-openvz-042stab081.8-amd64
[b]WARNING: could not open /var/tmp/mkinitramfs_Qv2Xzm/lib/modules/2.6.32-openvz-042stab081.8-amd64/modules.builtin: No such file or directory[/b]
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-openvz-042stab081.8-amd64 /boot/vmlinuz-2.6.32-openvz-042stab081.8-amd64
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found linux image: /boot/vmlinuz-2.6.32-openvz-042stab081.8-amd64
Found initrd image: /boot/initrd.img-2.6.32-openvz-042stab081.8-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-openvz-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-openvz-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
Found linux image: /boot/vmlinuz-2.6.18-20-ovz-amd64
Found initrd image: /boot/initrd.img-2.6.18-20-ovz-amd64
done

[rendegast]

download.openvz.org/debian:
Blöd:

• - Die Dateinameskonvention ist nicht gut umgesetzt, Version im Paketnamen <-> Paket-Version 1
  - Das Metapaket linux-image-openvz-.... trifft nicht das kernel-Paket.
  - Das header-Paket erzeugt nicht die Links source-> / build->

Manuelles Erstellen der Links, aber in der VM kann ich die VB-guest-dkms 4.1.18 doch nicht bauen.
Liegt wohl am inkompatiblen kernel 2.6.32.

Nichtsdestotrotz läuft der openvz-Kernel in der wheezy-VM.



Wegen des openvz-kernel aus squeeze,
bei einem dist-upgrade squeeze-wheezy zBsp. bleibt er ja erhalten.
Ob er dann auch startet/läuft ist eine Frage des Ausprobierens,
Evtl. gibt es Probleme / nötige Anpassungen beim wheezy-udev, evtl. nötiges Setzen von Kernelparametern.
Und die Frage, ob die vz*-Programme aus squeeze nötig wären, die aber in wheezy nicht laufen dürften (libc6).


----------------------------------------
-> Umsetzen mit einer anderen Virtualisierung?
LXC soll nach debian-wiki mit kernel 3.x wohl noch nicht sauber laufen.

[maxh]

Hi.
Danke für deine Antwort.

Es geht um den Host nicht um einen virtuellen Server. Im virtuellen Server benötigt man ja kein linux-image.
Hast du für den Host auch eine Idee?

Gruß,
Max

[rendegast]

Code: Alles auswählen

Es geht um den Host nicht um einen virtuellen Server. Im virtuellen Server benötigt man ja kein linux-image.

Richtig, aber ich muß den Kernel zum Ausprobieren ja nicht auf der realen Maschine installieren.
Das vb-guest-dkms-Modul war gerade installiert, daher habe ich auch mal den Test mit den Headers gemacht,
hätte auch fglrx-dkms oder nvidia-dkms oder ... probieren können.

Code: Alles auswählen

Hast du für den Host auch eine Idee?

Analog, einfach installieren,
preferences des Repo ~ 100 setzen.
Gewisse Probleme des Repo / der Pakete habe ich schon geschildert,
könnte mir denken, daß diese genau Deine Show-Stopper waren.

[maxh]

Ok. Danke dir soweit.
Muss gestehen, dass ich mich mit dem Thema Kernel immer nur alle 2-3 Jahre mal befasse, da ich i.d.R. in den VMs arbeite und man den Kernel da ja wenig anfassen muss.

Ich weiß auch nicht wie ich das manuell verlinken soll, aber das scheint ja ein Bug zu sein, den OpenVZ beheben muss. Das nervt ja tierisch...
Die Frage ist nur: Wird der Server trotzdem booten oder nicht?

Gruß,
Max

[rendegast]

Ich weiß auch nicht wie ich das manuell verlinken soll,

In dem Fall des openvz-Kernel/HeaderPaketes gibt es nur ein Header-Verzeichnis, daher:
/lib/modules/KERNELDIR/build -> /usr/src/HEADERDIR
/lib/modules/KERNELDIR/source -> /usr/src/HEADERDIR

(Bei debian-Kernel/HeaderPaketen ist gewöhnlich
/lib/modules/KERNELDIR/build -> /usr/src/HEADERDIR
/lib/modules/KERNELDIR/source -> /usr/src/HEADERDIR-common
)

Die Frage ist nur: Wird der Server trotzdem booten oder nicht?

Das Headerdir war mir ohnehin nicht nutzbar (kommt wohl auf die entsprechende Modul-Source an, s.o.).
Solltest Du keine separat zu bauenden Module (zum Start) benötigen,
kannst Du auf die Header gleich ganz verzichten.
Ob ein Gerät dann mit einem neuen Kernel bootet, dafür gibt es nur einen wirklichen Test.

Bei einem Remote-Server braucht es da eine passende failback-Strategie.