Boot-Problem Fehler /vmlinuz... has invalid signature

Guten Morgen,

Gestern haben wir auf dem UCS die aktuellen Updates eingespielt.

Heute früh, nach einem planmäßigen Reboot, bleibt der Server mit folgender Fehlermeldung stehen:

[quote]Fehler: /vmlinuz-3.16.0-ucs135-amd64.efi.signed has invalid signature
Fehler: Sie müssen zuerst den Kernel laden.

Beliebiege Taste um fortzusetzen…

Sowohl Vorgabe als auch Alternativeinträge können nicht gebootet werden.
[/quote]
Irgendeine Idee?

Gruß, Uwe

Hi borisu,

bei mir exakt das selbe Problem. Gestern das Update von 3.2.1 auf 4.0.2 ausgelöst. Es lief auch soweit prima. Seit dann noch ein abschließender Neustart notwendig war, stehe ich vor dem Problem.

Secure Boot ist bei mir ausgeschaltet.

Habe mittels Boot-Repair einen Auszug der Bott-Konfiguration unter paste.ubuntu.com/11940877/ abgelegt.

Kann ich die vorgeschlagene Reperatur probieren?

=================== Suggested repair
The default repair of the Boot-Repair utility would purge (in order to sign-grub enable-raid enable-lvm) and reinstall the grub-efi-amd64-signed of mapper/vg_ucs-rootfs, using the following options:        sda2/boot, sda1/boot/efi,
Additional repair would be performed: unhide-bootmenu-10s


=================== Final advice in case of suggested repair
Please do not forget to make your BIOS boot on sda1/efi/.../grub*.efi file!


=================== User settings
The settings chosen by the user will not act on the boot.

Die Standard-Reparatur hat nicht funktioniert… Sieht alles noch so aus wie vorher. Jetzt lasse ich erst einmal die Finger weg davon.

Naheliegender als das Signaturproblem, wie es GRUB2 darstellt, scheint mir ja “=> No boot loader is installed in the MBR of /dev/sda” als Aussage von Boot-Repair zu sein.

Das macht ja gar keinen Sinn… soll ja gar nicht im MBR stehen, sondern im EFI-Bereich.

Hallo,

alle vorherigen Kernel können nicht mehr gebootet werden? Habe ich das korrekt verstanden?
Kann das System mithilfe einer System Rescue CD gebootet werden?
Es sollte dort die Möglichkeit geben ein bereits installiertes System/Kernel zu booten - damit würde man Grub-Probleme isolieren können und hätte einen kurzfristigen Workaround um ins System zu booten und weitere Maßnahmen zu ergreifen.

Mit freundlichen Grüßen,
Tim Petersen

Hi,

ja das ist korrekt, alle älteren können auch nicht geladen werden.
Hier der Versuch, es mit Rescue-CD zu starten (Option: bestehende Linux Installation booten):
picpaste.de/C360_2015-07-27-09-2 … c2hCyG.jpg
Er versucht von sdb zu booten. Dort dürfte sich eigentlich gar nichts befinden, denn es ist an sich meine reine Datenplatte, UCS ist auf sda…

Auf sdb - auf der Datenplatte - befindet sich tatsächlich noch eine alte Partition mit einer alten Linux-Installation. Seinerzeit scheinbar vergessen worden zu löschen. Diese findet Rescue-CD, den Startpunkt von UCS aber nicht. Wie bringen ich Rescue-CD dazu, UCS zu starten und wie geht es dann weiter?

Für eventuelle Analysezwecke hier noch mein Updater-Log
paste.ubuntu.com/11947744

Hallo Herr Petersen,

mit der Boot CD komme ich ins System. Es läuft zwar kein Netzwerk, aber als root anmelden geht.

Bei der Rescue CD nehme ich die Auswahl 5 “Boot an existing…”
Nach der Auswahl der Keymap läuft das System los, bringt dann aber IPv6Tables Fehlermeldungen. Es wird kein LDAP gestartet und Netzwerk ist auch nicht.

Habe die grub.cfg und ein ls von /boot angehängt.

Gruß, Uwe
Archive.zip (2.33 KB)

Servus,

bin wieder im System drinnen. Zwar mit dem vorhergehenden Kernel:
Linux server 3.16-ucs109-amd64 #1 SMP Debian 3.16.5-1.109.201412161258 (2014-12-16) x86_64 GNU/Linux
aber das tut erstmal.

Nachdem mich die Boot-CD zumindestens in das System gebracht hat nahm ich folgende Schritte vor:

  • /boot nach /boot.org kopiert
  • in /boot die neuen Kernelimages gelöscht
  • die /boot/grub/grub.cfg mit grub-mkconfig -o /boot/grub/grub.cfg überschrieben
  • reboot

Nachdem das System erstmal wieder läuft mach ich mich am Wochenende auf die Fehlersuche.

PS: Als errata Level wird mir 258 angezeigt. Wie kann ich die Errata-Level 248-251 erneut einspielen?

Gruß, Uwe

Ich schaffe es leider auch erst wieder am Wochenende, etwas zu basteln. Borisu, falls du die Fehlerquelle lokalisiert hast, wäre ich über dein Update sehr dankbar :slight_smile:
Eine Frage als Vertreter der nichtprofessionellen Homeserver-Betreiber unter den UCS-Enthusiasten: Gibt es eine Art Reparaturinstallation, mit der ich halbwegs schadlos aus der Situation komme? Vor dem letzten Runterfahren habe ich bereits die neue Oberfläche sehen können etc. Reicht es vielleicht bestimmte Verzeichnisse mittels Live-CD zu sichern und wieder einzuspielen?

Servus,

Bootet dein System wieder?

Leider haben die Logs nichts hergegeben. Wenn ich nur die Logs vor mir hätte müsste ich behaupten das Update sei normal durch gelaufen ;(

Sichern von einzelnen Dateien/Ordnern bringt nicht viel.
Sichern/Wiederherstellen ist unter wiki.univention.de/index.php?tit … CS-Systems gut beschrieben.

Unter
forge.univention.org/bugzilla/s … i?id=39024
ist auch noch keine Lösung (ausser meinem Workaround).

Gruß, Uwe

Moin,

Ich bin zuversichtlich, dass wir im Laufe der Woche da etwas erreichen werden - ich gebe gern an dieser Stelle Bescheid!

Viele Grüße,
Tim Petersen

Hallo,

die Kollegen haben an [bug]39024[/bug] einen möglichen Fix erarbeitet. Gerne können Sie den testen und uns Rückmeldung geben ob das auch für Sie so funktioniert:

univention-install shim-signed grub-efi-amd64-signed delo- # install missing software umount /boot/grub # (temporarily) umount EFI partition $EDITOR /etc/fstab # modify /boot/grub entry to be mounted at /boot/efi mkdir /boot/efi # create new mountpoint mount /boot/efi # remount EFI partition (on new mountpoint) find /boot/efi/ -mindepth 1 -xdev -delete # clean EFI partition grub-install # reinstall grub update-grub # make sure the config is up-to-date

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

ich denke nicht dass der Ansatz bei mir zur Lösung führt, da ich von Erratalevel 242 (UCS 4.0-2) das Update startete.

shim-signed ist bereits installiert und bei der Auswahl von “grub-efi-amd64-signed” kommt ein PopUp mit der Meldung:

Fortfahren nicht möglich Folgende Pakete werden installiert bzw. aktualisiert: grub-efi-amd64-signed Die Aktion führt bei folgenden Paketen zu nicht automatisch behebbaren Problemen: grub-efi-amd64-signed
Auf der Kommadozeile ein: “univention-install grub-efi-amd64-signed” ergibt:

Die folgenden Pakete haben unerfüllte Abhängigkeiten: grub-efi-amd64-signed : Hängt ab von: grub-efi-amd64 (= 2.00-18.91.201411041456) E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Die Ausgabe von dpkg -l |grep efi ergibt:

ii efibootmgr 0.5.4-3.5.201403211254 amd64 Interact with the EFI Boot Manager ii gnu-efi 3.0v-5.12.201410071506 amd64 Library for developing EFI applications ii grub-efi 2.00-18.92.201506300903 amd64 GRand Unified Bootloader, version 2 (dummy package) ii grub-efi-amd64 2.00-18.92.201506300903 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii grub-efi-amd64-bin 2.00-18.92.201506300903 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
Ein dpkg -C ergibt nichts.

Gruß, Uwe

Hi,

ich habe heute den Fix aus dem Bugtracker probiert.

[ul]

  1. Mit System Rescue CD in das noch unveränderte System gebootet (musste statt Stick von CD booten, damit ich die Option root=/dev/mapper/vg_ucs-rootfs benutzen konnte)
  2. Netzwerkfähigkeit hergestellt mittels iptables -F und iptables -P INPUT ACCEPT
  3. univention-install shim-signed grub-efi-amd64-signed # ok
  4. univention-remove delo # nicht vorhanden - was soll delo eigentlich sein?
  5. umount /boot/grub # bei mir nicht eingehangen
  6. $EDITOR /etc/fstab # bei mir bereits auf efi gestellt
  7. mkdir /boot/efi # bei mir bereits eingehangen
  8. find /boot/efi/ -mindepth 1 -xdev -delete # ok, Verzeichnis geleert
  9. grub-install # ok
  10. update-grub # ok
    [/ul]

Alle Versuche zu booten enden nun nach dem Bildschirm von GRUB im Nirvana (schwarzer Bildschirm, USB-Maus und Tastatur stromlos). Habe es sowohl mit als auch ohne Secure Boot versucht.

Ansonsten:

–> hat bei mir nicht geklappt

Jetzt bin ich an folgender Stelle:

[ul]

  1. Mit System Rescue CD erneut in das System gebootet
  2. Offene Software Aktualisierung über UMC angestoßen
  3. grub-install und update grub erneut ausgeführt
    [/ul]

Nun bekomme ich bei aktivem Secure Boot eine “Invalid signature detected. Check Secure Boot Policy in Setup” von UEFI.
Bei ausgeschaltetem Secure Boot bzw. angeschaltetem Secure Boot bei gleichzeitigem Löschen aller Factory-Default-Keys läuft es auf “Fehler: /vmlinuz-3.16.0-ucs135-amd64.efi.signed has invalid signature.”.

So ein Dilemma…

Hi,
nun hätte ich wohl die Chance noch auf 4.0-3 upzudaten. Seht ihr hier die Chance, bei diesem Vorgang heilend einzugreifen?
Ich habe leider auch immer nur am WE Zeit und bin um jeden Hinweis froh, der mich zeitsparend näher ans Ziel bringt :slight_smile:

Hallo,

ich stehe vor dem gleichen Problem, anscheinend liegt es an der falschen Version von grub-efi-amd64…
Unverständlicher weise, da bei vielen anderen das ja zu keinem Problem führt…

[code]root@homeserver:~# apt-get install grub-efi-amd64-signed
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
grub-efi-amd64-signed : Hängt ab von: grub-efi-amd64 (= 2.00-18.91.201411041456) aber 2.00-18.92.201506300903 soll installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
[/code]

@univention: gibt es eventuell die Version als Deb zum download? dann könnte ich die vielleicht versuchen manuell zu installieren…

@stev-e: das update auf 4.0-3 habe ich gemacht (auch vom rescue stick gestartet) bringt aber keine abhilfe…

grüße

Alex

Hallo,

[quote=“stev-e”]Nun bekomme ich bei aktivem Secure Boot eine “Invalid signature detected. Check Secure Boot Policy in Setup” von UEFI.
Bei ausgeschaltetem Secure Boot bzw. angeschaltetem Secure Boot bei gleichzeitigem Löschen aller Factory-Default-Keys läuft es auf “Fehler: /vmlinuz-3.16.0-ucs135-amd64.efi.signed has invalid signature.”.[/quote]
leider habe ich hierzu bisher auch nichts neues abgesehen von dem im letzten Post beschriebenen Workaround. Als alternative könnten Sie noch versuchen im UEFI des Systems auf den “Legacy” oder “BIOS”-Mode umzuschalten und das System so zu booten.

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

[quote=“Meybohm”][quote=“alexboehm85”]@univention: gibt es eventuell die Version als Deb zum download? dann könnte ich die vielleicht versuchen manuell zu installieren…[/quote] das Paket kann natürlich, wie alle anderen auch, direkt von software.univention.de bezogen werden. Die Installation wird aber höchst wahrscheinlich mit der gleichen Meldung scheitern. Sie könnten einmal prüfen was passier wenn Sie grub-efi-amd64 mit angeben: univention-install -s grub-efi-amd64-signed grub-efi-amd64[/quote] das stimmt so leider nicht. grub-efi-amd64-signed wurde anscheinend nicht zusammen mit grub-efi-amd64 aktualisiert und steht daher nicht zur Verfügung. Die Kollegen der Entwicklung werden das kurzfristig korrigieren.
Wenn Sie die Möglichkeit haben zu testen, können Sie einmal auf die alter Grub-Version zurück gehen:univention-install grub-efi-amd64-signed=2.00-18.91.201411041456 grub-efi-amd64=2.00-18.91.201411041456

Mit freundlichen Grüßen
Janis Meybohm

Mastodon