@londonfog There is a long story about NVMe drives swaping around possibly on every reboot as the kernel does not seem to enumerate the drives always in the same order as it does with ATA/SCSI drives. For more details see here: https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message

For your situation: I am not sure what we can do to help you work around this. Please read through the other topic and see if you can get an idea on this.

@Quazz Thank you. I’ll look into the API.

This issue could probably be closed now. The image “export/import through API”-issue seems to me is a new and separate, though closely connected, issue.

For future readers the best solution, if FTP is possible over your network, would be to set up the remote servers as a “storage node” with “Is Master Node” unchecked. When this is done you simply check the “Replicate?” field for the images you want to be synchronized across all sites. You will still need to use the import/export functionality to make the images available at the remote sites.

However if FTP is not possible over your network you need to use rsync or scp or your preferred file transfer method, to transfer the images. (More examples can be found here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually) This also requires the use of the import/export functionality.

@JGwinner Please create a new thread with all the details of your problem.

@Richardpofnz Ok let’s see what the server side does. On the FOG server run tail -f /var/log/apache2/access.log (or tail -f /var/log/httpd/access_log if you are on CentOS/RHEL/fedora) while you do the menu stuff on the client.

On my test system it looks like this when I try “Deploy Image” from the menu:

192.168.2.10 - - [08/Jul/2019:14:11:10 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 2768 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:10 +0200] "GET /fog/service/ipxe/bg.png HTTP/1.1" 200 21280 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:31 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 813 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:34 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 464 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:35 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 481 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:35 +0200] "GET /fog/service/ipxe/bzImage HTTP/1.1" 200 8389280 "-" "iPXE/1.0.0+ (9907f)" ...

@Sebastian-Roth It’s alive!!

1232845e-7912-4553-b385-dddb8cb4ec12-image.png

Thanks for the help on this, really appreciated.

I just updated the official init files on the webserver. Marking as fixed.

@Julianh No it won’t wipe the image definitions or anything else important. It only removes DB entries that are obviously wrong (not pointing to valid entries or something like that).

It’s not very hard to do - just enter the DB password you find in /var/www/html/fog/lib/fog/config.class.php - might even be empty so you just hit ENTER on the password entry:

shell> mysql -u root -p Password: ... mysql> use fog; ... mysql> DELETE FROM `hosts` WHERE `hostID` = '0'; ...

Run all the commands mentioned in the wiki article.

@blackburn56789 Can you please give us some more details on the use case you think of when asking about this? Possibly we can help you with this if we know what you are trying to do.

As far as I know there is no way to add snapins automatically right now. And I am wondering what the trigger would be to add a snapin to a host. Registration!?

@gazzer82 said in Unable to boot to HDD whilst using PXE Boot USB:

Is their any way for me to target specific machines with different settings?

You can set specific EXIT TYPES for each host machines. Unfortunately there is no way to specify individual refind.conf files in FOG yet. Though it’s not very hard to manually add this to the code. I might suggest you give this a try as we won’t have the time to add this as a feature as quickly.

Edit /var/www/html/fog/lib/fog/bootmenu.class.php and jump to line 135. Here you add another variable same as the one above in line 131-135 so it looks like this:

$refind = sprintf( 'imgfetch ${boot-url}/service/ipxe/refind.conf%s' . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi', "\n" ); $refindbugged = sprintf( 'imgfetch ${boot-url}/service/ipxe/refindbugged.conf%s' . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi', "\n" ); ...

The only difference between the two is the variable name and the conf file name.

In that same file jump to line 170 (166 if you have not added the code above yet) and add the new item to the list here:

... self::$_exitTypes = array( 'sanboot' => $sanboot, 'grub' => $grub['basic'], 'grub_first_hdd' => $grub['basic'], 'grub_first_cdrom' => $grub['1cd'], 'grub_first_found_windows' => $grub['1fw'], 'refind_efi' => $refind, 'refindbugged_efi' => $refindbugged, 'exit' => 'exit', ); ...

And now there is one more place to edit to make this new item available in the web UI: /var/www/html/fog/lib/fog/service.class.php - around line 210:

.... $types = array( 'sanboot', 'grub', 'grub_first_hdd', 'grub_first_cdrom', 'grub_first_found_windows', 'refind_efi', 'refindbugged_efi', 'exit', ); ...

Save the changes and go back to the web UI. You should be able to select “REFINDBUGGED_EFI” in the host settings now. Create a file /var/www/html/fog/service/ipxe/refindbugged.conf with the specific settings you want for those clients.

Those changes will be lost when you update your FOG installation. This is definitely not a proper fix for your situation. But this should help you work around the issue for now.

@Matdes “check the fog server to ensure disk space is good to go” is not a very detailed error. Partclone doesn’t pass back the actual error to the calling program, only the capture failed. The FOG code tries its best to determine the root cause of the partclone capture failure, but some times it misses.

What we really need to see is the text that sprawls across the partclone screen when it errors out. To get this info please do the following.

Schedule another capture task, but before you submit the capture task, tick the debug checkbox. Schedule the task PXE boot the target computer After several screens of text (where you need to hit enter to clear) you will be dropped to the FOS Linux command prompt. At the FOS Linux command prompt key in fog This will start the capture process in debug mode. At each breakpoint the code will stop waiting for you to press enter to go on to the next step. Somewhere when partclone is capturing partition 3 you will see this error. Take a clear picture of the sprawling text with a mobile phone and post the results here.

That text will actually be the root of why partclone can’t capture that partition.

@Matdes When you delete images on the image list overview the files are not being deleted. This is intended.

If you want to see the files being deleted then go the image settings and use the tab named Delete…

@george1421 Perfect, thanks.

We figured out that an upgrade from mysql to mariadb caused the issue. The database is not completely lost but more or less renamed. We found this hint in the apt logs:

The file /var/lib/mysql/debian-5.7.flag indicates a version that cannot automatically be upgraded. Therefore the previous data directory will be renamed to /var/lib/mysql-5.7 and a new data directory will be initialized at /var/lib/mysql. Please manually export/import your data (e.g. with mysqldump) if needed.

Seems like this is kind of a known problem: https://askubuntu.com/questions/766917/14-04-to-16-04-killed-mysql

Right now we are working on getting the old database back up. Not looking promising. MariaDB crashes terribly when we let it start on the old MySQL 5.7 DB files.

Edit: We were not able to start up the old DB with the new MariaDB version. So the only way I could see was setting up another system (probably old Ubuntu 14.04) with the old MySQL 5.7 version, get up the database there and do a mysqldump as this format can be imported into newer versions. So we decided that it’s probably less work to manually add the image definitions by hand than recovering the old DB. Hope this topic will be helpful for others running into this. Although I guess there aren’t many people still around upgrading from the old version.

@dospace I’ll mark this solved now as the initial issue is found. If you run into issues with manually creating the image definitions just open a new topic and post all the details there (ls -al /images/<IMAGENAME> as well as file /images/<IMAGENAME>/d1p1.img).

@george1421 yes after i tried so much things i remembered that fog runs the batch as SYSTEM. So i think that will be the problem because the Installer copies Files into the Users Folder. I will try your another suggestion with the mapped drive.

@Sebastian-Roth I tried to get a silent command for the installer and tried the standard lines like /verysilent , /silent , /s, /quiet , /q. And yeah it actually worked only with /s 😄

@Sebastian-Roth Yeah, thank you this helps, now is working.

thank you again

@CoxM https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

would you provide the outputs from these commands.
lsblk (I know you already ran this)
df -h

I’m going to bet that you have 500GB of space, but knowing how centos works, it allocated 450GB to /home and not / where /images live. 50GB is the default allocation for the / partition.

@siara Hmmm, I still can’t see why this is failing on your server. Let’s try to get even more into the details. You said that Membership and Delete are working ok. I can understand that because those are handled by a different part of the PHP code. But I can’t think of why Inventory should properly work while all the others don’t. Are you really sure about this?

When you hover over the links with your mouse you should see the link that it would go to, e.g. http://192.168.2.10/fog/management/index.php?node=host&sub=edit&id=1#host-powermanagement
See that it uses the # in the URL to go to the different sub sections. Do the URLs look similar on your server?

Just trying to gather some more information and hopefully stumble upon what’s wrong here.

@chadw18 said:

After running a capture, it will get to 100% then it states unable to locate Database path and reboots.

There are a couple of different messages you can get at this stage. Please take a picture of the message on screen and post here so we know exactly what you run into and can help appropriately.

This problem was solved. I believe that the database server was reinstalled or a new one was installed and thus there was no password.