Bug#928750: [grub-efi-amd64] On EFI pxeboot grubx64.efi only loads config when loaded directly

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#928750: [grub-efi-amd64] On EFI pxeboot grubx64.efi only loads config when loaded directly

Michael Kesper-5
Package: grub-efi-amd64
Version: 2.02+dfsg1-16
Severity: important

--- Please enter the report below this line. ---

https://d-i.debian.org/manual/en.amd64/ch04s05.html mentions that you need to
configure
  filename "debian-installer/amd64/bootnetx64.efi";
as bootfile for booting via PXE in dhcp configs.

When doing so, grubx64.efi will be loaded in the next step, but will not try
to load its config files and - after 30s wait time showing the attached screen on console
present the Grub shell.
(As mentioned in https://lists.debian.org/debian-boot/2019/05/msg00076.html)

Excerpt from logs:

May  8 16:02:07 ssfnctl111 dhcpd: DHCPREQUEST for 10.45.10.32 (10.45.10.5) from 0c:c4:xxx via eth0
May  8 16:02:07 ssfnctl111 dhcpd: DHCPACK on 10.45.10.32 to 0c:c4:xxx via eth0
May  8 16:02:07 ssfnctl111 in.tftpd[21355]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/bootnetx64.efi
May  8 16:02:07 ssfnctl111 in.tftpd[21355]: tftp: client does not accept options
May  8 16:02:08 ssfnctl111 in.tftpd[21356]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/bootnetx64.efi
May  8 16:02:08 ssfnctl111 in.tftpd[21357]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/grubx64.efi
(Nothing re tftp afterwards)

If you change the boot option in dhcp. conf to
  filename "debian-installer/amd64/grubx64.efi";
it changes to:

May 10 10:51:20 ssfnctl111 in.tftpd[16770]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/grubx64.efi
May 10 10:51:20 ssfnctl111 in.tftpd[16770]: tftp: client does not accept options
May 10 10:51:21 ssfnctl111 in.tftpd[16771]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/grubx64.efi
May 10 10:51:21 ssfnctl111 in.tftpd[16773]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/command.lst
May 10 10:51:21 ssfnctl111 in.tftpd[16773]: sending NAK (1, File not found) to ::ffff:10.45.10.32
May 10 10:51:21 ssfnctl111 in.tftpd[16774]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/fs.lst
May 10 10:51:21 ssfnctl111 in.tftpd[16774]: sending NAK (1, File not found) to ::ffff:10.45.10.32
May 10 10:51:21 ssfnctl111 in.tftpd[16775]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/crypto.lst
May 10 10:51:21 ssfnctl111 in.tftpd[16775]: sending NAK (1, File not found) to ::ffff:10.45.10.32
May 10 10:51:21 ssfnctl111 in.tftpd[16776]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/terminal.lst
May 10 10:51:21 ssfnctl111 in.tftpd[16776]: sending NAK (1, File not found) to ::ffff:10.45.10.32
May 10 10:51:21 ssfnctl111 in.tftpd[16777]: RRQ from ::ffff:10.45.10.32 filename /grub/grub.cfg
May 10 10:51:21 ssfnctl111 in.tftpd[16777]: sending NAK (1, File not found) to ::ffff:10.45.10.32

After adding a symlink in /var/lib/tftpboot/ grub -> debian-10/debian-installer/amd64/grub
(additional to debian-installer -> debian-10/debian-installer), Grub will load and we can chose a menu
to start our preseeded install:

May 10 10:53:55 ssfnctl111 in.tftpd[18546]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/grubx64.efi
May 10 10:53:55 ssfnctl111 in.tftpd[18546]: tftp: client does not accept options
May 10 10:53:55 ssfnctl111 in.tftpd[18547]: RRQ from ::ffff:10.45.10.32 filename debian-installer/amd64/grubx64.efi
May 10 10:53:56 ssfnctl111 in.tftpd[18548]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/command.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18549]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/fs.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18550]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/fs.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18551]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/fs.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18552]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/fs.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18553]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/crypto.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18554]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/crypto.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18555]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/crypto.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18556]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/terminal.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18557]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/terminal.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18558]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/terminal.lst
May 10 10:53:56 ssfnctl111 in.tftpd[18559]: RRQ from ::ffff:10.45.10.32 filename /grub/grub.cfg
May 10 10:53:56 ssfnctl111 in.tftpd[18560]: RRQ from ::ffff:10.45.10.32 filename /grub/grub.cfg
May 10 10:53:56 ssfnctl111 in.tftpd[18561]: RRQ from ::ffff:10.45.10.32 filename /grub/grub.cfg
May 10 10:53:56 ssfnctl111 in.tftpd[18562]: RRQ from ::ffff:10.45.10.32 filename /grub/font.pf2
May 10 10:53:56 ssfnctl111 in.tftpd[18563]: RRQ from ::ffff:10.45.10.32 filename /isolinux/splash.png
May 10 10:53:56 ssfnctl111 in.tftpd[18563]: sending NAK (1, File not found) to ::ffff:10.45.10.32
May 10 10:53:56 ssfnctl111 in.tftpd[18564]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/play.mod
May 10 10:53:56 ssfnctl111 in.tftpd[18565]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/play.mod
May 10 10:53:56 ssfnctl111 in.tftpd[18566]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/play.mod
May 10 10:53:56 ssfnctl111 in.tftpd[18567]: RRQ from ::ffff:10.45.10.32 filename /grub/x86_64-efi/play.mod


--- System information. ---
Architecture:
Kernel:       Linux 4.19.0-4-amd64

Debian Release: buster/sid
  990 testing         security.debian.org
  990 testing         ftp2.de.debian.org
  990 buster          download.docker.com

--- Package information. ---
Depends                        (Version) | Installed
========================================-+-==================
debconf                        (>= 0.5)  | 1.5.71
 OR debconf-2.0                          |
grub-common            (= 2.02+dfsg1-16) | 2.02+dfsg1-16
grub2-common           (= 2.02+dfsg1-16) | 2.02+dfsg1-16
grub-efi-amd64-bin     (= 2.02+dfsg1-16) | 2.02+dfsg1-16
ucf                                      | 3.0038+nmu1


Package's Recommends field is empty.

Package's Suggests field is empty.



Screenshot_20190509_113044.png (14K) Download Attachment
signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#928750: Acknowledgement ([grub-efi-amd64] On EFI pxeboot grubx64.efi only loads config when loaded directly)

Michael Kesper-5
Additional info: Secure Boot is turned OFF on that system.

Michael


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Steve McIntyre
In reply to this post by Michael Kesper-5
Hi Michael!

On Mon, May 13, 2019 at 10:34:46AM +0200, Michael Kesper wrote:

>
>Is it possible that the erroneous behaviour of grubx64.efi (not loading its config
>files when being loaded by bootnetx64.efi aka shim-signed) gets triggered by
>how the shim calls grubx64?
>With Debian 9, the same setup (boot the installer via UEFI PXE) worked.
>
>References:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928750
>  https://lists.debian.org/debian-boot/2019/05/msg00076.html
>  https://lists.debian.org/debian-boot/2019/05/msg00084.html

Ah. Apologies, you've clearly found a bug in our setup. :-(

It looks like what you're seeing is that the signed grub image is
using a different $prefix setting, and now it needs help to find the
grub.cfg file.

The debian-installer build used to rebuild its own grub EFI image and
change some config during that build (using -p
"$netboot_prefix/grub"), but now we can't do that (as it would lose
the signature). We need to update our netboot tree and the
documentation to reflect this.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Because heaters aren't purple!" -- Catherine Pitt

Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Michael Kesper-5
Dear Steve,

On 13.05.19 18:49, Steve McIntyre wrote:

> Ah. Apologies, you've clearly found a bug in our setup. :-(
>
> It looks like what you're seeing is that the signed grub image is
> using a different $prefix setting, and now it needs help to find the
> grub.cfg file.
>
> The debian-installer build used to rebuild its own grub EFI image and
> change some config during that build (using -p
> "$netboot_prefix/grub"), but now we can't do that (as it would lose
> the signature). We need to update our netboot tree and the
> documentation to reflect this.
Should this bug be assigned to shim-signed, then?
With documentation I guess you meant
https://d-i.debian.org/manual/en.amd64/ch04s05.html

I'd prefer the section 4.5.1.1 to be split into a section 4.5.1.2
"PXE boot by UEFI" to emphasize the differences.
Should there then
filename "debian-installer/amd64/bootnetx64.efi";
be replaced by
filename "debian-installer/amd64/grubx64.efi";
?

Thanks a lot
Michael
 



signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Michael Kesper-5
In reply to this post by Steve McIntyre
Hi Steve, hi all,

On 13.05.19 18:49, Steve McIntyre wrote:

> On Mon, May 13, 2019 at 10:34:46AM +0200, Michael Kesper wrote:
>>
>> Is it possible that the erroneous behaviour of grubx64.efi (not loading its config
>> files when being loaded by bootnetx64.efi aka shim-signed) gets triggered by
>> how the shim calls grubx64?
>> With Debian 9, the same setup (boot the installer via UEFI PXE) worked.
>>
>> References:
>>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928750
>>  https://lists.debian.org/debian-boot/2019/05/msg00076.html
>>  https://lists.debian.org/debian-boot/2019/05/msg00084.html
>
> Ah. Apologies, you've clearly found a bug in our setup. :-(
>
> It looks like what you're seeing is that the signed grub image is
> using a different $prefix setting, and now it needs help to find the
> grub.cfg file.
>
> The debian-installer build used to rebuild its own grub EFI image and
> change some config during that build (using -p
> "$netboot_prefix/grub"), but now we can't do that (as it would lose
> the signature). We need to update our netboot tree and the
> documentation to reflect this.
It seems this is still neither fixed nor mentioned on
https://www.debian.org/devel/debian-installer/errata

Last version tested: 2019-06-05

Bye
Michael


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Steve McIntyre
Hi Michael,

On Wed, Jun 05, 2019 at 12:18:53PM +0200, Michael Kesper wrote:

>On 13.05.19 18:49, Steve McIntyre wrote:
>>
>> The debian-installer build used to rebuild its own grub EFI image and
>> change some config during that build (using -p
>> "$netboot_prefix/grub"), but now we can't do that (as it would lose
>> the signature). We need to update our netboot tree and the
>> documentation to reflect this.
>
>It seems this is still neither fixed nor mentioned on
>https://www.debian.org/devel/debian-installer/errata
>
>Last version tested: 2019-06-05

Apologies, this is on my list still but no progress yet. :-(

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Steve McIntyre
On Wed, Jun 05, 2019 at 04:47:27PM +0100, Steve McIntyre wrote:

>Hi Michael,
>
>On Wed, Jun 05, 2019 at 12:18:53PM +0200, Michael Kesper wrote:
>>On 13.05.19 18:49, Steve McIntyre wrote:
>>>
>>> The debian-installer build used to rebuild its own grub EFI image and
>>> change some config during that build (using -p
>>> "$netboot_prefix/grub"), but now we can't do that (as it would lose
>>> the signature). We need to update our netboot tree and the
>>> documentation to reflect this.
>>
>>It seems this is still neither fixed nor mentioned on
>>https://www.debian.org/devel/debian-installer/errata
>>
>>Last version tested: 2019-06-05
>
>Apologies, this is on my list still but no progress yet. :-(

In fact, I'm looking at a different fix: using a specific build of the
Grub netboot image with the d-i prefix configured. Watch this space!

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Bug#928750: - Bug in grubx64.efi triggered by shim?

Michael Kesper-5
Hi Steve,

On 10.06.19 18:57, Steve McIntyre wrote:
> In fact, I'm looking at a different fix: using a specific build of the
> Grub netboot image with the d-i prefix configured. Watch this space!

Thanks for investigating and keeping me informed! :)

Bye
Michael


signature.asc (673 bytes) Download Attachment