Posts made by Julianh

Thanks Sebastian, that’s great. How do I backup the database? and restore it?

Thanks

Julian

Hi Sebasrtian

It’s not really a fog issue, it the expansion of the raid array that requires it wiping. I have a mega raid 9341-8i hardware raid array. I’ve just run out of space,

I’ll be installing Ubuntu 20.

Thanks

Julian

Hi All,

I use Fog in my training rooms to re image the student servers. The images are updated once every 6 months if that, but it deploys them on a Friday night.

I’ve decided to wipe and re install Fog from my old version 1.5.0 to the new 1.5.9. I need to add a new drive to the array which requires a rebuild of the array.
I have about 20 images I’m going to copy to both an internal disk and USB disk. It’ll take a week I think. Then copy back and recreate the images pointing to the restored files
Then I’m going to reinstall the OS and Fog. That’s the plan.

I thought I’d ask about any gotchas before I hit them.

I have a dedicated box which is running Fog I borrowed from a lab, 32GB 4 Core SSD array, which will be fine, but the OS is updating to ubuntu 20. Nothing else will change. I have 2 types of images, Windows and VMware, and I’ve put the details below.

Is there anything I should be aware of?

Thanks

Julian

Er sorry for creating so much trouble.

Thanks Sebastian. I’m not good with databases though. Will these commands wipe the image side of the database? I’m not bothered. I can happily recreate the images, as the files will still be there.
Thanks
Julian

I had another look at it in the light of day. I redeployed the images to the rest of the servers and what a mess. Servers were deploying on the wrong physical boxes. It’s VMware and the UUID of the hard disks need to match or it gets awfully upset.

So the images seem to have their references to the image locations wrong. I then changed an images location and saved it, then changed it back again and saved it, nope that didn’t work. I then created a new image, moved the original image elsewhere, and pointed the new image to the correct file location, and it works.

So the database seems stuffed. The fog server is crutial, I’ve put it on a fast box with a SSD raid array and don’t want this again, so I’m going to image down the servers, rebuild the fog server and image it up.

I’m going to screen shot the image details. I’ll use unbuntu 18 and the latest fog. I’ll take the details of the images Is there anything I need to be aware of before I do this?
Thanks

Thanks I didn’t realise that. Much appreciated.

It would be nice if I could be emailed to let me know that an image, or group of images had successfully deployed or finished deploying.
There are services that allow you to subscribe to a number of SMS notifications, all you need to do is send them a set of parameters, so I could get a text telling me they’d finished deploying.

Just a thought

I rebuilt my training room last week and imaged it up. Fog version: 1.5.0. There are 11 machines. on 4 of them everything’s ok, but one doesn’t have an image but works, details below, and the remaining ones give me the following error. A screen shot is here.

https://www.dropbox.com/s/06wf9g22cxaslrs/IMG_3596.JPG?dl=0

There are 11 images in my room. Servers 0-11. Server 9 doesn’t exist. If I look in the /images directory I see Server0-8 and 10-11. BUT not server 1, but there is an image in the /images/dev directory with the same MAC as server1, so this is the temporary one that is copied over. If that didn’t happen then it probably ran out of disk space, but I deleted all the server images from /images before I started the upload. I’ve checked the images directory, and there’s space here’s the details https://www.dropbox.com/s/d0jnxw7b7q0dn92/IMG_3598.JPG?dl=0

I think the database is corrupted.

Fog has worked brilliantly for me, and I’ve become totally dependent on it. I have to get this working this week or I’m in a real mess.

can anyone help me? Pleeese

Julian

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

Excellent Sebastian, it was the Gzip format I missed. All working now.

I’m going to make changes to the images and image them up, what format would you recommend for the image. it’s server 2012 r2. 1 drive

Thanks

Julian

Hi Sebastian,
The old fog server has been reused, so I can’t get any settings off it

Here’s the result of the command you wanted.
https://www.dropbox.com/s/hhy4tw5p4gqyu7r/IMG_3285.JPG?dl=0

I always thought the operating system section was almost irrelevant, but I’ll set it to windows 7.

Thanks for your help, it’s much appreciated.

Hi Sebastian,

I had an old 1.20 fog server that was too slow in imaging the 12 clients it had, it’s used for a training room, it took 6 hours, they were big images, each one different. Anyway I upgraded to a fast network and SSD drive arrays. that was about a year or so ago, I checked and it says

You are currently running version: 1.5.0

Latest stable version is 1.5.5

Latest svn version is 6078

Latest git version is 1.5.5

I set the image to Single disk, multiple images, and got a slightly different error, which is here

https://www.dropbox.com/s/8hzkcxd0mve42v4/IMG_3281.JPG?dl=0

What’s strange is the directory it relates to. it refers to the images directory, when the image is in the /images2 directory. but I’ve checked the image it definatley refers to the /images2 directory

I think this is the problem, does anyone know how to make it look at images2? did the image files of 1.20 reference the file location, could it have brought this over?

Thanks

For once I have a fog problem that I have a bit of time to fix, a week Just a bit of a pity I have the problem

I had a fog 1.20 server that I replaced with new hardware, but I moved one of the disks from it to my new fog 1.50 server, as it had image files on it I wanted to keep. I need to add the images back in. No problem I thought, just add a new image and point to the original images. However it’s failing with a rather unusual error as you can see from the following. What’s weird is the files are in the /images2 folder, I did copy them to the /images folder too, but it still failed.

I have 10 images like this to restore.

Does anyone have any suggestions I could try

Thank you

Screen shots;
https://www.dropbox.com/sh/3hhup1uj6byllkm/AACrVaz_r9Qa-JPpAbH9dKqVa?dl=0

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;

What would you suggest?

A thought, could I have somehow set up the 2 disks are storage nodes reaplicating between themselves?

I’ve had a look but can;t find the option, any suggestions?

Thanks

Julian

I have a fog 1.50 server. It’s been fine, as I’ve just been using it to deploy one set of images. I have a SSD Array for the boot device, and /images.

I found I needed a bit more storage for some odd servers I needed, which could be a slow deployment, so I added a 5TB SATA drive as /images2.

I had to rebuild the images in /images , they are 103 GB in size on the disk, 447GB on the client. They are raw, single disk images.

The problem is I seem to be getting versions of the images on /images in /images2 here’s a copy from putty

image@fog:/images$ ls
dev                Linux-KM-Server5     Server3-VMware6.5
images2-5TB        Linux-KM-Server6     Server4-VMware6.5
Linux-KM-Server0   Linux-KM-Server7     Server5-VMware6.5
Linux-KM-Server1   Linux-KM-Server8     Server6-VMware6.5
Linux-KM-Server10  lost+found           Server7-VMware6.5
Linux-KM-Server11  postdownloadscripts  Server8-VMware6.5
Linux-KM-Server2   Server0-VMware6.5    Temp-S10-Waitingforspace
Linux-KM-Server3   Server10-VMware6.5   Temp-S11
Linux-KM-Server4   Server2-VMware6.5    vRoom1-ESXi-Guacamole

image@fog:/images$ ls /images2
backup-copy        Linux-KM-Server5     Server2-VMware6.5
dev                Linux-KM-Server6     Server3-VMware6.5
images2-5TB        Linux-KM-Server7     Server4-VMware6.5
Linux-KM-Server0   Linux-KM-Server8     Server5-VMware6.5
Linux-KM-Server1   lost+found           Server6-VMware6.5
Linux-KM-Server10  postdownloadscripts  Server7-VMware6.5
Linux-KM-Server11  Server0-VMware6.5    Server8-VMware6.5
Linux-KM-Server2   Server10-VMware6.5   Temp-S10-Waitingforspace
Linux-KM-Server3   Server11-VMware6.5   Temp-S11
Linux-KM-Server4   Server1-VMware6.5    vRoom1-ESXi-Guacamole
image@fog:/images$

The actual directories contain the following;

image@fog:/images$ ls -l Server0-VMware6.5/
total 100958896
-rwxrwxrwx 1 root root 103381871523 Jun  6 21:04 Server0-VMware6.5.000

image@fog:/images$ ls -l /images2/Server0-VMware6.5/
total 1421388
-rw-r--r-- 1 fog root 1455495892 Mar 21 20:00 Server0-VMware6.5.000
image@fog:/images$

Can anyone guide me as to what’s happening, and what I can delete. I don’t have enough space left to actually image up the servers.

Thanks

Julian

I had this problem this morning and wanted to put it up here so it could be found in a search by someone else having the same issue.

I set a load of imaging going late last night, came in this morning and couldn’t login to the fog server. It came up with the initialise schema screen you get on install.

I checked the SQL service, and got this

xxxx@fog:~$ systemctl status mysql.service
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: en
Active: activating (start-post) (Result: exit-code) since Wed 2018-05-16 08:0
Process: 3696 ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE)
Process: 3688 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exit
Main PID: 3696 (code=exited, status=1/FAILURE); : 3697 (mysql-systemd-s
Tasks: 2
Memory: 336.0K
CPU: 319ms
CGroup: /system.slice/mysql.service
└─control
├─3697 /bin/bash /usr/share/mysql/mysql-systemd-start post
└─3904 sleep 1

SQL wasn’t loading. A bit of Google, and I checked disk capacity and the disk was full.
I have a SSD array and wanted the OS protected as well as the images, hence why they are on the same disk.
All I did was to delete an image, releasing space, reboot the server, and all’s well.

If you have this, I hop this helps. Please mark this as solved

Julian

How do I mark this as fixed?

Thank you Wayne for such a detailed reply. I think I’ll have to leave it “as is” as 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.

What would be nice, for a future development would be a backup and restore option. Both with and without images. Mind you that wouldn’t be an easy 5 minute job, but I suspect it would reduce a lot of support instances, the majority of problems could be avoided.

Would that be possible?