@Julianh Please read through the whole wiki page and you’ll find the section on exporting the DB.

@Sebastian-Roth sorry it took so long, but I finally was able to create a separate thread in bug reports. https://forums.fogproject.org/topic/13486/fog-1-5-6-pushbullet-plugin-not-functioning

We are in the midst of reassembling classroom tech after the custodians did their cleaning so that is what caused the delay.

@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.

Thanks Sebastian,

The fog server ia a quad core 3.4GHZ with 32GB ram and uses a 4 TB sata drive to store these images on. It’s normal images are stored on a SSD array, its just because these aren’t used that often that they’re stored on a sata.

The clients are all 32GB 4/6 Cores @3.4 GHZ, single SSD disk with a dedicated 1 GB network.

The machines are usually used for just their PC’s image in the training room.

Any suggestions?

Thanks

Thanks George,
df -h gives

image@fog:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.4G 0 7.4G 0% /dev tmpfs 1.5G 8.9M 1.5G 1% /run /dev/mapper/fog--vg-root 1.9T 1.8T 39G 98% / tmpfs 7.4G 0 7.4G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup /dev/sda1 472M 58M 390M 13% /boot /dev/sdb1 4.6T 3.8T 549G 88% /images2 tmpfs 1.5G 0 1.5G 0% /run/user/1000

As you can see there’s not a lot of space left on the first drive.
I’ll be using th eimages for the next 3 weeks, even if they are not ideal, so I son’t want to create a new storage group in case I lose the images. the storage groups are;

0_1528474518141_Storage nodes.jpg 0_1528474532470_storage group.jpg

What would you suggest?

@julianh said in Ubuntu upgrade to 16.04.4 LTS kills Fog:

I have a dedicated fog Server that was somewhat expensive with its SSD arrays, so I can’t migrate to a new box, I can’t afford it.

You could migrate to a VM first - then from the VM back to the nice hardware. Keep the VM as a spare - but first use the VM and ensure everything is correct and working - and imaging.

@julianh said in Running out of Space during Imaging:

can I redirect the /images/dev to another disk?

Yes, you can do that. But there are some other questions to ask to figure out why you are having these problems and if there are any obvious quick wins we can help you with:

What is the output of df -h Output of lsblk Is this in a VM or a physical machine? Do you have more than one spare disk you can use for the FOG Server?

@Julianh I am sorry to say that but your setup is quiet complex with so many disks mounted in various locations and I don’t think we’ll be able to reliably guide you through a migration here in the forums. I am not sure what to advice. As Wayne said, 1.4.4 can deploy 1.2 images. So unmounting and moving the disks to the new system should work.

@wayne-workman That should be it

IP address The name of the new card as known by linux.

Fix the .fogsettings file and rerun the installer.

I might just look at the webgui in the fog configuration as well as the storage node settings for this fog server to ensure the name of the network interface matches what is now defined in linux.

it’s all about network througput and storage fastness comparing to the network speed 😉
would be interesting to see the deployment speed with a native 10gbit lan and ssd raid for storage 😛 …and sure the client should have ssd too.

But i can tell you 1gbit lan and hdd in the storage node can easily deploy a 16gb image within 2 minutes to a system with ssd 😉 i see it daily happen again and again hehe

Thanks for all the advice, I appreciate it. I’m going to go with a raid 5, 5 drive SSD array in my new fog Server, a few sata drives and some time looking at the scripts to implement HSM

Have a good day as they say

Yours

Julian

Areca cards work well in both environments, they are all pretty universal. I’ve used quite few different models in both OS’s (DebianLinux and Windows) . Debian has support built as modules (arcmsr) into the kernel out of the box, and those modules are also by default in the initrd. I’m not sure what the FOG kernel/initrd are based on, but I would imagine it couldn’t be too hard to add if needed.

I can attest they are fast cards, and fully support 4k sectors and 64bit LBA, as well as some SSD specific options.

One thing to be aware of - most OS’s aren’t aware of TRIM support for RAID drives. Some controllers expose emulated TRIM and convert it to drive level TRIM, but that is rare. Consequently, SSD’s will wear out rather quickly in a RAID array with a lot of writes.

@Julianh It’s also worth noting that the remaining two didn’t need turned off. They would have began imaging when a slot opened. I limit my FOG server’s maximum connections to 2, and I image 50 to 60 computers at once. 2 go, the rest wait in line.

@Arrowhead-IT said in Quick Question re Changing Fog 1.2 IP address:

I think that if you just change the ip in the fog settings it might just take care of the rest for you.

This is true for a new install. For existing though, the IPs in the DB are not touched. This is by design.

@Junkhacker
Well this was the interesting bit, it was all physical, the MACs imaged up were those of the physical adapters, but Hyper-v was “moving” the physical MACs to it’s internal network cards, and then of course imaging the software MACs up. Interesting, a pain but quite interesting.

@Julianh

Depending on your comfort level - you can make a copy of the image manually, and then manipulate the copy, and create an image definition to match.

for example, lets say I have /images/MyAwesomeWin7Image

I could copy it like this:
cp -R /images/MyAwesomeWin7Image /images/CopyOfMyAwesomeWin7Image

Then I could work with just the copy, and delete the disk 2 partitions like this:
rm -f /images/CopyOfMyAwesomeWin7Image/d2.mbr
rm -f /images/CopyOfMyAwesomeWin7Image/d2p1.img

Then, in the web interface I would go to “create new image” and put the image name and image path as CopyOfMyAwesomeWin7Image and select “Single Disk Multiple partition non-resizable” as the image type.

And then just assign that image to a host and try it out…

But if you’re using FOG 1.2.0, it does not work with totally blank HDDs. However FOG Trunk can handle blank HDDs - but it is developmental. I use FOG Trunk in production, others do to. You simply need to understand there will be bugs that you won’t expect, and when you find those, just report them here in the bugs section, the developers are really good at fixing bugs.

@Julianh WOW! Not something I’d have ever come up with. Thanks a lot for reporting back. I am really glad that we don’t need any kind of special kernel patch to make this work.

@Julianh If you’re running SVN builds, I’d actually recommend starting by deleting the backups.

I generate a backup of your GUI layout, now, for Every version of FOG you’re attempting to install.

This can eat up quite a bit of space as one can imagine.

I’d recommend (before allowing resources to eat up the 5% for system files and such) clean up the backup location.

Most layouts have a separate layout for /, /home, /var, and maybe others, but some installs use the / only setup.

Check in the /home (unless you changed the backup path for the installer) and look at how many folders of .BACKUP you have.

My guess is this is what’s eating up your space.

While, yes the backups do eat space and it is quite intentional, the backups may not be needed, I find it safer to have and not need, than need and not have. I use the backup folder/file now to ensure any “extra” data you store in the gui folder (for say ISO’s or alternative kernel files etc…).

I would also say its the physical disk based on what you have posted. I have experienced a bad sector on a hard drive cause ghost and clonezilla to fail. I have not yet experienced this with FOG (just because with the other I’ve deployed units in the 1000s).

I would ask 2 questions here.

What is the hardware you are deploying to (ie Lenovo M93, Optiplex 9010, etc) Have you physically replaced the hard drive in this system. (I noted that you mentioned hard drives . Do you have more than one in this system?