ich habe versucht, ein OpenSuse 13.1 auf dem Notebook per DVD auf 13.2 zu aktualisieren. Am Ende des Upgrades erhalte ich folgende Fehlermeldung:
undefined method sort' for nil:NilClass Caller: /mounts/mp_0001/usr/YaST2/modules/kernel.rb:626: in block in SaveModulesToLoad’
Beim anschließenden Reboot wird kein Kernel gefunden.
Hat jemand eine Idee, was da schief läuft? Kann man das Problem fixen/umgehen? (Habe ein Clonezilla-Image der 13.1-Installation, kann die Sache also wiederholen.)
An sich sollte die nicht notwendig sein (ich habe/hatte sie auf keinem meiner Systeme, die erfolgreich upgegradet wurden).
Genau weiß ich auch nicht was da schief läuft, aber ich vermute mal dass die während des Upgrades aus /etc/sysconfig/kernel erzeugt wird, um die “MODULES_LOADED_ON_BOOT” Einstellung dort zu migrieren (zumindest das meiste in /etc/sysconfig/kernel wird in 13.2 ignoriert).
Vielleicht liegts also auch einfach nur daran, dass du kein “MODULES_LOADED_ON_BOOT” in /etc/sysconfig/kernel hast?
Probier das einfach mal am Ende einzufügen:
Tja, im Bug Report war jetzt scheinbar das Vorhandensein dieser Datei (und der “MODULES_LOADED_ON_BOOT” Zeile in /etc/sysconfig/kernel) die Ursache für das Problem.
Kannst du bitte mal deine /etc/sysconfig/kernel posten? Vielleicht entdecke ich da ja was Verdächtiges.
Jedenfalls ist da natürlich ein Bug in kernel.rb (oder wo auch immer) der behoben werden sollte.
Allerdings hatte ich das Problem nicht auf beiden Systemen die ich upgegradet habe (und es gibt auch nicht viel andere Beschwerden darüber).
Also dürfte der Fehler nur unter ganz bestimmten Umständen auftreten.
Hoffentlich wird die genaue Ursache bald gefunden…
## Path: System/Kernel
## Description:
## Type: string
## Command: /sbin/mkinitrd
#
# This variable contains the list of modules to be added to the initial
# ramdisk by calling the script "mkinitrd"
# (like drivers for scsi-controllers, for lvm or reiserfs)
#
INITRD_MODULES=""
## Type: yesno
## Default: ""
## Command: /sbin/mkinitrd
#
#
# This variable disables the initialization of KMS in the initrd
# by not including the modules required for KMS even though KMS is
# supported on the underlying hardware.
# After changing run mkinitrd again.
#
NO_KMS_IN_INITRD="no"
## Type: string
## Command: /sbin/mkinitrd
#
# This variable contains the list of modules to be added to the initial
# ramdisk that is created for unprivilegd Xen domains (domU); you may need
# drivers for virtual block and network devices in addition to filesystem
# and device-mapper modules.
#
DOMU_INITRD_MODULES="xennet xenblk"
## Type: string
## Default: ""
#
# The file name of a binary ACPI Differentiated System Description Table
# (DSDT). This table is appended to the initial ram disk (initrd) that
# the mkinitrd script creates. If the kernel finds that its initrd
# contains a DSDT, this table replaces the DSDT of the bios. If the file
# specified in ACPI_DSDT is not found or ACPI_DSDT is empty/not specified,
# no DSDT will be appended to the initrd.
# Example path /etc/acpi/DSDT.aml
# You can also override Secondary System Description Tables (SSDTs).
# Add DSDT and SSDT files separated by spaces, e.g. "DSDT.aml SSDT1.aml"
# The files must be named DSDT.aml and/or SSDT[1-9]*.aml.
# For compatiblity reasons, if only one file is added it is assumed it is
# the DSDT and will be used as such, in future the above naming scheme
# will be enforce.
# Be aware that overriding these tables can harm your system.
# Only do this if you know what you are doing and file a bug on
# bugzilla.kernel.org so that the root cause of the issue will get fixed.
ACPI_DSDT=""
Kann es irgendwie mit der Kernelversion zusammen hängen? Ich habe - nicht beabsichtigt, vom Händler vorkonfiguriert - den Kernel aus dem “Kernel_stable”-Repository:
xy:~ # uname -a
Linux xy 3.17.2-1.g1afb260-desktop #1 SMP PREEMPT Thu Oct 30 19:14:09 UTC 2014 (1afb260) x86_64 x86_64 x86_64 GNU/Linux
Ich hatte allerdings gestern schon ein Downgrade auf den Kernel aus dem “repo-update” gemacht und dann das Upgrade auf 13.2 - das Problem war das gleiche. Aber ich weiß halt nicht, ob der neuere Kernel nicht vielleicht doch irgendwelche Spuren hinterlassen hat… ?
PS: Mit dem letzten posting von Lukas Ocilka (comment 10) kann ich nichts anfangen - schätze, der ist nur für Entwickler relevant?
Nein, nicht wirklich. Ich seh sa nichts Verdächtiges.
Und tatsächlich schaut sie exakt so aus wie meine…
Kann es irgendwie mit der Kernelversion zusammen hängen? Ich habe - nicht beabsichtigt, vom Händler vorkonfiguriert - den Kernel aus dem “Kernel_stable”-Repository:[/QUOTE]
Kann ich mir eigentlich nicht vorstellen.
PS: Mit dem letzten posting von Lukas Ocilka (comment 10) kann ich nichts anfangen - schätze, der ist nur für Entwickler relevant?
Ja. Wenn ich es richtig verstehe haben sie es geschafft den Fehler mit einem Testfall zu reproduzieren.
Tja, im Moment weiß ich jetzt leider auch nicht weiter.
Momentan bleibt wohl nur abwarten. Allerdings, da der Fehler ja im Installer ist, hilfts dir wohl auch nichts wenn er behoben wird.
Du könntest aber mal probieren, per “zypper dup” upzugraden.
Da das ja scheinbar ein Problem im YaST ist, solltest du es dadurch umgehen.
Dazu einfach die URLs deiner Repos von 13.1 auf 13.2 ändern (in YaST->Software Repositories z.B.). Oder du deaktivierst alle Repos und bindest die DVD als Repo ein, damit du nicht alles nochmal runterladen musst.
Dann einfach “sudo zypper dup” (im laufenden System) aufrufen um das Upgrade zu starten. Hat bei mir einwandfrei auf 2 Systemen geklappt.
Gute Idee, die DVD als Repo einzubinden und dann mit zypper dup zu upgraden - danke für den Tipp!
Allerdings zerschießt mir auch das das System: er versucht nach dem Reboot nach wie vor vom “alten” Kernel zu booten, der aber natürlich nicht mehr da ist…
Grub2 meldet: premature end of file /boot/vmlinuz-3.17.2-1.g1afb260-desktop
Beim nächsten Bootvorgang gerät Grub2 dann in eine Endlosschleife: Es wird für Sekundenbruchteile: “Welcome to Grub” angezeigt, dann resetet das System wieder.
Grub zeigt außerdem kein Menü an und ich habe keine Möglichkeit, mit e in den Editiermodus zu gehen.
Ich habe dann versucht, das über das Rettungssystem und chroot zu bereinigen - Fehlanzeige. Ich kann zwar über yast bootloader die Konfiguration anzeigen, aber jede Änderung dort wird kommentarlos ignoriert. Ich sehe dort, dass mehrere Menüeinträge zur Verfügung stehen, könnte dort den Default-Eintrag auswählen - das wird aber wie gesagt ignoriert. Die Möglichkeit, die Menüeinträge zu editieren ist wohl verschwunden. Ebenso verschwunden ist eine Möglichkeit, die früher schon oft solche Situationen gerettet hat: das Löschen der Bootkonfiguration und einen neuen Vorschlag erstellen zu lassen.
(Ehrlich gesagt, ich bin frustriert. Nicht nur funktioniert das Upgrade nicht, auch sonst hat sich einiges zum Negativen geändert… meine positive Meinung von OpenSuse ist in den letzten Stunden ziemlich nach unten gegangen…)
Nach dem Upgrade und vor dem Reboot habe ich nochmal yast bootloader aufgerufen und dort die Optionen zum Schreiben des generischen MBR, zum Start aus Root und Bootpartition aktiviern aktiviert. Außerdem unter Standard-Bootabschnitt den durch das Upgrade installierten 3.16.6-2-desktop ausgewählt, sowie VGA-Modus “1920x1080, 24 Bit (Modus 0x37f)” und Konsolenauflösung “1920x1080” (war auf Auto). Danach gleich noch ein zweites Mal rein, um zu sehen, ob er sich die Einstellungen merkt - bis auf den VGA-Modus OK.
Reboot - und hurra, er zeigt das grafische Menü an und bootet hoch.
Allerdings ignoriert er den Standard-Bootabschnitt und startet den 3.17er Kernel (der doch noch da ist, da hatte ich mich vorhin getäuscht).
Für mich sieht das so aus, als hätte es vorhin nicht daran gelegen, dass er den falschen Kernel zu booten versuchte, sondern dass im Rahmen des Upgrades irgendwie der Bootloader nicht ordentlich installiert wird? Was aber aus dem Rettungssystem nicht zu reparieren war… :\ Und was ich nach wie vor nicht verstehe: wie kann ich alte Einträge aus dem Grub2-Menü entfernen bzw. ein Default setzen? (Ist zwar nicht wirklich wichtig, aber interessieren würd’s mich.)
Das versteh ich jetzt nicht ganz. Er bootet immer den 3.17er kernel auch wenn du was anderes auswählst?
Oder meinst du das der falsche Eintrag als default ausgewählt wird?
Probier mal die Datei /boot/grub2/grubenv zu löschen, die kann das Default ändern (es ist zum Beispiel möglich die Auswahl vom letzten Boot zu speichern sodass der zuletzt gewählte Eintrag automatisch beim nächsten Mal ausgewählt ist. Das speicher grub2 dann in der Datei grubenv).
Aber normalerweise ist eben automatisch der Kernel mit der höchsten Versionsnummer default. Deine Beschreibung hört sich also eigentlich normal an.
Wenn du aus irgendeinen Grund den 3.17er Kernel entfernen willst, kannst du das in YaST->Software installieren/entfernen tun. Nach “kernel” suchen und auf “Versionen” unter der Paketliste klicken. Dann kannst du einzelne Versionen installieren/deinstallieren.
In diesem Fall solltest du aber eher auch das Kernel:stable repo entfernen/deaktivieren, das geht in YaST->Software Repositories, sonst wird der vermutlich automatisch wieder installiert (als “Update”).
Für mich sieht das so aus, als hätte es vorhin nicht daran gelegen, dass er den falschen Kernel zu booten versuchte, sondern dass im Rahmen des Upgrades irgendwie der Bootloader nicht ordentlich installiert wird? Was aber aus dem Rettungssystem nicht zu reparieren war… :\
Tja, ein ähnliches Problem haben auch schon (2) andere Leute berichtet. Komischerweise beide mit Kernel 3.17 (der eine zumindest, beim anderen bin ich jetzt nicht sicher), k.A. ob das Relevanz hat.
Scheinbar sind da Spuren vom alten Grub2 im MBR zurückgeblieben. Durch Schreiben von generischen Bootcode wurde das entfernt.
Es ist sowieso besser im MBR nur generischen Bootcode zu haben, vor allem wenn du mehrere Betriebssysteme installiert hast. Das vermeidet dass dein Bootloader von einem anderen OS überschrieben wird…
Und was ich nach wie vor nicht verstehe: wie kann ich alte Einträge aus dem Grub2-Menü entfernen bzw. ein Default setzen? (Ist zwar nicht wirklich wichtig, aber interessieren würd’s mich.)
Die Einträge werden automatisch angelegt, je nach vorhandenen Kernels und Betriebssystemen.
Ein Default kannst du in YaST->System->Bootloader setzen (unter Bootloader-Optionen).
Letzteres. Unter yast bootloader -> Bootloader-Optionen -> Standard-Bootabschnitt steht “openSUSE, mit Linux 3.16.6-2-desktop”. Ich hätte erwartet, dass dann dieser Kernel gebootet wird, wenn ich am Grub2-Bootmenü nicht eingreife (ich habe Timeout 3s und lasse die durchlaufen), ist aber nicht so. Es wird - wie du schreibst - wohl immer der Kernel mit der höchsten Versionsnummer gestartet. Dann leuchtet mir halt nur der Sinn der Option nicht ein…
Eigentlich ist mir das egal, es war mir ja bis vor kurzem gar nicht bewusst, dass ich gar nicht den Kernel aus dem Standard-Repository habe… nur wenn Probleme auftauchen, denkt man halt zuerst an das, was nicht Standard ist…
So wie’s aussieht habe ich jetzt mein System wieder ordentlich am Laufen - war im Vergleich zu den Upgrades seit 11.irgendwas eine eher schwere Geburt (VirtualBox hat mich noch ein paar Nerven gekostet - die Version aus dem openSuse-Repository habe ich nicht zum laufen gekriegt; habe jetzt wieder das Repo von virtualbox.org eingebunden, damit ging’s sofort).
Nein. Eigentlich sollte der Eintrag der dort gesetzt ist gebootet werden.
Wenn nicht ists ein Bug.
Ich hab das aber noch gar nicht in 13.2 ausprobiert… Normalerweise ändere ich den Default-Eintrag nicht.
So wie’s aussieht habe ich jetzt mein System wieder ordentlich am Laufen - war im Vergleich zu den Upgrades seit 11.irgendwas eine eher schwere Geburt (VirtualBox hat mich noch ein paar Nerven gekostet - die Version aus dem openSuse-Repository habe ich nicht zum laufen gekriegt; habe jetzt wieder das Repo von virtualbox.org eingebunden, damit ging’s sofort).
Die openSUSE Version läuft einwandfrei hier.
Hast du vielleicht vboxgtk anstelle von virtualbox-qt als GUI installiert? (könnte automatisch ausgewählt worden sein)
Das ist eine GTK (GNOME) Alternative, wurde aber seit 2 Jahren nicht weiterentwickelt, unterstützt VirtualBox ab 4.2 nicht vollständig, und funktioniert jetzt in 13.2 gar nicht mehr (lässt sich nicht starten).
Aus diesen Gründen wurde sie auch letzte Woche aus der Distribution geschmissen, aber in 13.2 ist das Paket leider noch enthalten…
virtualbox-qt hingegen funktioniert einwandfrei (das ist die offizielle GUI, dir auch im Oracle Paket enthalten ist).
Ist aber im Prinzip eh egal welches du verwendest, wenn du das Repo von virtualbox.org einbindest (war eh in der Liste die du gepostet hast), bekommst du auch immer das Aktuellste als Update…
Kleiner Nachtrag: Auf einem anderen Rechner hat das Offline-Upgrade von DVD (nicht per zypper) einwandfrei funktioniert, das Problem ist nicht aufgetreten.
