@joyboy11111 ok so it was dhcpd not dhcp

So from your top picture you have 4 network adapters but only one is configured. That is OK I just wanted to make sure you didn’t have 2 interfaces active at one time.

Before you do this net bit, restart the dhcp server with systemct restart dhcpd and then confirm if its running with the ps and netstat commands. If its not running again look at the log file.

If the above fails or its complaining about an interface to bind to then do the following.

If you look at the dhcpd file, in there should be a line like

DHCPDARGS="";

Change it to bind to the dhcp server to only eth0

DHCPDARGS="eth0";

@joyboy11111 OK the no subnet error is a bit strange but move that into the subnet 192.168.1.0 section. That is what its complaining about. It should be global at that level, but whatever.

Now did you fiddle with the configuration in /etc/sysconfig/dhcp? If not I need to see the output of these two commands

ip a s
cat /etc/sysconfig/dhcp

@joyboy11111 Well I would look at the /var/log directory either messages or syslog in there to see what the dhcp server is compaining about.

tail -30 /var/log/messages
or
tail -30 /var/log/syslog

@joyboy11111 Lets start with this.

Connect to the fog server using putty or ssh

mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.sav
vi /etc/dhcp/dhcpd.conf
i (to insert)

Copy the following code out of your browser and the paste into the vi editor

option space PXE;
option PXE.mtftp-ip    code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 192.168.1.41;
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 192.168.1.50 192.168.1.75;
    default-lease-time 21600;
    max-lease-time 43200;
    option domain-name-servers 192.168.1.4;
    option routers 192.168.1.254;
 
    class "UEFI-32-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
    filename "i386-efi/ipxe.efi";
    }

    class "UEFI-32-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
     filename "i386-efi/ipxe.efi";
    }

    class "UEFI-64-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
     filename "snponly.efi";
    }

    class "UEFI-64-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
    filename "snponly.efi";
    }

    class "UEFI-64-3" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
     filename "snponly.efi";
    }

    class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
    }

}

Write and then Exit vi

systemctl restart dhcp
ps aux | grep dhcp

The ps command should show there is the dhcp service running. You can also test with

netstat -an | grep :67  

That should return with something like

tcp4     0.0.0.0:67

@joyboy11111 So the file may have been open with vi or nano when the computer was rebooted or you have the file open in another session on the server. If the swap file was created previously before a reboot you can delete the file. In the same directory as that file there should be a .swp file. You can remove that file so you won’t get that nuances message.

@joyboy11111 Did someone hand edit that file? I find it strange that it doesn’t match the fog supplied configuration file.

You can remove that static filename stanza line and insert the class definitions from the wiki page. Then reboot the dhcp server.

The ways its currently configured that dhcp service will only support booting bios based computers via PXE.

@lakk I have had to work (deal) with them from time to time. I can tell you I did the exact same thing with them (breaking the mirror) by (assuming) the intel raid controller acts like a traditional raid controller. I can tell you it does not, because it exposes both the raid device and the JBOD disks to the OS. The OS needs to be smart enough to know how to manage the array.

I did write a tutorial on how to use FOG with these type of raid adapters here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid (oh my all the way back in 2016…)

I can tell you another example (possibly of what you are seeing). We have several dell precision rack mount workstations that use these raid controllers for their local disks. Somewhere in 2018-2019 they upgraded the OS from Windows 7 to Windows 10. About 6 months later we got a call that 2 of the workstations had reverted back to windows 7. This wasn’t possible because it was a clean install of windows 10 and not an upgrade from Windows 7. Its just not possible to do what they said it did. We had them reboot the workstation and take a few screen shots. They called back and said that it switched back to windows 10. Thinking they were just crazy we said the next time it happened give us a call. About a month later it did it again. To no make this any longer of an example I’ll cut to the point. We found that the raid-1 mirror was split (akin to split brain) some time before windows 10 was installed. So not knowing the mirror was broken they installed windows 10 and it went onto one disk while the other disk remained at windows 7 install. It appears that the intel raid controller picks at random which disk will be the leader and the other the follower in the mirror (for the intel controller the leader disk has read/write activity, while the follower only has write activity). That is how on one boot it would start up as win10 and the another boot win7.

@rubensurtfe-0 As soon as the boot files are sent to the target computer, the FOG server is no longer involved with the target computer. SO this error is with what ever OS is running.

@huecuva said in Hanging on ipxe initalizing devices.:

Would I still be able to deploy the image by creating a task in the FOG webgui?

yes that is required. That is covered in the tips I just chatted to you.

@huecuva said in Hanging on ipxe initalizing devices.:

@george1421 How do I boot USB? And what capabilities of FOG would I not have access to?

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Multicasting and some tight integration with fog like “deploy image” menu in ipxe.

Also look at the fog forum chat bubble for a few more hints.

@huecuva Well its unfortunate that it doesn’t fully initialize on that target hardware. I have seen it in the past do that and a firmware update usually fixes it. Since iPXE is out of the picture we do have a method to USB boot into imaging if you need to go that route. You will not have some of the capabilities of FOG but you will be able to image computers.

@huecuva So just for clarity is it freezing starting iPXE or FOS Linux?

Is the MSI mobo in uefi or bios mode?

@huecuva said in Hanging on ipxe initalizing devices.:

After a little more research, I’ve been able to determine one possibility. Could it maybe be a host boot kernel issue? I’m apparently running kernel 4.19.0-11, but that kernel isn’t even listed when I go into Kernel Update in FOG. Would it be worth upgrading the kernel? I don’t want to make it stop booting my gaming rig.

This is a bit deceiving here (not your post but how FOG boots). The iPXE menu is driven by the ipxe boot loader (undionly.kpxe or ipxe.efi). Once you make a menu selection then FOS Linux (a.k.a the kernel) / bzImage init.xz is transferred to the target computer and FOS Linux boots. This is the engine that clones disk images.

So if your system is hanging before the iPXE menu then its a iPXE issues, if it hags after a menu selection then it is probably FOS Linux.

The version of “the kernel” is not related to the kernel version on the host computer that FOG is installed on. It refers to the version of the kernel that powers FOS Linux. I can tell you that you will want to upgrade to 5.6.18 of the fos linux kernel if you want to support 2020 or later hardware. You can do that through the webui FOG Configuration -> Kernel section.

@huecuva said in Hanging on ipxe initalizing devices.:

my HTPC (i5 3470) it hangs on initializing devices

Just so I understand correctly, ipxe is transferred to the HTPC and it starts to boot because you see the iPXE banner, but then you see initializing devices and it stops booting. This is because of a compatibility issue between iPXE and the firmware on the target computer. The first step would be to ensure you had the latest firmware on the HTPC.

@rubensurtfe-0 It looks like you are booting in virtual box? If so how much ram do you give to this VM?

Also did you see during booting that the squashfs was transferred to the target computer. When I tested this configuration there was surely 2 booting sequences, one to boot into the os to copy over the squashfs and the second when the OS in the squashfs starts booting. Where did it freeze for you?

@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

@rubensurtfe-0 It works once we have the right ISO image and correct web server path.

@lakk What is your raid controller? The built in intel raid? If so that setup is to put it polity a hardware assisted software raid. Its possible to use FOG to clone these disk structures but you need to know ahead of time that you are using these hybrid raid configurations. This intel raid presents these disks as normal disks to the operating system so you can easily break the raid if you were to just change one of the disks. You need to startup the software raid manager and talk to the logical raid disk. Its a bit confusing to explain but your source disk is now damaged.

If you remove the disk0 (/dev/sda) from the computer you may be able to boot the computer using disk1 (/dev/sdb) since FOG wasn’t told about the array it probably only interacted with disk0 (/dev/sda). Your computer should boot but in a degraded state since disk0 is out of sync with disk1.

@rubensurtfe-0 As I mentioned in the other thread. The http server for FOG is configured in such a way that it doesn’t allow downloads of any files outside of the /fog directory. There is an adjustment that can be made.

@george1421 This post works, but it does not: https://forums.fogproject.org/post/140524

The menu structure and files are right. Where it falls down is it can’t locate the initramfs via http. I know the problem it is in the rewriting rules FOG adds to the apache server. It won’t let you download any files other than in the /fog directory on the server. I can fix this but its too late tonight and I’m out of brain juice. As soon as I can correct for the redirect the solution will work as intended.