@abulhol Should be back up and running.

Thanks for letting us know.

@nik That appears to be a vmware workstation interface, but TBH I’ve never seen that interface before at least on windows.

The error is a bit strange too. The vmnetX devices are basically like vSwitches are to vSphere ESXi. To reach outside of that vmnetX vSwitch that vmnetX needs to be connected to a physical network adapter. If your fog server doesn’t need to reach outside of the VM Host server then you don’t need to bridge to a physical adapter. If you want two on vm host vms to communicate all you need to do is to connect the VMs to the same vmnetX device.

@jcyrus_rti You are welcome!

Sorry if my answer sounded harsh. Didn’t mean to.

So much for me. I didn’t see that the computer was in raid mode and not in AHCI.
The subject is irrelevant.
Sorry for the inconvenience

Solved topic

@george1421 it is a racktop production filesystem,
the server “heads” are from racktop
I don’t know what filesystem is under that.

The senior sysadmin is looking into creating the share on that system.

I will let you know once I can continue working on this.

Thank again

@sebastian-roth to fix-it, i have changed owner, changrp and chmod.
Thanks for you help 🙂

@george1421
Merci cela à fonctionner avec bzImage553 👍
Bonne continuation
JCH

@mstabrin Ok that is the answer I just came up with. For every foreign subnet you will need to add in a new dhcp-range value.

Well done finding the solution. I also learned something new today too about adding multiple ranges.

@amirbfc said in Lenovo M75s-1 boot on uefi:

“Could not select: Exec format error (http://ipxe.org/2e008081)”

Is secure boot disabled in the UEFI settings?

@dominique said in Database engine MyISAM - upgrade FOG?:

Any idea when 1.6.0 will be general available?

There is no timeline for this yet. Many people use FOG but very few help working on it. So things are going very slow at the moment. We’ll bring out a last 1.5.x release (1.5.10) to finish up that line and then the next will be a first 1.6 release (months down the road).

If you are keen to get InnoDB earlier you can follow the topic Goerge posted. From my point of view this should be possible in 1.5.x setups as well. But we won’t officially support this and don’t want to push out for a major change in the 1.5.x branch anymore.

@huecuva said in Fog on Proxmox ?:

I’m just having issues booting my HTPC from ipxe for some reason I can’t figure out.

Please start a new thread so we can discuss

@alesser Not really unfortunately.

The token you see on the screen is stored in the fogserver in a different mechanism. What you see is an encrypted string compared to what is actually stored in the FOG Server.

If you have the original “plain text” value, it should work (even if you don’t see the same key) as it’s still referencing the same “plain text” value.

@victor-r Interesting… there must be some other code that is doing that. Rerun the fog installer to put things back.

Just to be sure I’m looking in the right area, you are trying to replicate your images from the FOG server to the windows storage node or are you trying to capture directly to a windows storage node?

@sebastian-roth not really, there are a few references to the same problem, and only one person said they were successful by taking the undionly.kpxe file from a debian 10.4 installation.

I will complete this image on a physical machine, it not a big issue. It is just super convenient when working remotely that’s all.

Thanks for taking to time to reply.

Zufar

@bluedude For a longer term solution I would implement the dhcp policies from the document Sebastian provided. That solution will help you when you have a mix of bios and uefi systems on your campus.

BUT for a test right now, replace undionly.kpxe with snponly.efi then try to pxe boot that troubled target computer. Understand when you move away from the bios boot loader the bios systems will fail to pxe boot. But what we are looking at right now is/does snponly.efi resolve uefi booting on this troubled computer. Once you find out then put back the undionly.kpxe file until you can get the dhcp policies setup. I can tell you they do work because I have them setup in my environment.

@vemoya All I can say you get what you’re paying for.

Create a new iPXE menu that looks similar to this.

Menu Item: os.chainwdsimaging
Description: Boot WDS Imaging Solution
Parameters:
cpuid --ext 29 && set warch x64 || set warch wx86
iseq ${platform} pcbios && set bootfname wdsnbp.com ||
iseq ${platform} efi && set bootfname wdsmgfw.efi ||
chain -ar tftp://10.254.0.155\\boot\\${warch}\\${bootfname}
boot || goto MENU
Menu Show with: All Hosts

The script parameters looks a bit complicated but it basically checks to see if the target is x86 or x64 and uefi or bios to pick the right location and file name to boot.

Understand that for pxe booting there is two methods and it appears you are using both in your setup.

There is the static mode where you define dhcp options 66 and 67 listing statically the boot server and file name to use. In your case your dhcp server looks like you have policies defined to switch between uefi and bios boot files this is good.

The second method you are using is called proxy dhcp this is where you add your pxe boot server (WDS or FOG running dnsmasq) to the last host in your dhcp-helper service on your router. Both WDS and FOG running dnsmasq will respond with the proper boot file when it hears a dhcp discover from the target computer (this is why you have it listed in the dhcp helper service). The proxydhcp server (WDS or dnsmasq) will only provide the pxe boot information leaving your main dhcp server to provide the rest of the boot information. If you have a proxydhcp server configured its settings will override the static settings you have defined in dhcp options 66 and 67.

The reason why I’m telling you this, if you don’t stop the proxydhcp service on WDS it could respond to proxy boot requests giving you a random boot experience. Its ok to have static and dynamic assigned boot files, just know that proxydhcp will override static settings, when you can’t figure out why things are working as intended.

Be aware I did not test the script above only wrote it on the fly without much thought. YMMV

@george1421

That appears to have resolved it! Thanks!

@george1421 Hello, tsc=unstable worked! Thanks. Since some of the computers don’t belong to our campus, and just come here to be reimaged, I tried to apply that parameter in the settings in all clients and it didn’t give us compatibility issues with more modern systems (I tested for example in HP Elite 8200’s and it worked perfectly).

Thank you for your assistance! 🙂

@Vango The upper picture shows the new FOG version 1.6 we keep working on since a long time, mostly it’s @Tom-Elliott’s great work.

The version is confusing as the work in this branched off at around FOG 1.5.7 and has not been updated to 1.6.x for some time as it was still a very early alpha version not quite ready for production. It’s great to hear you have been using it for a year now already! We are still working on it and hope to release an official 1.6.x in the next months.

You can get the current stage of it as we work on it by checking out the branch working-1.6.

Let us know if there is anything that needs fixing.

@brakcounty While I can imagine an upgrade to break things in rare cases I would not think this would happen for a service like ISC-DHCP which has been around for so many years. But hey, you never know. Everything is possible.