Bug 13078

Summary: PXE install fails due to old filename structure in download URL
Product: IPFire Reporter: Adolf Belka <adolf.belka>
Component: ---Assignee: Adolf Belka <adolf.belka>
Status: CLOSED FIXED QA Contact:
Severity: Crash    
Priority: Will affect all users CC: michael.tremer, peter.mueller
Version: 2   
Hardware: x86_64   
OS: Unspecified   

Description Adolf Belka 2023-04-11 08:29:46 UTC 
The problem was flagged in the forum.

https://community.ipfire.org/t/kernel-panic-on-attempted-install/9589

I have confirmed this on my vm testbed.

Instead of looking for
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core173/ipfire-2.27-core173-x86_64.iso

the installer is trying, and failing, to download the file
https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core173/ipfire-2.27.x86_64-full-core173.iso
Comment 1 Adolf Belka 2023-04-11 08:33:55 UTC 
The Download URL is defined in the installer lfs file.

This problem has been present from CU170 as that is when the download filename format was changed.

Patch is being created to fix this.

I would like to also test this but I can not find how the ipxe.iso file is created.
I presume it is done via some separate script which is not in the build tree for IPFire2.x

Is it possible for me to create an ipxe.iso file from a completed build?
Comment 2 Michael Tremer 2023-04-11 09:49:58 UTC 
Hello Adolf,

I misread the bug ticket and thought it was assigned to me. So I submitted a patch to the list:

> https://lists.ipfire.org/pipermail/development/2023-April/015763.html

The whole thing is easier than thought because the URL is part of the installer. And so it has to be changed in lfs/installer and that is it. There is no need to rebuilt iPXE.
Comment 3 Adolf Belka 2023-04-11 10:26:35 UTC 
(In reply to Michael Tremer from comment #2)
> Hello Adolf,
> 
> I misread the bug ticket and thought it was assigned to me. So I submitted a
> patch to the list:

No problems.

> The whole thing is easier than thought because the URL is part of the
> installer. And so it has to be changed in lfs/installer and that is it.
> There is no need to rebuilt iPXE.

The change to lfs/installer I can see will update the installer but how does the ipxe process get hold of the installer.

The installer I thought was part of the iso to be downloaded but how does the ipxe.iso know where to download the installer from if the installer is part of the iso download.

I suspect my problem understanding this is that I am not at all familiar with how the whole PXE process works. I will have to have a read through it all.
Comment 4 Michael Tremer 2023-04-11 10:37:02 UTC 
(In reply to Adolf Belka from comment #3)
> The change to lfs/installer I can see will update the installer but how does
> the ipxe process get hold of the installer.

iPXE will download the menu from here:

> https://boot.ipfire.org/menu.cfg?arch=x86_64

This file has URLs for the kernel and the initrd which contains the user space including the installer.

> The installer I thought was part of the iso to be downloaded but how does
> the ipxe.iso know where to download the installer from if the installer is
> part of the iso download.

That would be a much nicer way actually: Download the entire ISO file to memory and then simply boot from it. But I suppose that will be super slow as the TCP stack in iPXE does not have many features that would allow fast downloads. So downloading only the minimum is probably more user friendly. Once the kernel is being loaded we have the Linux TCP stack which should download the ISO image very swiftly.

> I suspect my problem understanding this is that I am not at all familiar
> with how the whole PXE process works. I will have to have a read through it
> all.

Oh it is a little bit complicated because it pulls so many things from various places and I didn't really write any documentation. Most of the magic is in the web app actually:

> https://git.ipfire.org/?p=ipfire.org.git;a=tree;f=src/templates/netboot;h=29ccb5e82eb331632c4901e8c208df7cf0c9eaf9;hb=HEAD
> https://git.ipfire.org/?p=ipfire.org.git;a=blob;f=src/backend/netboot.py;h=7d378696e4148b10eff5a10a6bee688ff8e81dbb;hb=HEAD
> https://git.ipfire.org/?p=ipfire.org.git;a=blob;f=src/web/boot.py;h=61bc322eb8986242656c61191335f5214df73a51;hb=HEAD
Comment 5 Adolf Belka 2023-04-26 16:08:52 UTC 
I have seen that your patch has been merged into next and I was thinking about testing the pxe to confirm everything is okay now but I am not sure that will work.

I presume that the pxe iso will always look for the menu.cfg from the current Core Update. If that is correct then it can't be tested, even in Testing phase but has to wait for the Release phase.

Am I correct in my thinking or have I missed something in my understanding.
Comment 8 Adolf Belka 2023-05-20 14:24:22 UTC 
I am unable to test this fix currently.

If I choose Core Update 174 from the menu then that still has the old URL in the installer.

In the Development section of the pxe installer screen the most recent version is Core Update 87 RC

Core Update 175 Testing does not show up in it.

There is an entry labelled Nightly Build but selecting that gives a new screen with the entry Start installation! but pressing that gives no response.

This looks like it can only be tested when Core Update 175 becomes a Released version and is shown in the Stable releases list.

The Development releases list seems to be a bit pointless as they are exceptionally old. If the Testing builkds can't be included in the Development releases list then it might be better to remove the Development releases list from the menu.
Comment 9 Adolf Belka 2023-06-12 18:27:03 UTC 
The fix was able to be verified on CU175 Release version.