Posts made by george1421

ok I want you to run the following command from a windows computer browser.

http://10.100.10.22/fog/service/ipxe/boot.php?mac=00:1c:42:86:14:c4
Post the output here.

I worked with the OP over DM for quite a while and then setup a TV session. The root cause here is that ubuntu is the enemy of fog (bug). Then during the execution of the ALTER USER step in the link I provided below the password for the mysql root user became confused. We ran through the mysql root user password reset process to reset the password which worked. But the upgrade still failed to backup the current database. Long story short, there was a second background mysql process running causing the process the fog installer was managing to fail causing the backup of the database to fail. Once we found this back ground mysql process running we killed it and then restarted mysql. This time the install succeeded as designed.

Case closed.

@elias-santiago As part of that post did you also execute the ALTER user command? If so the password for the root user is now <blank>.

If you can no longer log into the mysql server using a known password (or blank) then you will need to follow the process to reset the root account for mysql: https://support.rackspace.com/how-to/mysql-resetting-a-lost-mysql-root-password/

@elias-santiago just to confirm one more time. You know the password to log into mysql using mysql -u root -p fog right? If you can have your confirmed in your /opt/fog/.fogsettings file that snmysqluser='root' and snmysqlpass= the password you used to login to mysql and snmysqlhost='127.0.0.1'

There is something wrong here. The error says the .fogsettings file is wrong.

@elias-santiago In the same directory as the installfog.sh script, there is a log directory. In that directory there should be an error log file for the version you are currently installing. See if that log file contains why the backup failed.

@elias-santiago My question was more about, does your fog server use a proxy to reach the internet, where you set http_proxy=<server_ip>:<port> if that was the case then you need to be sure to include the no_proxy clause or you will get the backup error. But since your fog server can reach the internet directly this isn’t the cause of your error.

@elias-santiago Just wondering, do you use a proxy server to access the internet or does your fog server have direct access to the internet?

@jim-graczyk In short, will what you did work. Most assuredly. That is one way to go about it. And I will tell you its much easier to do it the way you did it than post FOG install. Unfortunately some people only realize that they need more disk space after they have setup fog and fully configured it. So to avoid reimaging the server with the proper disk space there is a round about method to do exactly what you did, but post install. In the since of performance standpoint for your VM, you will probably be better off (performance wise) with a 2 vmdk/vhd model since you will have 2 disk worker threads (one for the OS disk and one for images). So this route is (IMO) the preferred route.

Now to your point about all of the other stuff I did. I’m an old unix guy so I have a golden rule. No unregulated (size) data goes on the OS partition/disk. This is for windows as well as unix/linux. In unix if you fill up the root partition the OS will crash, and usually crash so bad the only solution is to reinstall the OS. With that in mind, I see the /images and /snapins as unregulated (controlled) storage. So in the thread I moved both locations to a vmdk different than the root partition. I could be wrong, but I don’t think the FOG management program considers existing disk space availability or disk reserve when you go to upload objects into storage. If you have good control on your snapins or don’t use snapins then mounting /images to the new vmdk is sufficient.

@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:

I would also offer the suggestion that you separate the /images folder onto a separate virtual disk.

I would also recommend this. The issue I’ve seen is filling up /images with images will take down the OS since /images is part of the root file system. Its roughly equivalent to filling up the drive of a windows computer. You typically don’t place uncontrolled growth data on your OS disk in windows, the same applies to linux.

I don’t personally like the idea of shuttling in and out images as needed. But if one had some just a little bash shell scripting skills it could be done. You might think about it as a poor man’s hierarchical storage solution. You would keep active images on high speed disk and then shuttle the image to lower speed (possibly usb attached) storage.

In regards to moving the images off the root partition. I did create a tutorial on how to do this with centos, similar concept can be done with ubuntu. https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition

Here is the process to apply the patch:

1. Open a linux command prompt on your FOG server.
2. Key in the following command:
   sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php
3. Remove the plugin
4. Reinstall the plugin
5. Add in your plugin settings and save

@gob There is a bug in 1.4.4 that needs to be patched. Let me get the download url for you.

@louislagad OK lets see what the pcap is telling us. That will give us a better picture of what the client is seeing.

Just wondering, is the dhcp server configured for some other imaging solution?

@louislagad Are client and fog server on same subnet?

@louislagad If the last post doesn’t fix the issue then lets grab a pcap of the dialog. What we need to get a crystal clear picture is that the fog server, dhcp server and pxe booting client need to be on the same subnet (vlan).

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to a google drive and either post the link here or send me a IM with the link (if you don’t want it published globally). I’ll take a look at it with wireshark so we can understand what the client is seeing.

@louislagad said in PXE E74 on some PC:

pxe-service=X86PC, “Boot to FOG”, undionly.kpxe
pxe-service=X86-64_EFI, “Boot to FOG UEFI”, ipxe.efi
pxe-service=BC_EFI, “Boot to FOG UEFI PXE-BC”, ipxe.efi

OK what I want you to change is this in the config file I posted. (I know this config file works in 90% of the cases but some times we need to add a little more magic).

Update the above section to look like this (replacing <fog_server_ip> with the fog server’s IP address):

pxe-service=X86PC, "Boot to FOG", undionly.kpxe,<fog_server_ip>
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi,<fog_server_ip>
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi,<fog_server_ip>

Don’t forget to restart the dnsmasq service after you update the config file.

[Mod note: I updated your post to include a code block so its easier to read your config]

You might want to start with this config from the following post. https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6

This config is known to work correctly. Just be sure to update the fog server’s IP addresses.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_ip>,proxy

@elias-santiago has the database password changed for some reason? Have you changed the root user mysql password?

If you look in the file /opt/fog/.fogsettings. There should be the mysql user ID and password listed there. See if you can use that to login to the mysql console with mysql -u root -p fog and when prompted use the mysql password listed in the .fogsettings file.

Since you are also running ubuntu you may want to review this post: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@i00 FWIW: The last instructions left by the installer script did tell you the same thing. If you question what I’m telling you, rerun the installer (no harm doing this) and watch the prompts. It will use the prompts you first selected. The FOG wiki also is a great source of information on how to use FOG.

But point taken, we probably should update the wiki.

I’m glad you got it working. If you have questions post back to the forums.

regards

(I know this will sound a bit snarky) Do you understand what you just installed, and why you installed it?

FOG is a web based imaging tool. There is a web console on the FOG server you can log into at http://<fog_server_ip>/fog The management url is presented at the end of the installation script.

From there you need to follow the instructions during the install of configuring your dhcp server to send out the ip address of the fog server and the boot file name so your pxe booting target computers can find the fog server. This is done by setting dhcp option 66 to the ip address of the fog server and dhcp option 67 to the name of the boot loader, which must match the type of pxe booting client (bios[legacy mode] / uefi).

Then on the pxe booting computer you need to set it to network boot (either through the bios settings or use the firmware boot menu). That should take you to the fog ipxe menu where you can register the target computer with FOG or test hardware compatibility with FOG.

Once registration is done you can schedule either capture or deploy tasks.

There are many videos on youtube on both FOG setup as well as how to use it for system imaging.

@bigjim That is correct. You can only deploy a bios (legacy mode) image to legacy mode computers, and uefi images to uefi based computers. They are not interchangeable. This isn’t a limitation in fog, but more of a hardware consideration.

You will need to create your vm and configure it for uefi mode before installing your reference OS. If your VM is based in vSphere there is an option setting in the setup configuration for the vm. To change it isn’t difficult. Just select the radio button for uefi. Then install your OS.