Upload Image From HDD 500GB to SSD 120GB

[Adriano Rocha]

@Sebastian-Roth said in Upload Image From HDD 500GB to SSD 120GB:

@Gilberto-Ferraz It’s usually due to the partition layout when FOG cannot deploy an image from a bigger disk to a smaller one. Please post the details of the partition files you find in /images/05_09_2019_si_essa/ on your FOG server. There are three important text files: d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions

Post the contents of all those three files here.

I have this same problem

[Tom Elliott]

@Adriano-Rocha Do you work with with @Gilberto-Ferraz? If you’re having the “same” problem, that means you can’t access your machine either?

I don’t mean to sound smart or anything, but I highly doubt your issue is the same. Similar, sure.

Of note (too all in the thread), is this causing issues with actual imaging. Sorry if I missed this, but the error is very clearly a “Warning”

I’ve seen this too, and although it “failed” with this error, it all seemed to work properly.

I’m still with @Quazz on this one, that the partition ordering is all out of wack at this point.

[Adriano Rocha]

@Tom-Elliott
I posted the wrong comment, I have the same problem loading an image of a 500GB hd on 480 SSD hd.

[Sebastian Roth]

@Adriano-Rocha Those kind of issues are often caused by different partition layout problems. Please open your own topic and post the relevant information requested below (FOG version, d1.partitions, d1.minimum.partitions, d1.fixed_size_partitions)!

@Gilberto-Ferraz Just to get this back on top: We need to have console access to solve problems. Please tell us the Linux OS you are using and we should be able to help you get console login again.

[Gilberto Ferraz]

Hello!
Finally got access to the fog server.
the content of

cat d1.partitions
cat d1.minimum.partitions
cat d1.fixed_size_partitions
of folder
/ images / 05_09_2019_si_essa

It’s

[Sebastian Roth]

@Gilberto-Ferraz Ok, the issue might be caused by that third hidden (type=27) partition on your source disk. It’s more or less preventing FOG from properly resizing your layout to a smaller size disk.

The other things is that your FOG version 1.5.4 is fairly old. There have been a lot of fixes and improvements since then. I am not sure but possibly there was a fix in the resize scripts since then. So my first suggestion would be you upgrade to the latest version (latest release is 1.5.7) and see if it fixes the issue. If not we can take it from there.

[Quazz]

In the current iteration, FOS will always require at least the position of the last partition to be included.

In practice this means that if you have a non-resizable partition (eg recovery) after your Windows partition, then it will always be the full disk size being deployed.

This is because the start position of that partition is near the end of the disk and will be deployed as such (on bigger disks this means it will start near about where it does on the 500GB disk), which means it can’t deploy on smaller disks.

We hope to one day be able to shuffle partitions around and resize regardless, but for now you will have to fix your layout before capture by moving the recovery partition to before the windows partition.

[Gilberto Ferraz]

@Sebastian-Roth Hello, thanks for the help!
I am afraid to upgrade to version 1.5.7 I am afraid of losing access to the images and inventoried hosts.

Do I get all this after the upgrade?

[george1421]

@Quazz said in Upload Image From HDD 500GB to SSD 120GB:

This is because the start position of that partition is near the end of the disk and will be deployed as such (on bigger disks this means it will start near about where it does on the 500GB disk), which means it can’t deploy on smaller disks.

Warning personal opinion here: If the target system will remain in the FOG environment after deployment (i.e. not created by a system reseller so that once its loaded you will never see it again). I would really have to ask the value of having a recovery partition at all. If this system is in a business environment who would waste the time restoring the system back using windows recovery vs just blasting a new image onto the target computer from FOG? I can tell you from experience if a system is damaged as much to need the recovery partition, the nuke and pave method is faster (assuming you can afford to loose all of the data on the disk). In my environment when we setup a new task sequence in MDT we always remove the recovery partition and make the drive fill the remaining space in the disk. That way the (or drive if needed) is always the last partition on the disk. This process may not fit your environment, but it works well for us.

[george1421]

@Gilberto-Ferraz said in Upload Image From HDD 500GB to SSD 120GB:

@Sebastian-Roth Hello, thanks for the help!
I am afraid to upgrade to version 1.5.7 I am afraid of losing access to the images and inventoried hosts.

Do I get all this after the upgrade?

Unless you do something really bad, upgrading will only extend the sql database schema and not replace any of its contents. So upgrading will not loose any data or images on your fog server. The upgrade process does not touch anything in your /images directory either. While anything is possible historically we have not seen any such loss. If you are at all concerned make sure you have a backup or snapshot of the FOG server so you can restore it.

[Gilberto Ferraz]

@george1421 hello!
I upgraded to fog 1.5.7 on my ubuntu 18.08.3 LTS.

Now I have problems with Maria DB “Database connection unavailable”

could you help me?

[george1421]

@Gilberto-Ferraz Well, that isn’t what I wanted to hear. We had another thread just a few days ago where the mssql server went away.

Lets start with

sudo systemctl restart mariadb

If no luck then lets see whats the status is

sudo systemctl status maridb

[Gilberto Ferraz]

@george1421 said in Upload Image From HDD 500GB to SSD 120GB:

sudo systemctl status maridb

bart2018@bart2018fog:~$ sudo systemctl restart mariadb
Failed to restart mariadb.service: Unit mariadb.service not found.
bart2018@bart2018fog:~$ sudo systemctl status maridb
Unit maridb.service could not be found.
bart2018@bart2018fog:~$

is that mariadb is no longer on my server

[george1421]

@Gilberto-Ferraz I’m not a ubuntu admin but what does sudo apt-get install mariadb give you?

@Developers would the fog 1.5.7 log list if the database was uninstalled for any reason?

[Gilberto Ferraz]

@george1421 I can’t even install it I’m using OS ubuntu 18.08.3 LTS.

[george1421]

@Gilberto-Ferraz then try sudo apt-get install mysql

I do find it very strange that the database service would be installed by the fog installer. Something unexpected must be going on with ubuntu.

[Gilberto Ferraz]

@george1421 It is very strange I do not know what happened also does not let install mysql. I try to install version 1.5.7 again?

[Tom Elliott]

@george1421 What OS is this being installed from?

I’m fairly sure 18.04 and newer have mariadb available.

[Tom Elliott]

On Ubuntu 18.04 it’s mariadb-server I think

[Gilberto Ferraz]

@Tom-Elliott I thought so too, but the update turned out not to work well I try to install fog 1.5.7 again ??