forum.opsi.org

Hi Forum,

wir nutzen opsi mit grub boot. Folgendes Problem. Wenn Windows durchinstalliert hat, bügeln wir mit opsi-uefi-netboot die Bootreihenfolge wieder auf Netzwerk an erster Stelle. Nun ist es bei der neuen Hardwareklasse HP 400 g6 Bios Version S23 Ver. 02.06.02 so, dass wenn das Gerät nun wieder von Netzwerk startet und es liegt keine Pipefile für die MAC vor(da Windows ja schon installiert) verhaspelt sich der Rechner wie folgt:
1. Er bootet grub.cfg
2. statt dass er die local disk bootet, gibt er ein UEFI boot menu zurück

Anscheinend läufts hier schief:
menuentry 'Local Disk' {
exit
}
Also wenn er das hier macht, kommt wieder vom UEFI eine Abfrage, ob man Netzwerk oder Platte starten will, das ist interaktiv und man kommt hier nicht weiter, bis man händisch was auswählt....

Habt Ihr eine Idee?

VG
Andreas

Code: Alles auswählen

tftpboot/grub# dpkg -l | grep opsi
ii  lmz-opsi-base                          4.0.0-20200723-01                               all          Basiskonfiguration und Tools fuer die paedML(R) Windows.
ii  lmz-opsi-keyring                       4.0.0-2019-03                                   all          GnuPGP-Schluessel fuer die LMZ-Repositorien.
ii  lmz-opsi-patches                       4.0.0-20191008-01                               all          Patches fuer den opsi-Server in der paedML(R) Windows.
ii  lmz-opsi-postupdate                    4.0.0-20190626-01                               all          Konfigurationspaket (postinstall).
ii  lmz-opsi-preupdate                     4.0.0-20200413-01                               all          Konfigurationspaket (preinstall).
ii  opsi-configed                          4.0.7.6.34-2                                    all          OPSI config editor
ii  opsi-directory-connector               31.1-1                                          all          opsi directory connector.
ii  opsi-linux-bootimage                   20200506-1                                      all          opsi bootimage for netboot tasks.
ii  opsi-linux-support                     4.1.1-3                                         all          Configure system to be able to deploy Linux with opsi.
ii  opsi-server                            4.1.1.8-1                                       all          opsi server configuration package
ii  opsi-tftpd-hpa                         5.2.8-52                                        amd64        HPA's tftp server
ii  opsi-utils                             4.1.1.35-1                                      all          utilites for working with opsi.
ii  opsi-vm-config                         4.1.2                                           all          Configuration of opsi VM.
ii  opsi-windows-support                   4.1.1-8                                         all          Install utilities useful for deploying Windows with opsi.
ii  opsiconfd                              4.1.1.20-1                                      all          opsi configuration service
ii  opsipxeconfd                           4.1.1.19-2                                      all          opsi pxe configuration daemon
ii  python-opsi                            4.1.1.89-1                                      all          opsi python library

I guess the problem is not with opsi, just a b0rked UEFI implementation.

I don't know if you have this HP 400 G6, but look here: https://support.hp.com/my-en/drivers/se ... c-277477-1
Especially the revision history has some items about boot order. Otherwise see if you can contact HP (as if), because if it's a problem in their UEFI they should fix it, and opsi can't probably help much with that.

Also, don't forget to update to update your opsi server.

Hi,

thanx for sharing your info. Firmware results:
- rollback: does not fix my problem
- latest: does not fix my problem

Cant believe that such a big distributor like HP did a crappy uefi implementation...

we have to stick on that opsi releases cuz we using paedml windows. We did not have the problem with elilo boot.

greets from Germany

Doch das kannst du rihig glauben.
Dell, HP und Konsorten haben teilweise bescheidene UEFI Implementationen. Liegt aber auch am schwammigen Standart der zu viel Spielraum zulässt.

Zu deinem Problem:
Wir machen beim Localboot ein "exit" aus dem Grub heraus um zum nächsten Booteintrag zu springen. Leider gibt es im Grub kein "localboot 0" oder ähnliches. Faher mussen wir uns so behelfen. Und dein HP springt wohl nicht zum nächsten Booteintrag sondern wo anders hin. Soviel zum schwammigen Standard.

Gruß
Mathias

Verfasst: **05 Nov 2021, 14:33**

Hi,
ginge als Workaround dass grub garnicht bootet, wenn keine MAC Pipefile hat? Also das Opsi bootmenu wenn keine MAC Pipefile an liegt benötigen wir nicht. Das würde auch den start verkürzen. Könnte man da irgendwie an setzen?

VG

Verfasst: **05 Nov 2021, 16:13**

Hi

nein leider nicht
der grub muss mit dem Menü starten, im hintergrund wird dann geschaut ob die pipe da ist, falls ja, lädt er die, falls nicht, wird das menü angezeigt.

Gruß
Mathias

Verfasst: **08 Nov 2021, 17:44**

Zwei wage Ideen:

Die Default-Datei `/tftpboot/grub/grub.cfg` um einen ersten neuen Eintrag ergänzen, der per Chainloading den Microsoft-Bootloader lädt. Soweit ich weiß, geht das aber nicht, wenn Secure-Boot und/oder Bitlocker aktiviert ist (EDIT: Bitlocker geht - eben getestet). Das müsste ungefähr so aussehen (ungetestet):

Code: Alles auswählen

...
source "$pipefile"

# NEU START
menuentry "Windows Vista/7/8/8.1/10/11 UEFI/GPT" {
    insmod part_gpt
    insmod search_fs_file
    insmod fat
    insmod chain
    search --no-floppy --file --set=root /EFI/Microsoft/Boot/bootmgfw.efi --hint-efi=hd0,gpt1
    chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi
}
# NEU ENDE

menuentry 'Local Disk' {
...

Oder kleiner wenn die Platte und Partition bekannt und immer gleich ist.

Code: Alles auswählen

menuentry "Windows Vista/7/8/8.1/10/11 UEFI/GPT (nosearch)" {
    set root='(hd0,gpt1)'
    chainloader /EFI/MICROSOFT/BOOT/bootmgfw.efi
}

Über Grub eine EFI-Shell laden (muss am besten lokal vorhanden sein) und dort (am besten per Script als Parameter) den BootNext auf den richtigen Eintrag setzen und Neustarten - als ungefähres Beispiel was ich meine:

Code: Alles auswählen

# Einträge auslesen - analog `efibootmgr`
#bcfg boot dump

# Einmalig per NextBoot die BootOrder überschreiben - analog `efimootmgr --bootnext XXX` (Nummer vorher raussuchen mit efibootmgr oder obigem Befehl)
setvar BootNext -nv -bs -rt =0200
reset

Schön ist beides nicht... Aber beim alten elilo hatten wir auch einmal das Problem mit einer Serie und haben das dort durch einen fehlerhaften Dummy-Eintrag behoben (was vielleicht auch noch eine Variante wäre?!)

Könnt ihr nicht irgendwie umgehen das Paket opsi-uefi-netboot bei dieser Serie ohne konfiguriertes Netboot auszurollen?

Verfasst: **09 Nov 2021, 13:12**

@mattias:
danke für die Rückmeldung. Der Workaround wäre, welcher wohl sofort funktionieren würde bei einem Neuinstall.
- opsi-uefi-netboot auf once + prepare auf setup
- wol wecken
- rechner installieren opsi-uefi-netboot -> dadurch wird das boot device wieder auf netboot first gesetzt
- rebooten der rechner, die sollten dann von Netzwerk booten
- im laufe des setup setzt dann windows sich wieder an erste Stelle vom efi bootloader

Muss man halt dran denken beim nächsten ausrollen, alles etwas unschön. Aktuell haben wir secureboot aktiv. ich werde deine Codevorschläge mal ausprobieren und berichten wie sich das mit secureboot verhält....

forum.opsi.org

Opsi grub boot Problem

Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem

Re: Opsi grub boot Problem