Hi All,

I’ve been using the fog project for a while (5 years or so). I’ve been heavily relying on it to install various workstations. Today I ran into an issue that I never experienced before. I’ve installed clients with 2 nics without any issues. Normally the pxe boot would simply boot off of whatever nic was connected to the LAN. Today I was installing our standard image that I’ve been using for years, on a Dell Pro Max Slim workstation. Now I’ve installed this type of workstation in the past without any issues, but of course with only one nic. Today the system has 4 nics. Only 1 of the 4 nics is connected to the LAN. The system starts the PXE, and it appears to get it’s IP address and proceeds to the next stage. This time it gets it’s IP address but then scans through the remaining 3 nics… None of them have an IP address configured so they fail. It seems to forgotten that the first nic got the IP address without any issues. When it proceeds to go to the install stage it kacks out as it doesn’t believe it has a valid IP address. If I simply pull the 3 nics out and install the system everything works. Yet I have to re-configure the box with 4 nics in the end. Anyone have a way to tell the fog server, simply continue after getting the first card IP address. (ie stop searching for other nics).

Hey All,

I recently transferred a perfectly working fog project server to another server and pouched the postdownload script functionality. I’ve gone through a bit of debugging. I put a /bin/bash inside my /images/postdownloadscripts/fog.postdownload so that I could shell out and see why I’m not getting the client hostinfo that I used to fetch with curl leveraging the fog-api-token and fog-user-token.

I’ve validated that my ${FOG_API_TOKEN} contains the same string that is on my configuration page of my fog server. I’ve also validated that my ${FOG_USER_TOKEN} contains the same API string for a user within my user list. Both the user and the fog settings have the api enabled.

Yet if I issue the following from my bash shell on the client after doing the pxeboot:

curl -A “” -Lks
-o /tmp/hostinfo.sh
-H ‘Content-Type: application/json’
-H “fog-api-token: ${FOG_API_TOKEN}”
-H “fog-user-token: ${FOG_USER_TOKEN}”
${web}/service/hostinfo.php
–data “mac=$mac”

Where $mac is the mac address of the pxe booted client, and $web simply contains http://192.168.1.35/fog/. Yet the contents of the file /tmp/hostinfo.sh is essentially:

No token passed to authenticate this host

I kinda need the othertag1 from the fogserver where I store some unique information about the client. Prior to my moving of my server to the new configuration this worked fine… Any insight on this matter would be greatly appreiated.

@sebastian-roth

Okay so I’ve done the following debugging so far… The image that I created was called CentOS7-MBR, as it’s a MBR not a GPT installation. After letting the system boot via pxe and get to a fogclient prompt I referenced the URL:

Troubleshooting an image

Now unfortunately I’m dumping a linux image via partclone not a windows 7 image but I thought the process would be similar.

# dd if=d1.mbr of=/dev/sda bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.0256039 s, 20.0 kB/s

# partprobe 

# cat d1p1.img |pigz -d -c |partclone.restore -O /dev/sda1 -N -f -i
Partclone fail, please check /var/log/partclone.log !

# ls -ld /dev/sd*
brw-rw---- 1 root disk 8, 0 Feb 27 16:06 /dev/sda
brw-rw---- 1 root disk 8, 1 Feb 27 16:07 /dev/sda1
brw-rw---- 1 root disk 8, 2 Feb 27 16:06 /dev/sda2
brw-rw---- 1 root disk 8, 3 Feb 27 16:06 /dev/sda3
brw-rw---- 1 root disk 8, 4 Feb 27 16:06 /dev/sda4

So… not sure how to proceed. When I looked into the partclone log file it wasn’t much help:

# cat /var/log/partclone.log 
Partclone v0.3.13 http://partclone.org
Starting to restore image (-) to device (/dev/sda1)
read image_hdr error=0

Any advice…

I know if I attempt to re-install the system with any disk, which is large enough to hold the image I will get the above issue. constantly now. I’ve put the system in debug mode and I’m attempting to issue the install commands by hand to see what the issue could be. I believe the issue either has to with the partition layout not being re-read into the kernel space. ie if I have a system that has no partitions, or the disk has existing partitions, yet different physical layout, and I deploy a realizable disk image it will produce this error. It’s almost as if I need a hdparm -z /dev/sda a few thousand times until the kernel recognizes the partition change and alters /dev

Re: Deploy image not expanding partitions

I’ve been using the fogproject to deploy windows images for some time now and thought I would attempt a linux deployment. I had already done so with a pxe via hand scripts and wanted to see how fog project handles it.

Initially I was quite impressed. I captured an image (one disk, 4 partitions and made it resizable). Capture went well and I was able to deploy on a few boxes. Now the image has been sitting for about 6-8months and I attempted to re-deploy. Yet now the deployment fails as it wants to e2fsck before resizing and I have no way of interrupting the process to do so.

Sadly I went back to my older method of deploying images. Once deployed I decided to re-capture it but this time use the non-resizable option. After the capture was complete I decided to re-deploy the image. The image deployed without any issues. As I still had the old “resizable” image I thought I would change images and redeploy again. This time the resizable image deployed without any issues.

Still curious I pulled the drive and put another blank drive onto the system and attempted to deploy the resizable image. Again it failed to deploy saying: "Could not resize /dev/sda1 (expand Partition)
Please run ‘e2fsck -f /dev/sda1’ first…

Please help me resolve this issue.

Just so your aware my fog server is a CentOS 7 box, running FogProject 1.5.9