@tmikecurry said in After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date":
…did this occur because we needed to re-inventory the hardware on the source laptop? (So it would stop associating it with the earlier image?)
In FOG the inventory has no association with imaging directly as far as I can tell. So I think setting the correct image in the host object was actually the solution.
@cavarmy said in unable to image a laptop:
I’m new to fog was able to capture the image but can’t deploy.
As we see from the outputs you posted (in the PDF) there is no image existing in /images - unless the output in the picture is truncated. But that’s just one issue I see because in the picture you posted first the error is pretty clear: “Connection timed out”.
As we don’t know your network structure there is not much we can do to help unless you provide more information - see my other post below.
@rodluz said in Persistent Groups Not Working - FOG 1.5.9.235:
I ran the command on both systems and the server using FOG 1.5.94 is using PHP 7.2.24 while the new server with FOG 1.5.9.235 is using 8.1.
This points to this being a PHP 8 issue. Though it’s strange you don’t see an error in the logs. I will try to replicate the issue as well. Will take a few days.
@brakcounty As I said this is not normal I reckon. From what we heard so far I can imagine some kind of security gatway causing the delay while checking HTTPS traffic. Though on the other hand that would need to be a highly sofisticated transparent proxy setup. Please check with your network team.
Other than that I suggest you do manual tests in your browser. Open Chrome or Firefox development tool bar and then load the boot.php and other URLs you find having the delay. See if you can find out what is causing it.
As a next step you probably need to install wireshark on the PC and capture the network traffic. Feel free to send me a private message with a download link to the saved wireshark pcap file if you need help with reading it.
@DPR-SIO said in “could not complete tasking (/bin/fog.upload)”:
I Think I may have found the solution to my problem but I’m not sure
Would be interesting to hear what you found.
@brakcounty Didn’t find the time to test on my side yet. Will do in the next days and let you know.
@Chris-Whiteley This is known and fixed in the latest version - really latest dev-branch as well as the latest official release 1.5.10 that came out a few days ago.
@jmeyer said in Update to last dev (1.6.0-alpha.1182):
Updating Database
Usually that’s the part where you need to open the web browser and let it update the database schema. Did you do that?
Do you run the installer with command line options or just plain?
@medchemii said in Capture not the entire disk but more than one partition:
is there a way to capture not the entire disk but more than one partition ?
The short answer is no. But there might be a way to achieve what you want on deploys. Though I have not tested this and I am not exactly sure this works. Figure out the partition number (start counting at 1), go to the image folder on your FOG server (usually /images/.....) and rename the file d1pX.img to .bak or whatever. Then try a deployment.
If this is not working and you are keen you can work on implementing this feature. Let us know and we can give you hints on where to look at.
As a side note:
The image type description in the wiki (I got there from the balloon help: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) points to a non-existing page (404): https://docs.fogproject.org/en/latest/management/image-management.html
Thanks! @JJ-Fullmer would you find the time to fix that quickly?
@hummela Not sure if spacing in names could cause this. I have not had much time lately and couldn’t find the time to look into this. But it’s on the list. Will get back to you.
@Warsonix Try using a different iPXE binary. The default for UEFI machines is snp.efi and you might want to try ipxe.efi or snponly.efi.
@Goll420 said in updating fog on centos 7:
Hi Tom, sorry to hi-jack the thread, but …
Why not open your own one?
what if you DON’T have the git installed?
Either install git or grab the tar.gz / zip archive version found on the website to download: https://fogproject.org/download
sudo -i
# or
su -
tar xzf fogproject-1.5.10.tar.gz
cd fogproject/bin
./installfog.sh
Our FOG server is on an isolated network without internet access so it’s not an option for me really.
Well, how did you install FOG in the first place then? Internet access is needed. Maybe you can install a NIC (wireless LAN or cable) to get internet access temporarily?
@Tom-Elliott said in Fog Snap-In Permissions Issue?:
Is it possible it’s requesting the resource from a different server than the one you know the files are on?
Just along these lines… do you have more than one FOG node in your network?
The remote server returned an error: (404) Not Found.
The snapin files are not requested via HTTP URL directly but through a helper script. See if you have /var/www/fog/service/snapins.file.php on your FOG server(s).
@JJ-Fullmer said in “Deploy Image” Not Working for HP Probook 450 G9:
I think you’re thinking of this post https://forums.fogproject.org/topic/16720/hp-elitebook-840-g9-cannot-deploy-image
No, that’s not the one. But I found it: https://forums.fogproject.org/topic/16746/using-deploy-image-via-pxe-with-more-than-two-nics
@LLamaPie @LLamaPie @rodluz Took a while until I found the time to look into this. But I found the bug and just pushed a fix to the latest dev-branch. Please update and you should not run into the issue no matter how many NICs you have.
@Tom-Elliott Would you like to check working-1.6 as well?
@jblomquist said in Is there a way to restrict FOG menu access to specific users?:
I’d like to allow a particular user to be able to deploy an image, but not quick delete a host through the PXE menu.
Which version of FOG do you use?
The quick delete option is secured in the iPXE menu in FOG 1.5.10 (github commit).
@nil said in Could not mount images folder /bin/fog.upload:
I run Fog on a debian 10.5 with dhcpmasq in proxmox container.
Possibly Proxmox setup is causing NFS to fail.
There was a brief discussion on Proxmox containers in the forums just a few weeks ago: https://forums.fogproject.org/topic/14996/fog-on-proxmox
@Strahd Ok, this one is pretty similar but it can only be fixed in the code. But before I ask you to update to the latest dev-branch version we should better try a manual fix for you. Can you please edit /var/www/fog/lib/fog/bootmenu.class.php and jump to line 1056 or search for “param imageID”.
Here is how the code should look like originally: https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/fog/bootmenu.class.php#L1062
Please add that single one line (or all three if you add the comments as well) after line 1062 like this:
...
'param imageID ${imageID}',
'param qihost 1',
'param username ${username}',
'param password ${password}',
'param sysuuid ${uuid}',
'isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme',
'isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme',
// add line START
'goto bootme',
// add line END
);
unset($Image);
...
Just save the changes, no need to reboot the server or anything. Changes are life right away. If you mess with the code it will break PXE booting for any client.
As mentioned below there is a glitch in 1.5.8 on Debian 10 as well. I just spun up a test VM and did a quick recovery as the steps might vary between different systems and versions. This should work on Debian 10 with MariaDB 10.3.22 - run as root:
systemctl stop mariadb.service
mysqld_safe --skip-grant-tables &
mysql -u root
Now from here we are in the mysql shell and can try to change the password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.3.22-MariaDB-0+deb10u1 Debian 10
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> select user,password,host,plugin from mysql.user;
+------+-------------------------------------------+-----------+-----------------------+
| user | password | host | plugin |
+------+-------------------------------------------+-----------+-----------------------+
| root | *B9179FF9CF31E6DDF1DCEA4E656BCB4C5CA71943 | localhost | mysql_native_password |
+------+-------------------------------------------+-----------+-----------------------+
1 row in set (0.002 sec)
MariaDB [(none)]> update mysql.user set password=PASSWORD("newpassword") where User='root';
Query OK, 1 row affected (0.001 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [(none)]> update mysql.user set authentication_string=PASSWORD("newpassword") where User='root';
Query OK, 1 row affected (0.002 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [(none)]> update mysql.user set plugin='mysql_native_password' where User='root';
Query OK, 0 rows affected (0.002 sec)
Rows matched: 1 Changed: 0 Warnings: 0
MariaDB [(none)]>
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.009 sec)
MariaDB [(none)]> quit
Bye
Ok, password is set! Now let’s restart the DB and test connecting as root:
killall -15 mysqld
systemctl start mariadb.service
mysql -u root -p
Maybe even re-set the password again using the proper tools now that you have access again because messing with the user table is not that great but as far as I know it’s the only way on this version.
mysqladmin -u root -p password
Enter password:
New password:
Confirm new password: