Arch Linux

odd, works fine here.

Seems related to the website https certificate.

for me it also works now

[Deleted Duplicate]

This bug still exists in the ipxe.efi UEFI executable available under the netbook section on the Arch Download page. I cloned the archlinux.ipxe from https://www.archlinux.org/releng/netboot/archlinux.ipxe to my personal https server and tried to chain load it from my webserver with https enabled and had the same issue. I had to disable https on my webserver, and use an http URL to this cloned archlinux.ipxe to be able to continue the boot process.

I suspect it is something to do with improper root ertificates embedded within the efi executable available in the downloads section.
One more thing to note, the archlinux.org website and my webserver both use certificates from let's encrypt.

I can also reproduce this when trying to boot up packet.net machines using our netboot image.

I rebuilt the netboot ipxe image with ocsp debugging enabled. I attached the output in a screenshot.

It's most definitely an issue with ocsp. For the people that's working, it shouldn't (this is most likely an issue with ocsp not responding to *your* request and the ipxe chainloader just going on with its day.
I re-baked the ipxe image using the aur makepkg and replaced the certificate with the new X3 certificate from Let's encrypt. I attached the patch over the AUR package if you want to rebuild yourself. Here's the verification run with both root certificates using openssl for reference:

Using the new cert

santiago at ~/.../ipxe/ipxe-netboot ✔ openssl ocsp -issuer le_dst_x3.pem -cert cert.pem -text -url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 04EB3A2F52E901717DF12D38A8797B0A7F36
Request Extensions:
OCSP Nonce:
04106FD124B52EED1D7C5D1A60FA02B2CFED
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Mar 2 12:48:00 2019 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 04EB3A2F52E901717DF12D38A8797B0A7F36
Cert Status: good
This Update: Mar 2 12:00:00 2019 GMT
Next Update: Mar 9 12:00:00 2019 GMT

Signature Algorithm: sha256WithRSAEncryption
46:68:79:56:5e:90:ac:85:15:4e:68:b1:55:81:38:e1:18:a8:
63:c3:4e:11:96:11:03:11:c3:e9:9f:60:cb:0b:9b:b3:46:8a:
63:37:dd:59:ad:bc:ed:8b:c4:28:4f:d7:51:a3:c9:3d:2b:34:
91:d8:c4:80:c1:4a:cc:d7:77:5c:e2:df:da:e5:6a:9a:cd:b7:
a1:86:93:3b:df:2d:44:c2:6c:e3:3c:a8:fb:3d:16:06:03:c2:
b4:09:c8:75:85:82:8f:8b:a7:13:76:5e:2e:12:83:9d:9e:ce:
a5:fa:c3:79:bf:c0:b1:2b:75:e4:1c:53:27:94:87:64:82:94:
9e:c8:86:b8:0e:ec:72:d2:c2:46:8a:96:be:ac:07:f5:d2:42:
fa:e6:a1:4b:6a:eb:bf:ef:b8:01:88:dd:57:80:4c:2f:f8:22:
2f:76:d2:d8:ae:9a:16:cf:b3:d6:f2:ef:13:d0:b3:61:d4:82:
d3:a5:80:e8:dd:40:6e:59:ec:d6:11:35:2c:a6:4d:bb:29:ca:
2f:d9:f6:ed:c8:30:ea:58:45:33:f9:a9:49:e1:24:6d:0f:fc:
a1:a2:62:13:d8:97:b7:62:62:fe:23:84:e3:e0:51:88:bf:26:
19:2b:73:5c:76:1c:2c:f4:ad:c3:0d:9d:28:d2:87:b3:fe:9b:
b2:50:3b:34
WARNING: no nonce in response
Response verify OK
cert.pem: good
This Update: Mar 2 12:00:00 2019 GMT
Next Update: Mar 9 12:00:00 2019 GMT


Using the old cert
santiago at ~/.../ipxe/ipxe-netboot ✔ openssl ocsp -issuer dst_x1.pem -cert cert.pem -text -url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: C4A7B1A47B2C71FADBE14B9075FFC41560858910
Serial Number: 04EB3A2F52E901717DF12D38A8797B0A7F36
Request Extensions:
OCSP Nonce:
0410FACC1991A87546C81C455EEC1F496559
Responder Error: unauthorized (6)

For reference, the kernel panic that other people may be running into is due to having too little memory on the machine (-m 1G should be around 1.5+ G instead)

The pxe image has been updated, so this issue should be fixed.

Hi,

I'm having this issue with the current UEFI executable (ipxe.d63edd60ae06.efi) from https://www.archlinux.org/releng/netboot/ .

I am not able to boot via latest UEFI netboot image. It gives following error

https://www.archlinux.org/releng/netboot/archlinux.ipxe ... operation not permitted ... (http://ipxe.org/err/410de13c)

I am using UEFI shell but same bug is reported for BIOS neboot too.

https://bbs.archlinux.org/viewtopic.php?id=249217

PS: I am trying in Virtualbox but that should probably not be an issue.

Sangy figured out what the issue is, this will require infrastructure changes on our side.

I couldn't figure out how to "subscribe" to this issue, so here's a screenshot.