Discussion:
[E64] Eisfair unter Hyper-V installieren
(zu alt für eine Antwort)
Karl Heinrich Meyer
2020-05-31 10:29:44 UTC
Permalink
Hallo,

ich betreibe einen Eisfair (32-bit) seit einigen Jahren unter
Server2012R2 Hyper-V als virtuelle Maschine. Da hier keine Kernelupdates
mehr möglich sind (Platte wird doppelt erkannt als HDA vom
Kernel-Treiber und als SDA vom Hyper-V-Treiber und HDA lässt sich nicht
zu Disk-by-ID konvertieren) habe ich eine Neuinstallation versucht.

Mit dem aktuellen Installer der 64-bit Version komme ich bis zur Auswahl
des Plattentreibers. Nach Auswahl von 27 hv-storvsc folgt

Loading SCSI/SATA/RAID/USB-STORAGE drivers ...
hv_storvsc
hv_storvsc: Unknown symbol fc_attach_transport (err0)
hv_storvsc: Unknown symbol fc_remove_host (err0)
hv_storvsc: Unknown symbol fc_release_transport (err0)
insmod: ERROR: could not insert module
/lib/modules/4.19-210-eisfair-64-VIRT/kernel/drivers/scsi/hv_storvsc.ko:
Unknown symbol in module

und er findet keine disk, auch nicht mit dem ata_piix, der in der
32-bit-SMP Version die virtuelle Platte erkennt. Unter einer neu
installierten 32-bit Version führt im übrigen der Update vom SMP auf den
gleichen Virt-Kernel zu einer Kernel-Panic, das habe ich aber nicht
näher untersucht.
Thomas Bork
2020-05-31 14:24:32 UTC
Permalink
Post by Karl Heinrich Meyer
Mit dem aktuellen Installer der 64-bit Version komme ich bis zur Auswahl
des Plattentreibers. Nach Auswahl von 27 hv-storvsc folgt
Loading SCSI/SATA/RAID/USB-STORAGE drivers ...
 hv_storvsc
hv_storvsc: Unknown symbol fc_attach_transport (err0)
hv_storvsc: Unknown symbol fc_remove_host (err0)
hv_storvsc: Unknown symbol fc_release_transport (err0)
insmod: ERROR: could not insert module
Unknown symbol in module
Wundert mich nicht. Ich habe zwar scsi-list um den Treiber hv_storvsc
ergänzt aber anscheinend vergessen, scsi.sh anzupassen. Damit fehlt
hv_storvsc das erforderliche Modul scsi_transport_fc.ko.
Post by Karl Heinrich Meyer
und er findet keine disk, auch nicht mit dem ata_piix, der in der
32-bit-SMP Version die virtuelle Platte erkennt.
Sicher, dass Du das mit der gleichen Generation Installer getestet hast?
Beim Wechsel auf den Kernel 4.9 (jetzt in den aktuellen Installern)
haben wir die Treiber abgeschafft, die IDE als /dev/hd* interpretieren.
Eventuell wurden die IDE-Platten unter Hyper-V nur mit diesen Treibern
erkannt, die damals fest einkompiliert waren.
Post by Karl Heinrich Meyer
Unter einer neu
installierten 32-bit Version führt im übrigen der Update vom SMP auf den
gleichen Virt-Kernel zu einer Kernel-Panic, das habe ich aber nicht
näher untersucht.
Hat wahrscheinlich die selbe Ursache wie oben. Also muss unter Hyper-V
nun immer mit dem 64-Bit-Installer und hv-storvsc installiert werden.
Geht natürlich erst, wenn ich das obige Problem behoben habe
(Abhängigkeit zu scsi_transport_fc.ko).
--
der tom
[eisfair-team]
Karl Heinrich Meyer
2020-05-31 17:02:35 UTC
Permalink
Post by Thomas Bork
Post by Karl Heinrich Meyer
Mit dem aktuellen Installer der 64-bit Version komme ich bis zur
Auswahl des Plattentreibers. Nach Auswahl von 27 hv-storvsc folgt
Loading SCSI/SATA/RAID/USB-STORAGE drivers ...
  hv_storvsc
hv_storvsc: Unknown symbol fc_attach_transport (err0)
hv_storvsc: Unknown symbol fc_remove_host (err0)
hv_storvsc: Unknown symbol fc_release_transport (err0)
insmod: ERROR: could not insert module
Unknown symbol in module
Wundert mich nicht. Ich habe zwar scsi-list um den Treiber hv_storvsc
ergänzt aber anscheinend vergessen, scsi.sh anzupassen. Damit fehlt
hv_storvsc das erforderliche Modul scsi_transport_fc.ko.
Post by Karl Heinrich Meyer
und er findet keine disk, auch nicht mit dem ata_piix, der in der
32-bit-SMP Version die virtuelle Platte erkennt.
Sicher, dass Du das mit der gleichen Generation Installer getestet hast?
Beim Wechsel auf den Kernel 4.9 (jetzt in den aktuellen Installern)
haben wir die Treiber abgeschafft, die IDE als /dev/hd* interpretieren.
Eventuell wurden die IDE-Platten unter Hyper-V nur mit diesen Treibern
erkannt, die damals fest einkompiliert waren.
Post by Karl Heinrich Meyer
Unter einer neu installierten 32-bit Version führt im übrigen der
Update vom SMP auf den gleichen Virt-Kernel zu einer Kernel-Panic, das
habe ich aber nicht näher untersucht.
Hat wahrscheinlich die selbe Ursache wie oben. Also muss unter Hyper-V
nun immer mit dem 64-Bit-Installer und hv-storvsc installiert werden.
Geht natürlich erst, wenn ich das obige Problem behoben habe
(Abhängigkeit zu scsi_transport_fc.ko).
Hallo,

gerade noch mal gestestet. Der aktuelle 32-bit Installer findet bei
Auswahl des SCSI-Treibers mit Ja und Auswahl=0 keiner die Platte als
sda. Kann ja nur der ATA-PIIX sein der für das CD-ROM bereits geladen
ist. Lässt sich so auch bis zum Testing-Kenrel 5.1 akualisieren. Erst
beim Nachinstallieren des VIRT-Kernels kommt dann die Kernel-Panic.

Beim 64-bit Installer findet der ata_piix aber nur das CD-ROM und nicht
die Platte, egal ob mit Auswahl=0 oder oder ob Auswahl=14 (ata__piix)
explizit ausgewählt wird.

Ist aber im Moment nicht so wichtig, noch läuft meine alter 32-bit EIS
ja noch. Problematisch wird es erst, wenn Updates den neueren Kernel
voraussetzen.

Schöne Pfingsten noch und danke für die viele Arbeit am EIS
Thomas Bork
2020-05-31 18:35:50 UTC
Permalink
Post by Karl Heinrich Meyer
Hallo,
gerade noch mal gestestet. Der aktuelle 32-bit Installer findet bei
Auswahl des SCSI-Treibers mit Ja und Auswahl=0 keiner die Platte als
sda. Kann ja nur der ATA-PIIX sein der für das CD-ROM bereits geladen
ist. Lässt sich so auch bis zum Testing-Kenrel 5.1 akualisieren. Erst
beim Nachinstallieren des VIRT-Kernels kommt dann die Kernel-Panic.
Ok, die Logik sieht anscheinend so aus:
Ist kein Modul hv_storvsc vorhanden, fühlt sich ata_piix für die
virtuellen Controller zuständig. Ist hv_storvsc vorhanden, dann spricht
ata_piix die Controller nicht mehr an.

Damit ist klar:
Sobald Du den VIRT-Kernel installierst, nachdem vom 32-Bit-Installer
ursprünglich installiert hattest, verlierst Du den Zugriff auf die Platten.

Also:
Installiere in diesem Fall den VIRT-Kernel _nicht_.
Post by Karl Heinrich Meyer
Beim 64-bit Installer findet der ata_piix aber nur das CD-ROM und nicht
die Platte, egal ob mit Auswahl=0 oder oder ob Auswahl=14 (ata__piix)
explizit ausgewählt wird.
Ist nach der obigen Logik klar:
Da der 64-Bit-Installer mit dem Modul hv_storvsc kommt, fühlt sich
ata_piix nicht mehr zuständig.
Post by Karl Heinrich Meyer
Post by Thomas Bork
Hat wahrscheinlich die selbe Ursache wie oben. Also muss unter Hyper-V
nun immer mit dem 64-Bit-Installer und hv-storvsc installiert werden.
Geht natürlich erst, wenn ich das obige Problem behoben habe
(Abhängigkeit zu scsi_transport_fc.ko).
--
der tom
[eisfair-team]
Thomas Bork
2020-05-31 19:54:52 UTC
Permalink
Post by Thomas Bork
Ist kein Modul hv_storvsc vorhanden, fühlt sich ata_piix für die
virtuellen Controller zuständig. Ist hv_storvsc vorhanden, dann spricht
ata_piix die Controller nicht mehr an.
Genau so ist es. Dieses Verhalten kann man mit einer Option des Moduls
ata_piix übersteuern:

49 # modinfo ata_piix | grep hyper
parm: prefer_ms_hyperv:Prefer Hyper-V paravirtualization
drivers instead of ATA, 0 - Use ATA drivers, 1 (Default) - Use the
paravirtualization drivers. (int)

Per Default gewinnt hv_storvsc, wenn es vorhanden ist.

Nun könnte man in der initramfs den hv_storvsc blacklisten und dem
ata_piix die Option prefer_ms_hyperv=0 mitgeben, um auch bei
Vorhandensein des hv_storvsc die Platten mit dem ata_piix anzusteuern,
das würde aber je nach System wieder zu unterschiedlichen
initramfs-Dateien führen und das ganze Handling bei Kernel-Updates
unnötig verkomplizieren. Denn wer entscheidet, wann man das tun sollte
und wann nicht?
Post by Thomas Bork
Post by Thomas Bork
Hat wahrscheinlich die selbe Ursache wie oben. Also muss unter Hyper-V
nun immer mit dem 64-Bit-Installer und hv-storvsc installiert werden.
Geht natürlich erst, wenn ich das obige Problem behoben habe
(Abhängigkeit zu scsi_transport_fc.ko).
--
der tom
[eisfair-team]
Loading...