Best posts made by george1421

See if this one fits the case: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

@dambron When you look at the uploaded image size in FOG Image management, what is its file size compared to how much actual data is on the reference image hard drive?

If you were to capture that same reference image again, looking at the partclone screen does it say capturing in RAW mode?

@lucas942 said in .fogsettings don't exist:

/opt/fog/.fogsettings

First of all this file is hidden by default so by just browsing /opt/fog you will not see it. You need to use ls -la /opt/fog to see it.

Second this file is created after the first time you run the fog installer script. If something happens where the installer script doesn’t complete successfully that file will not be created. That file contains the values selected during your initial setup of fog.

Normally you do not need to edit/change this file. What specific problem are you seeing?

Lastly, your english is perfect, no need to be sorry. I will not say bad things about you even if you are french.

@DarKFeeliN OK if the fog server, dnsmasq server, and pxe booting clients are on the same subnet then dnsmasq will (should) work without modifying your networking infrastructure. dhcp works through broadcast messages. If the dnsmaq server was on the same subnet as your dhcp server then you must update the networking infrastructure.

Now to understand why its not working. I want you to follow this tutorial. Since you have public IP addresses upload the pcap to a share file site (like google drive) and then IM me the link and I’ll take a look at it. The pcap will only contain pxe boot information if you follow my capture filter. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you want to look at the pcap in windows you can use wireshark. You should see the client send a dhcp discover packet and then both the main dhcp server as well as dnsmasq sending a dhcp offer packet. As long as both offers are received by the target computer then it should work. There are a few other things to look out for so I need to see the pcap file.

@DarKFeeliN said in Not able to PXE boot from FOGServer on Proxmox LXC with proxyDHCP:

I haven’t been able to record a single packet from port 67, 68, 69 or 4011 for the duration of the time I had a client try to boot from PXE for both the fogserver and the proxmox host.

I suspect the gateway switch might suppress those broadcoasts. I will build a small local network with a switch I control, redo the tcpdumps and report if the results are different.

This might sound bad but this is a good bit of information. For dhcp to work, broadcasts MUST be supported on your network. Even if you are not picking up the other parts of the pxe booting process you MUST see the discover, offer, request, and ack/nack messages (also dhcp inform messages too) or there is no chance of any target computer getting a dhcp address.

So your fog server is running as a vm under Proxmox (I don’t know this hypervisor so I can only speak in general terms).

1. If you create a VM (or have one) on this same vm host server does it pick up a dhcp address in the x.y.42.X range?
2. Do you have the fog server bridged to the business network (not natted)?
3. Do you need to set the vm host server interface into promiscuous mode?
4. If you take a second computer as a witness computer with wireshark installed connected to the same network switch as the FOG server’s vm host do you see any dhcp traffic?

Once we see dhcp traffic then we can focus on if dnsmasq is working like it should.

@lucas942 said in Nas node storage : permission denied:

I just got to find a directory in / images on the NAS 14gb its name is: e86a64cbxxxx and this corresponds to the MAC address of my PC.
So I rename this folder “Standard”?
Because the name of my image is “Standard”

You have a few things that are wrong.

1. The image file should be first captured into the /images/dev/<mac_address> folder.
2. After the image is fully uploaded to the /images/dev/<mac_address> folder the target computer logs into the FOG server (nas in your case) via FTP and issues a move command to move all of the files in /images/dev/<mac_address> to /images/<image_name>.

The screen shot of the error you see about ftp_put tells me that in the storage node configuration there is 2 fields Management Username and Management Password. The values in those fields must match the user you created on the NAS device.

Have you changed or messed with the linux user fog’s password or user account? Understand this is not the default web ui admin named fog, I’m talking about the linux service account by the same name. If so you may want to run through this tutorial to fix everything: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

Is 10.16.20.2 the IP address of your fog server?

I’m shooting from the hip here, but since the table is blank we can’t break it more.

sudo mysql -u root -p fog

Press enter for the password

INSERT INTO users(uID,uName,uType,uAllowAPI) VALUES(1,'fog',0,1);

UPDATE users SET uPass = MD5('password') WHERE uName = 'fog';
exit;

If the insert into doesn’t work then try this query instead

INSERT INTO users(uName,uType,uAllowAPI) VALUES('fog',0,1);

If its having an issue with insert into then I will need to look up the exact syntax, but it should be close.

You should then reboot the fog server to flush the cached tables.

Make sure your firmware is up to date in this hardware. Its failing between the UEFI PXE rom hand off and iPXE starting. Typically when we’ve seen this in the past it was related to cruddy early generation firmware.

@willian said in Change the boot order automatically:

What I meant is if you configure each machine to enter the boot menu by F12

On the Dell systems, when its at the Dell splash screen if you hit F12 you will be presented with a ROM boot menu. From there you can (one time) change the boot order from the default hard drive to a network or cdrom boot. There is nothing to configure for this, you just hit 12 for dells and sometimes F1 or F10 for other hardware to get this boot menu. We do this because I want the IT Tech sitting in front of the computer they are to image so they know for sure what system they are imaging. If they have to image 10 machines at one they boot each machine, hit the F12 and select network boot.

Our approach would be different if I needed to image 30 computers all at once using the FOG multicast imaging, such as in a educational classroom setting.

@JerJer Well… I found in the git hub notes that 0.9.1 was in the build release for quite a while. I have not contacted one of the developers to find out what is currently shipping.

I would then revert to my previous request to temporarily rename refind.efi and then go through the pxe boot process and exit to the hard drive. I have not ever heard of refind being sent to a bios based computer before, especially since its not listed in the iPXE menu. I don’t understand how its getting to the target computer.

@kenneth-sisco Ok now where its stopped is its trying to write the kernel files to /var/www/html/fog/service/ipxe directory. If I remember correctly there was a bug in 1.4.4 where the directory permissions did not let the linux user fog (or apache I can’t remember which) write into that directory. While there is a slight security risk in this if you issue the command chmod -R 777 /var/www/html/fog/service/ipxe that will mask the directory permission issue and allow the ftp download to write to that directory. The security risk is that you are setting world read-write access on that directory.

If you still can’t get the download to work, you can update the kernel by hand, but lets see where fixing the permissions on the kernel directory gets us.

@kenneth-sisco said in FOG Kernel Update Errors:

/var/www/fog/service/ipxe

Well that’s great you have it sorted out.

Yeah some time after 1.4.4 the path was standardized across all linux distros because you had the debian variants in /var/www/fog/service/ipxe and the rhel variants in /var/www/html/fog/service/ipxe it was too hard to give clear directions to fog admins so the developers merged the paths together.

@kenneth-sisco Yeah based on the title this issue is solved. Lets start a new thread with this “new” issue. The developers don’t really like us to mix threads because it confuses the future readers.

But in the mean time as you start a new thread. Kill this current capture/deploy task and then reschedule the task with the debug check box ticked then schedule the task. PXE boot the target computer. You will see several screens of text that you will need to clear with the enter key. After the pages have completed you will be dropped to the FOS Linux command prompt. At the FOS linux command prompt key in ip addr show and lspci -nn|grep -i net and post the results in the new thread. Also include in that new thread the hardware manufacturer and model of computer that has this issue.

@kenneth-sisco Ok that is good (being on 4.11), well not really but explains why the network adapter isn’t working. Remember that the kernel is booting from the USB flash stick. So its the bzImage and bzImage32 on the flash stick that counts here. So you need to update the usb flash stick from here: https://fogproject.org/kernels/

Grab Kernel.TomElliott.4.19.36.64 and save it as /boot/bzImage on the flash drive.
Also grab Kernel.TomElliott.4.19.36.32 and save it as /boot/bzImage32 on the flash drive, replacing the files that are there.

Remember that case IS important.

As far as files and paths, I’m a RHEL guy so I have a certain slant on things and file paths. The debian variants (where FOS Linux is) confuse me a bit, i can get you into the ballpark but you will have to find the bases. Its good you were able to fine what you needed in /var/log/messages.

@kenneth-sisco Ugh, I’m mixing up my thread again. Sorry. The files go in /var/www/html/fog/service/ipxe directory. You should be able to update the kernels using the FOG Settings menu.

@vpt said in Unable to use an NFS share to store images:

With this setup, I get an error message during capturing that states that access is denied when attempting to mount the share to the /images directory. I have verified that the share on the QNAP is wide open to anyone, but I still get an access denied.

Its probably because FOS Linux connects to the storage node using NFS and the NFS server (QNAP in this case) has squash_root enabled (meaning that it rejects root mounting the NFS share). I have some KBs in the tutorials forum that talk about synology NAS and using a windows server as a FOG storage node (not recommended) that mentions this setting too.

Hmm… I find it interesting that its trying to load a non-fog init (virtual hard drive). Why is it referencing fog/images/init.gz Secondly, the init for fog should be .xz compressed and not .gz compressed. Off the top of my head, I don’t know of the FOG kernel will be able to expand a .gz compressed file since natively it only understand .xz.

But the error basically says the kernel could not connect to the virtual hard drive.

@AlexPDX said in kernel panic-not syncing: VFS: unable to mount root fs on unknown block(1,0):

I followed the instalation steps exactly

I find this hard to understand. If you followed the installation steps exactly then it would not try to load fog/image/init.gz. Where did you get the instructions to install fog 1.5.6?

Can you go to this url with a web browser and then post the output here. http://192.168.192.111/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 and also http://192.168.192.111/fog/service/ipxe/boot.php?mac=f8:b1:56:d9:b8:ab

@AlexPDX OK, can you show me the host definition for the system Windows10-CLEAN?

Also I have to ask you why you have this item in the FOG iPXE menu?

item FOG_1.5.5 FOG Server

kernel bzImage loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=http://192.168.192.111/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.192.111:/images/ storageip=192.168.192.111 loglevel=4
imgfetch init.xz
boot || goto MENU

This is set as default but it doesn’t “do” anything. I know it boots the fog kernel, but its not a standard menu item.

Back to what you posted there is nothing in the iPXE menu to call fog/images/init.gz that I can see.

Lets start with the host definition screen shot, then if that doesn’t give us a clue, I’ll have you schedule a capture or deploy (whatever you were doing to that computer when it threw that error), but don’t pxe boot the target computer. I’ll want you to run that second link. As long as the computer mac address is the same it should give us a little better picture. When a task is running, that call to boot.php will be very short.