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.
=================== 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.
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.
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?
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.
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?
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
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?
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
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.
ich habe heute den Fix aus dem Bugtracker probiert.
[ul]
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)
Netzwerkfähigkeit hergestellt mittels iptables -F und iptables -P INPUT ACCEPT
univention-install shim-signed grub-efi-amd64-signed # ok
univention-remove delo # nicht vorhanden - was soll delo eigentlich sein?
umount /boot/grub # bei mir nicht eingehangen
$EDITOR /etc/fstab # bei mir bereits auf efi gestellt
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.
Mit System Rescue CD erneut in das System gebootet
Offene Software Aktualisierung über UMC angestoßen
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.”.
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
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…
[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.
[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