Posts made by Tim Reynolds

@Tim-Reynolds @Sebastian-Roth I resolved the issue. I created a new VM with the same Ubuntu 22.04 then installed the latest dev branch of Fog (1.5.10.5) instead of the stable version. After importing images and the SSL folder and re-installing, everything now works as it should.

@Tim-Reynolds @Sebastian-Roth Any other ideas? My backup plan is to use Clonezilla to clone the physical fog server into a Hyper-V VM, but I’m not having a lot of luck with that either. What are your thoughts about installing Fog 1.5.9 instead of 1.5.10 onto my Hyper-V VM and then migrating the images, SQL DB, and SSL from the old server which was 1.5.9? Then, if everything works, I could upgrade the installation in place.
Thanks!
Tim

@Sebastian-Roth I am sure. When I go to the management console page, I see this login page:

When I go the Fog Version Information page, I see the following:

The Fog I upgraded from was 1.5.9. But all I did was copy the images and SSL info as directed in the Fog migrations instructions.
Most everything works. I even dropped an image from the new server. The main (very important) things that don’t work is the Hosts Details page and the Snapins page.
I’m thinking I might try using Clonezilla to clone the current server and then restore that image into a new VM then upgrade from the VM. I’ve never done something like that. Any thoughts on that?
Thanks in advance!
Tim

Here is a portion of the apache2.log file showing the results of loading the Hosts Details page:
[Thu Jul 13 09:28:29.313965 2023] [proxy_fcgi:error] [pid 107916] [client x.x.x.x:63487] AH01071: Got error ‘PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/snapin.class.php:392\nStack trace:\n#0 /var/www/fog/lib/fog/snapin.class.php(392): min()\n#1 /var/www/fog/lib/fog/snapin.class.php(344): Snapin->getPrimaryGroup()\n#2 /var/www/fog/lib/router/route.class.php(1315): Snapin->getStorageGroup()\n#3 /var/www/fog/lib/router/route.class.php(488): Route::getter()\n#4 /var/www/fog/lib/pages/hostmanagementpage.class.php(1786): Route::listem()\n#5 /var/www/fog/lib/pages/hostmanagementpage.class.php(3244): HostManagementPage->hostSnapins()\n#6 /var/www/fog/lib/fog/fogpagemanager.class.php(220): HostManagementPage->edit()\n#7 /var/www/fog/management/index.php(58): FOGPageManager->render()\n#8 {main}\n thrown in /var/www/fog/lib/fog/snapin.class.php on line 392’, referer: http://x.x.x.x/fog/management/index.php?node=host&sub=list.

Since this was a migration from an old server to a new and Fog V1.5.9 to Fog 1.5.10 I followed the instructions located here - https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG and then completed the steps in the “If old server was FOG 1.3.0+” section.

I had an old fog server running Ubuntu 18.04 with Fog 1.5.9. I am migrating to a new fog server Hyper-V VM on a Windows 2022 server. The Hyper-V VM is a Gen 2 running Ubuntu 22.04.2 LTS with Fog 1.5.10. I followed online documentation regarding migrating from one server to another. The OS install on the new VM went fine as well as the Ubuntu install. The Fog SQL DB migrated over as well as all of the image files. I followed the steps to copy the SSL folder from one server to the other so that the snapins and current Fog client control would still function. I can access the web GUI and can see all of my images and hosts. The problem is that when I list all hosts everything looks correct but when click on a host the page displays in a sort of “text” looking layout. I have attached an image of what it looks like.
Everything else seems to work as it is supposed to.
When I list all images, I can click on any image definition and the subsequent page renders correctly. The only other thing I can find is regarding Snapins. When I click on the “Snapins” icon the correct page shows. I can click on New Snapin and it will allow me to create the snapin, but if I select “List all snapins” it shows me a “This page isn’t working” message with HTTP error 500. Obviously, I have done something correctly.
Hopefully, I have given you enough info to point me in the right direction to resolve.
Thanks in advance!

OK. Will do. Thanks!

I am running Fog 1.4.0 with client 0.11.12 and imaging Win10 64 bit V1709.
When re-imaging a computer that already was on the domain, the log file says “hostnamechanger unknown return code: 2224” and will not add it back into the domain. When I go into AD and remove the computer account, it will add back to the domain with no issues.
What should I do to correct? I don’t want to have to remove computer names each time I re-image.

@Tom-Elliott The issue has been resolved. I downloaded 1.4.0 SVN6069 and that install worked.

@Tom-Elliott I have a rule on the filter that ensures that the content filter is disabled on the Fog server’s IP address. Also, I have the firewall allow all traffic to the Fog server.

@Tim-Reynolds Did the file attachment shed some light on the problem?

@Tim-Reynolds the attachment is a text file.

@Tom-Elliott Attached is a document with the results of df-h and the install.0_1494274173932_1.4.0-rc9

@Tom-Elliott It unzipped the binaries successfully, it just wouldn’t copy them.

@Tom-Elliott Copying binaries where needed still failed.

@Tom-Elliott I’m still unable to. I can ping Google.

@george1421 I can’t ping, but it resolves it as 162.213.199.177. I can browse to it from Firefox.

@george1421 It does have direct access.

@george1421 I attempted the update to 1.4.0 RC9. The install ran ok until it got to the point where it was trying to copy binaries where needed. Then it failed. Any ideas?

@george1421 I will try that. Thanks!

SERVER FOG Version: 1.3.5
OS: Ubuntu Server 16.04
CLIENT OS: Windows 7 and 10
DESCRIPTION
After update from 1.3.3 to 1.3.5, I can’t deploy my old images I receive following error:
An error has been detected!
No source file passed (writeImage)
Args Passed: /dev/sda1
When you look at the Web UI, it says that the image has 0 bytes. I can see on the server that the image files are there. I looked into the problem and found that most people said it was an FTP permissions issue, so I tried to go through that troubleshooting, but it did not help.
So I decided to image the laptop with a Win10 image even though it wouldn’t match the rest of the lab. When I tried that, I got an error that indicated that the target partition was too small. The image is a single disk resizeable image. I am trying to put it on a 250GB drive. The original drives it was created on were 500GB drives, but that’s all I had for a spare. It does image onto a “Same size” drive with no issues.