@mckay You are welcome. This is what the forum is all about! 🙂

Happy new year!

sorry, I didn’t. but I think you can easily recreate this by following your instructions and immediately after the upgrade is finished try to capture a machine.

For bios based computers you would use undionly.kpxe as the default bootloader. For uefi based systems the boot file is ipxe.efi. The next server or boot server value should be the IP address of your fog server.

@Gamienator Sorry, just didn’t get to take a closer look at this up until today. I think you’ve done a pretty good job considering this is your first time using PHP!

Thinking more about the scenario you have I was wondering if there is a more apropriate way to do this. I don’t understand why you’d want to have users (I suppose you mean admins) start the transfers manually. What I mean is: Someone needs to have image X on FOG server in location Y and so he opens your special website, selects image, clicks send and needs to wait for it to finish before a host can be deployed at location Y. But why is this interaction needed at all I wonder? If I’d be you I’d try to have it all automated as much as possible.

One way would be to just replicate all images to the servers in all locations. Though images might not be needed and it would therefore waste a lot of bandwith to transfer the huge images to locations where they might not be used at all. So I thought about miss-using FOG’s concept of storage groups could be useful for you. Define a storage group for every location you have. Then edit the image settings -> tab “Storage Group” and assign the location/storage group where you want the image to be used. I’d suggest you leave the pre defined “default” Storage Group as is for every image but only add the new “location storage groups” as needed.

Now combine the stuff you’ve come up with already with the settings I mention above: Create a cronjob on your main server that will query the the “Storage Group” information of every image from the database and do the replication to the other servers automatically based on this information. So when people create a new image definition and add the correct “Storage Group” to it the image will be automatically replicated as soon as the image is being captured.

This is all about the raw image data replication. Now for the database there are two scenarios I can imagine. One would be to use MySQL’s capability of replicating (syncing) databases automatically. One of our users just wrote a tutorial on this topic. I’d suggest to not replicate all tables but only sync the images table by using replication filter rules.

The other option is to add a simple mysqldump through SSH tunnel command that grabs all the information from the images table and push it to the other server’s database. It would be wise to also base this on the “Storage Group” information described above so you’d only have the image defintions needed in all the locations.

That’s just my point of view. See what you think and let me know if you need help with this.

@greichelt On your fog server itself, there is a config file /etc/resolv.conf that file should list your name servers (DNS servers) used for the fog server to do name lookups. A quick google-fu will show you the parameters needed for that file. Typically on ubuntu that file is managed by the network manager application. Just be aware of that because it may overwrite any settings you add. For the network manager application that is typically an application on the tool tray that deals with network configuration (sorry I’m a rhel guy, so I can’t give exact instructions for ubuntu).

@weite Start here: https://forums.fogproject.org/post/129262

@george1421
The only reason I can see it continuing to work is because microsoft isn’t primarily a hardware company. They need their OS to be available on many different standard x86_64 hardware. Now if they stop selling OEM installers and only using somesort of pre-baked internet recovery I would be more nervous.

@Sebastian-Roth said in All disk capture unable to deployed to two larger disks:

The old patch was removed some time ago (ref) and I guess this was a hickup in your build environment.

Yes I found out a bit after that post, I just over laid the new files over the existing path because I’m building the inits using a different method than the build script. Sorry that was my mistake.

@Sebastian-Roth So, in the end, I have entirely switched to a bridged network solution, and everything is working fine now. It seems that the problem was, in fact, as you mentioned, about the issue in the installer script with network adapter enumeration. But that also means it is some type of bug - all captures of an image were successful, only failed at the very end trying to update the database.

The difference that I noticed between bridged and internal NAT configuration is that in the latter one, the FOG installer script at the very beginning complains that net-tools is not installed. When it asked about the network adapters, it couldn’t get an IP at first because it tried to use a network adapter enp0s3 enp0s8 (NAT adapter for internet connection and internal NAT adapter), at which point I had to specify to use enp0s8 adapter manually.

@UWPVIOLATOR Did you get to test the script?

Meanwhile we have released a new version of the fog-client which should print out a text instead of the hash when it catches the unhandled exception.

Either you can update to the latest dev-branch version to get the new fog-client or you can switch over manually: Download SmartInstaller and MSI and put those in /var/www/html/fog/client/ (rename the old binaries to be sure you have a backup copy in case). Then edit /var/www/html/fog/lib/fog/system.class.php and change the line where you see the client version from 0.11.16 to 0.11.17. Be aware that all your hosts with running fog-client will download the SmartInstaller from your FOG server and attempt to auto update!

@jhumpf We need more information to be able to help!

@mikmatcr Did you get your disk setup or do you still need help with this?

good call, I will talk better with the MS people.

Cheers!

Good holidays!

@Sebastian-Roth

Ohh thank you ! It works now ! 🙂

I didn’t know if I had to log on and then reboot manually to join the domain.

I noticed that I have to wait 3-4 minutes after the first boot for the automatically reboot and then the PC is in the domain !

Thanks a lot for the help, the problem is now solved !

@Sebastian-Roth the installer will not run without internet connectivity. It hangs on the line adding repository, I think. I’ve left it for 30 minutes with no change.

This behavior is new, because I’ve always deleted the .fogsettings file and rerun the installer to change the ip.

Outside the settings in the web ui I had to manually change the ip set in the tftpboot folder.

@dinagaran7007 Please open a new topic and post all your details there: FOG version, install error log, …

@Sebastian-Roth There were still some duplicated MACs on my network removed then from the database and it worked, this issue was caused by myself, there were some pending macs to aprove and I didn’t paid attention to then and approved then all, but lots of them were from Virtual machines.

@IdahoTech said in Updated Ubuntu and now cannot get to fog gui:

So let me ask this to all who answered do you have a password on your sql? Seems to be a problem with ‘no password’ mysql installations…

Just as an FYI, this issue is being addressed in the soon to be released FOG version 1.5.8. In 1.5.8 there will be tighter controls on the database side. The downside is that the FOG admin will need to remember the root password for mysql since it won’t be recorded anywhere in FOG. FOG shouldn’t need the root user’s password for mysql except the first time FOG is installed, it need’s root’s password to setup the FOG database. After that there is a foguser created that interacts with the FOG database even during upgrades.

@FuriousGamer065 You probably should run through the tutorial to ensure that all of the bits are in the right spot and then rerun the fog installer.

Understand this will only address the ftp issue. There still may be the issue related to unable to find the storage node. That’s on the NFS site of the image upload.