Hallo,
nutze UCS auf einem Fujitsu Primergy RX1330 M1 (quasi Standardhardware), dennoch will das System mit dem neuen Kernel nicht booten – der “alte” 3.16 läuft anstandslos.
Gibt es ähnliche Erfahrungen?
Danke und Gruß
Criena
Hallo,
Können sie nähere detaillierte Informationen zu der eingesetzten Hardware geben? Im Speziellen: Board, Controller, etc.?
Mit freundlichem Gruß,
Jens Thorp-Hansen
Hallo Herr Hansen,
das Board ist ein Fujitsu D3229, mit Intel C226 Chipsatz. Der Prozessor (vermutlich weniger relevant) ist ein Xeon E3-1240Lv3.
# lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family Thermal Management Controller (rev 05)
01:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05)
01:00.1 Co-processor: Emulex Corporation Device 0800
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
Data Sheet: http://sp.ts.fujitsu.com/dmsp/Publications/public/ds-py-rx1330-m1.pdf
Kann es sein, dass die Unterstüzung für den Chipsatz aus ihrem 4.1-Kernel entfernt wurde?
Ich erhalte nach Grub ein kurzes “Loading…”, dann blitzt der graue Boot-Hintergrund (mit dem grünen Univention-Logo) auf und anschließend erscheint “Loading…” erneut. An diesem Punkt hängt sich das System auf. Ein Hard-Reset ist erforderlich.
Das ist insofern unschön, als dass die Docker-Unterstützung erst mit 4.1 vorhanden ist und die neue UCS-Version ohne Docker gar keine Zusatz-Software mehr installiert.
Vielen Dank für die Hilfe und einen guten Rutsch
Criena
Hallo,
Es ist gerade nicht klar, wo das System während des Bootvorgangs hängen bleibt. Es würde uns helfen, wenn das System einmal mit maximalen Debug-Ausgaben gestartet wird. Dafür muss das System einmal mit Kernel 3.16 gebootet werden und einige UCR-Variable gesetzt werden:
ucr set grub/loglevel=7 grub/quiet=no grub/bootsplash=nosplash
Anschließend muss der Kernel 4.1 gebootet werden. Wenn das System hängen bleibt, benötigen wir einen Screenshot bzw. ein Foto des Bildschirms. Anschließend kann das System wieder mit Kernel 3.16 gebootet und die alten Booteinstellungen mit folgendem Befehl wieder hergestellt werden:
ucr set grub/loglevel=0 grub/quiet=yes grub/bootsplash=splash
Mit freundlichem Gruß,
Jens Thorp-Hansen
Hallo Herr Hansen,
anbei der Screenshot:
Die Systempartition kann wohl nicht gefunden werden. Da diese am USB 3.0-Bus hängt, fehlt eventuell der passende Treiber im Kernel/initrd?
Gruß
Criena
Hallo,
Die Meldung besagt dass die USB3-Platte nicht gefunden wird. Warum kann man gerade leider nicht sehen. Ggf. werden nicht alle Kernelmodule in die Initrd übernommen, so dass der Treiber für die USB3-Platte fehlt. Man könnte mal folgendes ausprobieren:
ucr set initramfs/modules=all
update-initramfs -u -k 4.1.0-ucs153-amd64
update-initramfs -u -k 4.1.0-ucs163-amd64
Mit freundlichem Gruß,
Jens Thorp-Hansen
Hallo Herr Hansen,
“all” scheint kein valider Wert für die Variable zu sein:
update-initramfs: Generating /boot/initrd.img-4.1.0-ucs163-amd64
W: mkinitramfs: unsupported MODULES setting: all.
W: mkinitramfs: Falling back to MODULES=most.
Da “most” der Standard ist, gab es hier keine Änderung des Ergebnisses.
Ich habe die Kernel-Configs von 3.16 und 4.1 miteinander verglichen und konnte keine Änderungen im Bereich USB erkennen.
Dennoch habe ich die /etc/initramfs-tools/modules um folgende Zeilen ergänzt und ein neues initrd erstellt:
ehci_pci
ehci_hcd
xhci_hcd
usbhid
hid
usb_storage
Auch hier leider keine Änderung des Ergebnisses.
Ich verstehe nicht warum der eine Kernel läuft, der andere aber nicht. Es scheint aber zumindest kein UCS-spezifisches Problem zu sein.
Eine kleine Anmerkung: in lsinitramfs (Teil des Pakets initramfs-tools) existiert ein Bug der das Anzeigen der gepackten Module bei neuren Kerneln verhindert. Laut Debian Bug #717805 ist das Problem in einer neueren Version bereits gefixt.
Heureka, gelöst!
Durch Zufall bin ich auf folgenden Artikel gestoßen: https://blog.tschoerner.eu/2016/04/10/debianubuntu-bootet-nicht-da-das-root-device-nicht-gefunden-werden-kann/.
Danach habe ich mir nochmals meine Anpassungen an etc/initramfs-tools/modules angeschaut. Das Modul xhci-hcd war zwar dabei, xhci-pci fehlte jedoch. Mit neuer etc/initramfs-tools/modules (lediglich die beiden XHCI-Module) fix eine initrd erstellt, gebootet und… siehe da, es läuft.
Schönen Sonntag
Criena