@george1421 Great stuff you are working on this full on!! I try to follow up on what you post and test. Though I don’t have the time to engage in this at the moment.

It’s interesting you and Junkhacker seem to get different results and it would be very important to figure out why. I can’t imagine it being a UEFI vs legacy difference issue as partclone should just be deploying the actual contents of the partitions no matter what the boot type or partition layout looks like. But what do I know…

@george1421 said:

I just tried to recapture a uefi golden image and I have an error about getPartitionLabel: command not found on line 486, then partclone exited with error code 139.

Not sure which version you used because we removed getPartitionLabel stuff recently. Please make sure you use the very latest version (master branch).

@Junkhacker The UUID error you see stems from an issue we had in the inits when I created the one you use for testing. This was fixed some weeks ago.

i tried the init you supplied, and i got a "failed to set disk guid (sgdisk -U) (restoreUUIDInformation)

Can you please post a picture of that?

@dambron said:

I’ve tried it myself and even when selecting “Single Disk- Resizable” and “Everything” it captures the image fine, but is not actually able to distribute to a smaller drive than 500GB.

Can you please post the contents of the following three text files of this image (/images/<IMAGENAME>/ on your FOG server): d1.fixed_size_partitions, d1.minimum.partitions and d1.partitions

@probbier Well, who added the links in the old version and how was it done? I am sure things have changed a fair bit since then and you need to figure out how to do this.

Don’t get me wrong, I will try to help you fix things but I have so much other things to do and can’t spend any more time helping you to customize your installation.

I’d suggest you look at the apache config generated by the FOG installer. Should be in /etc/apache2/sites-enabled/001-fog.conf on Ubuntu. There we have so called RewriteRule statements in place. Probably those prevent from links working for you but I am not sure.

@nvdp2002 The last we see in the log is Is the MySQL password blank? (Y/n) - how do you answer the question? Do you know the password of your database? Is it blank or set?

@probbier said in FOG 1.5.4 Client Management page:

client webpage

What do you mean by the “client webpage”?

@michaeloberg Please post the contents of the log file from the client (either in C:\fog.log or C:\Program Files (x86)\FOG\fog.log).

@Junkhacker said in The future of partclone and therefore FOG as it is:

a new feature i want to utilize was added in 1.3.8.

We can patch Buildroot to use the newer version. That shouldn’t be much trouble I suppose.

@Junkhacker said:

if the changes i want to be made make it in to the final builds,

Can you please post more details on which changes you’d like to have. I read about option -a0 and in the other topic it’s -aX0 and --rsyncable. Where do I find information about these options?

@Junkhacker So far we had version 1.3.3 and going to go to 1.3.5. As George said, just using the versions bundled with Buildroot.

@TaTa Thanks for the update. Would you mind opening a new topic for this as it has not much to do with the initial posting. I feel it’s good to keep things separated so people will find answers quickly as well.

At first I though you might be running into an issue we already found in 1.5.5 and fixed some weeks ago: https://forums.fogproject.org/topic/12911/chainloading-failed-advanced-menu (definitely worth reading the whole topic as it also has some information on how this works)

But as you are using dev-branch I suppose you already have that fix. When did you last update to the latest dev-branch version?

Can you please post your advanced menu code here? Possibly it’s just an issue within the menu code?!

Fixed in dev-branch.

@G-M Just a quick question. Is it the primary MAC or a secondary one you are trying to delete?

I am sure @Tom-Elliott will look into this as soon as he’s got some time.

@Rebelman This is not making sense to me. Seems like hidden menu is definitely not active on your server but still you get the output from boot.php as if it would be enabled.

One thing I noticed in the output you posted is that the settingID of FOG_PXE_MENU_HIDDEN on your server is 64. On mine it is 69. But FOG_PXE_HIDDENMENU_TIMEOUT is 114 same as yours. The settingID does not play a role as far as I know but I wonder if this is a first sign of some database issue/difference that might be playing a role in this.

Let’s step back from the details a little bit. Re-reading your posts I wonder about what you are saying this only being an issue with UEFI machines. You said: “I also just tested on an older machine that still uses Legacy and I have no problems imaging it”. Was this legacy machine as well new to FOG, I mean unregistered?

You might want to run the database maintenance just to make sure: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands

Could you possibly take a video of the boot process? Would be great to see the exact difference. Take one video where you boot an unregistered UEFI machine. As well take another video where you do the exact same steps with an unregistered legacy machine. Upload those videos and post links here.

For a clear good readable video capture you can rest your camera or smartphone on a pile of books on your desk. Will be way less shaky than doing it free hand.

@pdit Well here is what happens. You seem to switch between those IPs forth and back but this cannot be handled by FOG and its installer.

If your IP is currently set to 10.10.30.218 (from DHCP because you need internet) you cannot simply tell FOG to use a different IP (172.31.1.10) which is not configured on your network interface at that moment.

Be aware that changing the FOG IP involves more than just changing the IP in the Linux network config. See our wiki article on this: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

As well we have a script that does all the changes for you: https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

I might try to improve the installer to give a more clear answer to the user if an IP is given that does not exist on the machine right now.

Edit: The installer was updated in dev-branch to ask for the interface first and select the IP in the same step. We’ll release FOG 1.5.6 soon and this should have prevented what you are trying to do here in the first place.

@pdit said in dhcp issue:

Same E73’s works when imaged using in network Fog server

This is probably on a different switch as well!?! I am fairly sure this is where the difference is coming from.

@Wayne-Workman said in The future of partclone and therefore FOG as it is:

I reckon (not tested yet).

Need to emphasize this! @Junkhacker Has obviously worked on this and tested way more than I have.

@mwolfe60 said in master node sending data to storage node.:

can we not replicate those images and delete them from the storage node or is all or nothing ?

Open the image settings in the web UI and un-check the option Replicate…

I had a look a the new logs you send me and I still can’t see there being an issue. Possibly you just restart the fogreplicaiton service too early before it finishes transferring the huge file? From my point of view the replication algorithm seems to work. Here is an example:

...
[04-30-19 11:48:01 am]  * Found Image to transfer to 1 node
[04-30-19 11:48:01 am]  | Image Name: Automation_TB_CF54
...
[04-30-19 11:48:10 am]   # Automation_TB_CF54: File size mismatch - d1p2.img: 48334490621 != 1202149362
[04-30-19 11:48:10 am]   # Automation_TB_CF54: Deleting remote file d1p2.img
[04-30-19 11:48:10 am]  * Starting Sync Actions
...
[04-30-19 11:48:10 am]  | Started sync for Image Automation_TB_CF54 - Resource id #1105
...
[04-30-19 12:06:13 pm]  | Image Name: Automation_TB_CF54
[04-30-19 12:06:13 pm] | Replication already running with PID: 2651
...

So it finds that d1p2.img is not the same size on the storage node, deletes it and starts replicating it again. This is at 11:48. Then it checks all the other images and on the next loop (at 12:06) when it comes back to that image it tells us there the sync of that file is still going on and goes ahead.

Doing some quick maths here. Transferring a 45 GB file over a 100 Mbit/s link will take at least 1 hour 07 minutes and 35 seconds. And that calculation is most certainly still a fair way off. I’d expect it to take one and a half to three hours depending on the other traffic on that link. So you just need to be patient!

If the link collapses somewhere on between it needs to start over again. I know this sounds stupid but implementing a continuing sync that can pick up on a broken file is way more advanced. Not something we can implement on short notice.

@pdit Wayne is definitely on the right track there I think. Follow his instructions and post that information here. As well you might take a picture of the output “would you like to change default network interface from ?” so I might check if we have a bug in the installer as well.

@probbier Kind of what I expected to see. You seem to have two versions of the web UI installed on your server. One in /var/www/fog and the other one in /var/www/html/fog. In a normal installation /var/www/fog is just a link to /var/www/html/fog but this does not seem to be the case on your server.

From the dates we see that the most current version is probably installed in /var/www/html/fog as it should be. I’d advise you to move that other one out of the way and re-create the link as it is intended:

sudo su -
mv /var/www/fog/ /root/fog_backup_old_webdir
ln -s /var/www/html/fog/ /var/www/fog

After that you will be editing the same files again no matter the path - “/var/www/fog/lib/pages/clientmanagementpage.class.php” is the same file as “/var/www/html/fog/lib/pages/clientmanagementpage.class.php” after creating that link.

@michaeloberg Most of those issues turn out to be a problem with the entered IP/hostname in the setup. Find the latest example of this here: https://forums.fogproject.org/topic/13200/ca-certificate