boot command hangs

[obie]

I'm on the latest master of ipxe and am able to get a script running pulling from a public version of Centos. Here's what runs successfully for me:

Code:

#!ipxe

  # Running this example on machine from USB to prove that boot from iPXE USB image works
  echo Starting Script
  dhcp
  echo After dhcp
  set base http://mirror.centos.org/centos/7/os/x86_64

  prompt -k 0x197e -t 2000 Press F12 to install CentOS... || exit
  kernel ${base}/images/pxeboot/vmlinuz initrd=initrd.img repo=${base}
  initrd ${base}/images/pxeboot/initrd.img
  boot

This works great but now I want to iterate on pulling from a https url. I changed the url and enabled HTTPS by adding the #define for DOWNLOAD_PROTO_HTTPS in config/general.h.

This is the script as it looks now:

Code:

#!ipxe
  
  echo Booting OS v66
  dhcp
  initrd https://<MY_URL>/initrd.img
  kernel https://<MY_URL>/vmlinuz initrd=initrd.img
  echo Sleeping after kernel and initrd ...
  sleep 60
  echo Booting now ...
  boot

When I run this script, I can see HTTPS in the enabled protocols so I believe I did that right. And on the kernel, initrd calls I get URL ... ok so I believe I'm pulling those down correctly. Unfortunately, the script hangs on boot after printing 'Booting now...'. I tried swapping the order of the initrd and kernel calls as well as adding a sleep as recommended in an another thread but I'm still seeing the same hanging. I'm running this from a usb image using bin/ipxe.usb EMBED=my_file.

Any ideas as to what may be going on? Any debug flags I can set? I'm on the latest ipxe but if there's any other information I can provide, I'd be very happy to.

I'm new to ipxe so there may be something I fundamentally am misunderstanding.

[NiKiZe]

the most likely scenario i think is that for some reason the kernel is corrupted.
I would start with imgstat to check filesize and imagetype - compare between working and non working.

Also double check in a browser that https with that url works correctly

[obie]

So I double checked the urls for pulling down the vmlinuz and initrd.img and they are fine.

Listed here (public urls):
https://storage.cloud.google.com/public-...-1/vmlinuz
https://storage.cloud.google.com/public-...initrd.img

They are the same CentOS images as the working script just downloaded and hosted somewhere else (gcloud).
When I download them manually, they are 6 MB and 50 MB respectively just like the centos.org files so I think they are exactly the same.


However, imgstat returns something interesting.

In the working script:
vmlinuz: 6639904 bytes [bzImage] [SELECTED] ...
initrd.img : 52584760 bytes ...

Just as expected.

But in the non-working script:

initrd.img: 74115 bytes [PXE-NBP]
vmlinuz: 74093 bytes [PXE-NBP] [SELECTED]

These sizes (70kb) are way off and very similar so maybe an error response. The data type also seems not be bzImage and instead PXE-NBP. So far, looks like it is not able to download these correctly. Given that I can download those files from the given urls manually and they are at the expected size it seems to be an error in how I'm pulling the kernel and initrd down. Anything special I can do to debug this step? HTTPS is an enabled protocol (in the features list when iPXE starts) but it could be some issue with that.

[NiKiZe]

if https was not enabled you would get "protocol not supported" so that is not the issue.

You will need to figure out what is going on.
use your non https version...

then extend it with initrd https: files, but end them with an additional filename.

initrd https://<MY_URL>/initrd.img httpsinitrd
initrd https://<MY_URL>/vmlinuz httpsvmlinuz

this should add the downloaded data to separate cpio archives - which should be available from within your started linux distro - and hopefully could be used to identify what is going on.

Another thing that you could do is to recreate the iPXE user-agent and headers with curl or similar, and see if that makes a difference.
Also hosting the files on the same service, but without https, might be helpful for debuging using tcpdump or similar.