Can we get a bit more details on the target computer?
Who made it and what model number?
Is this in uefi or bois (legacy mode)?
From the FOG iPXE menu did you see if the hardware was compatible with FOG? Did both network and disk pass?
Can we get a bit more details on the target computer?
Who made it and what model number?
Is this in uefi or bois (legacy mode)?
From the FOG iPXE menu did you see if the hardware was compatible with FOG? Did both network and disk pass?
@geardog I’ve seen this similar error when in uefi mode and the disk controller is set to raid-on mode.
Can you schedule another capture or deployment to this target computer, but before you submit the job, tick the debug check box then pxe boot the target computer. After a few enter key-presses on the target computer you will be dropped to a linux command prompt. At the command prompt please key in the following command.
lsblk
and post the results here.
with centos 7 booted, can you post the output of this command
lsblk
? I’m suspecting that LVM is your disk format.
Also it would be helpful to know what version of FOG you are using.
@irfan4701 I’m going to suspect that with the ubuntu systems its using standard disk partitions. I know that at one time FOG couldn’t resize LVM disks so non-resizable was the only option. I thought the developers were working on that option, but maybe LVM resizing was on the roadmap and not actively being worked on.
@kagashe Reading between the lines here, If you have a storage node at each remote location, then that becomes your pxe boot server at the remote location. The location plugin, when configured, will direct the clients assigned to that storage node to image from that storage node.
Here is my POC tutorial to setup a synology nas as a FOG storage node: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node
You need to watch directory permission on the synology NAS as well as nfs share permissions.
This appears to be an interesting issue. I might suspect that either the target computer either doesn’t have an IP network or something else is going on here.
Is 149.166.139.13 the IP address of your fog server?
If so then on your fog server key in the following command:
showmount -e 127.0.0.1
I see that you are using the https protocol? The ip address [149.166.139.13] points to in-info-fog.soic.iupui.edu?
Is the target (pxe booting host) on the same subnet (vlan) as the fog server?
I just saw something, you are booting this target computer with a FOS USB drive [boottype=usb]?
@kagashe Lets get some terms clear. FOG has two install modes. One is the normal FOG install. This creates a master node. The other install mode is a storage node. In a typically FOG configuration you will always have at least a (normal) FOG server install. This shall be your master node. You can have as many storage nodes as your organization needs. (hang in there I’m almost to the point of your question) You would typically place the master node at your HQ and storage nodes at remote sites.
At your HQ you would set dhcp options 66 and 67 to point to the master node. At each remote site you set your dhcp options 66 and 67 to point to your local storage node. That way you are not pulling any boot files over your site to site WAN connections.
@hammett131 ok I see why it doesn’t boot.
The device is saying its a uefi system (EF-BC type 7) but 10.0.2.1 is sending undionly.kpxe as the boot file name. The target computer promptly downloads the file and chokes on it. Its saying the next server is 10.0.2.122, which is your fog server?
@hammett131 If you can’t get your sonicwall to cooperate you can install dnsmasq on the FOG server to dynamically supply the boot information while you still use the sonicwall for dhcp services. There are a number of ways to get things working in your environment.
@ldiorio Interesting the scan delay setting was added intentionally to give the uefi firmware a chance to fully boot up before attempting to exit via refind. We may need to reconsider switching that back if it continues to cause an issue. It was turned on by default to solve a problem, but then it appears to have caused another.
Thank you for all of your fine detective work on this. Without the actual hardware in our hands, it hard to debug issues like this.
@chris-whiteley Why not just put a fog storage node on the other side of the link. Then you wouldn’t run the risk of over committing your WAN. You can define a specific replication bandwidth. That IS something that fog can manage. You could even use an older dual core desktop computer as a FOG storage node. FOG Servers don’t need a lot of resources.
Are you using fog’s linux service account called fog
perchance? That linux user is managed and owned by the FOG application. If you change/reset this account you will have imaging issues.
@hammett131 said in UEFI Initializing devices.:
HP 4300
Is it just with the above model?
Just for confirmation we are talking about this model? https://support.hp.com/us-en/document/c03403843
Have you ensured you have the latest firmware installed on this device?
How many of these devices do you have on your campus?
What version of FOG are you running?
Where its getting hung up is booting the iPXE kernel, its hanging up on initializing the hardware. We have seen this with some crappy uefi firmware implementations. Usually a firmware update fixes the issue.
@arainero In the post where you stated “With REFIND_EFI set it gets stuck on the following:”, That picture is of a bios (legacy) boot not uefi. I can understand why refind may not like that if you don’t have legacy mode enabled in refind.
Also what hardware are we dealing with here, both manufacturer and model?
@greg-plamondon Hint: When you get the http 500 errors, inspect your apache error log file so see if apache or php threw an error.
Just for clarity here (because I’m a little confused on what you are asking). The .EXE’s you deploy may or may not take arguments. In regards to FOG the arguments you want to send still go into the “Snapin Pack Arguments” field. The developer of the .EXE has all of the control on what command line arguments they will accept. FOG can only pass what is in the “Snapin Pack Arguments” field when invoking the snapin.
For example if you have just a simple .exe that take parameters it would look something like this (using no preconstructed template)
If I misunderstood what you are asking, please clarify.
@imagingmaster21 do you need your whole fog database or only the image information? If its only the image information, the quickest way is via the web gui. Go into the images on server A and export the image definitions, then log into the web gui on server B and import the image definitions. This will move over the image definitions without over writing (messing up) anything else in your server B FOG server.
If your end goal is actually migrating to a new server, then there is a wiki page that covers the migration: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
@imagingmaster21 Ok so the target computer is saying it can’t reach your image store. All of the kernel parameters look good.
So we need to do some checking.
showmount -e 127.0.0.1
and post the output here. (Hint if you connect to your fog server using putty you can copy and paste the text without needing to do screen shots).ls -la /images