FOG Hangouts group

rogalskij

@Tom-Elliott Thank you so much Tom, as always I appreciate your support and guidance.

rogalskij

So, does that mean I should install the new one at the top? Or do I have the new one already by virtue of installing back in July? Sorry versioning gets confusing for me. Also what is FOS?

rogalskij

Our Fog instance updated to Kernel version 6.12.35 sometime over the summer. Since then new Kernel versions have been showing up under the Fog Configuration > Kernel Update menu per normal. The version number on these new versions however keep showing 6.12.35, the same that we already have. The first 6.12.35 shows July 15th as the date, but the newest 6.12.35 shows October 14th as the date.

Is this a bug only affecting us? Should we just update to the new version even though it shows the same number? Anyone else experiencing this? I just want to make sure I have the latest Kernel for new devices we purchase. Thanks everyone!

JJ Fullmer

@george1421 said in Broken iPXE boot loader:

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

This is the first post I found searching autoexec.ipxe so replying here for future searchers.

This was an addition in a recent ipxe version, and is meant to be a way to add ipxe based functionality without needing to recompile ipxe in order to edit an embedded script (https://github.com/ipxe/ipxe/discussions/1237#discussioncomment-9847219), I can’t find the post/doc again but I remember reading in one place that ipxe added it as part of the hopes of getting a signed ipxe shim so users could use the signed shim and then use this script to add what they can’t embed. While technically we can create a blank file in /tftpboot/ i.e. just

#!ipxe

which will remove the error during boot, this can then cause kernel panics when loading into FOS. Why it does this is a bit of a mystery at the moment, maybe it’s adding to or replacing another part of our pxe menu scripts that causes something in loading the kernels to lose access to ramdisk drivers. But adding it can break everything, so for the time being, just ignore the error.

soscrafts01

Hi,

i have in school one computer class without stored in bios windows pro key and i try to assign to host a windows 11 pro key but for the whole class when i deploy image more than half pc have some error about the isntalling windows was interrupted i think it might be problem with unattend file on image or that i wrote one windows key when i was creating the image but if it was a problem i think only one pc would imaged well but always few pc is imaged well the funniest thinks is i make image on this same device which is in class but in another class where we have another devices i did not have this problem i sometimes i had issues with to old or too new bios but this time all class have this same id of bios

Well where i need to look for problems? in unattend file or in that i put key of winmdows 11 pro to distribution image ?

rogalskij

@Clebboii A workaround that always worked for me that was recommended by Tom was to use the full DNS name rather than the IP address. I was initially logging into the UI through the IP, and found that very same issue. When he mentioned it and I started using the full DNS name, the issue went away.

JJ Fullmer

@gaptoothgonni Well darn, have you tried booting with snponly.efi instead of ipxe.efi? It wouldn’t make a ton of sense if that worked but something else to try.
If it’s booting to the wim though, it should just be getting the drivers from the wim unless ipxe somehow changes how they’re presented, which I don’t think it does but that’s also the only difference between where it’s working. Might be worth looking at https://github.com/ipxe/ipxe/discussions and seeing if anyone has had similar issues. Since you’re just using FOG to create the ipxe boot menu, it’s not likely anything within FOG that’s causing this. You could try ipxe’s pre-built boot files, though they won’t have the embedded fog stuff https://boot.ipxe.org/ but maybe will make a difference. There’s other ipxe efi files you can try too, or try an older one ( I think we still include some legacy ones in /tftpboot)

JJ Fullmer

@pilipp_edv That should be enough I imagine, thanks for being thorough. I’ll take a look at the kernel config when I get a chance.

JJ Fullmer

@pilipp_edv
Glad you got it figure out.
In case you aren’t aware, you can download that bzImage as a different name like bzImage-mmc and use that case sensitive name in the Host Kernel field on any host you have with the mmc and your other hosts can use the default latest.

Would you be willing to share more info on the make/model of these computers and or the make/model of the mmc controller and such? Although it could just be down to what driver versions are included by linux at the kernel level with different versions of the kernel, we can also check if there was a config change in what we include in the kernel between then and now that could have caused this.

JJ Fullmer

@chunter2 Ah, yes that would do it.
That just becomes the default value when creating new hosts.
If you set it via a group, it will update those values on all hosts in a given group, but it doesn’t do that dynamically/perpetually.

J	Joe Schmitt
S	soscrafts01
O	oelked
M	Mr_____T
B	broodbaron
R	rcalayan
H	hammerc807
D	dyacishyn
L	lukebarone
M	Melisa
Y	yushin
B	brechtvervaeke
A	abasto
E	emreonder
R	rogalskij
M	mkoliva15
C	carltoncortez
A	alvin.bayani
K	kguevarra
D	David Raymond

FOG Hangouts

Posts

Member List