Upload Image From HDD 500GB to SSD 120GB

[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 ??

[george1421]

@Gilberto-Ferraz So if you follow Tom’s lead does sudo apt-get install mariadb-server work better.

Secondly, I feel I need to apologies since the upgrade should have worked no problem. I have no idea that ubuntu would break.

[Gilberto Ferraz]

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

when i try to reinstall fog 1.5.7 again give me this error when installing mariadb-client and mariadb-server package.

[george1421]

@Gilberto-Ferraz so again, if you run sudo apt-get install mariadb-server (now that we know the package name) what does apt-get tell you?

[Sebastian Roth]

@Gilberto-Ferraz Too bad I have been away for a couple of hours and did not know the Linux OS you have. If I’d known I would have warned you.

There is a known issue when upgrading to 1.5.7 on Ubuntu!! If you say yes when the installer asks if it should re-install Apache/PHP it will also try to force a migration from mysql to mariadb and fails.

Here are the steps to manually roll back to MySQL that will still have all your FOG information:

sudo -i
mv /var/lib/mysql /var/lib/mysql-mariadb
apt-get remove mariadb-client mariadb-server
cp -a /var/lib/mysql-5.7 /var/lib/mysql
apt-get install mysql-client mysql-server
systemctl start mysql

For more detailed infos read:
https://forums.fogproject.org/topic/13492/fog-1-5-7-update-database-issue
https://forums.fogproject.org/topic/13703/missing-data-after-fog-1-5-7-upgrade
https://forums.fogproject.org/topic/13447/lost-database

[Gilberto Ferraz]

@Sebastian-Roth

Thanks a lot for the help. I’m already weekend. But then I test your solution. I’m glad to hear that the problem was not mine but ubuntu 18.04 You will try to recover the system and install new centos.