HOW to upgrade from trunk SVN 5850 to 1.4.0 stable?
-
@Quazz
Hmmm nice idea I don’t have try to recreate the definitions of imported images.
I will testing it.For the error I had no time to read it sorry if I have time, I’m going to recreate the same process and capture the moment with my phone.
Thinks you for help me
[EDIT]:
Sorry I just have understand your question about the error.the error is not about the database, is about image deployement.
I can start deployement to client computer but at the end of the process I have an partclone error and the computer reboot corrupted -
@EagleEnergy Yes, but at the end of deployment FOG contacts the database, when this fails it will mention such.
At any rate, since the error is partclone related, can we get the specific error? The answer will vary depending on it.
Additionally, if you could share the settings for the image you’re trying to deploy (the image definition settings)
FOG has added new options for the image manager, it’s possible that this is causing issues for you (I seem to recall someone else having issues having with it, too).
-
@Quazz said in HOW to upgrade from trunk SVN 5850 to 1.4.0 stable?:
FOG has added new options for the image manager, it’s possible that this is causing issues for you (I seem to recall someone else having issues having with it, too).
This is what I think also because fields of settings between my version (8450) and the 1.4.0
-
@EagleEnergy said in HOW to upgrade from trunk SVN 5850 to 1.4.0 stable?:
The first is the database transfert, when i import the old database and go back to the web interface of fog, I have the database install page. Because I can directly see when I navigate in the interface, the trunk database and the 1.4.0 database are very different.
That’s intended. When we import an older database, FOG can upgrade it to the current schema version. There should be a big fat button center-screen that says update database or something similar.
-
@Quazz said in HOW to upgrade from trunk SVN 5850 to 1.4.0 stable?:
At any rate, since the error is partclone related, can we get the specific error? The answer will vary depending on it.
This postinitscript packages everything in /var/log of FOS and sends it to a windows share (and other cool stuff): https://github.com/FOGProject/fog-community-scripts/blob/master/fogAutomatedTesting/postinit.sh
Works whether image deployment pukes on itself or not. This would include the full partclone log and /var/log/messages and other things.
-
Thanks you guys. I will trying yours solutions at Monday.
I have tried before to recreate one image but not the time to test to deploy it.
@Wayne-Workman : Think you for the script.
@Quazz: I will finish the test of your solution.
I will reporting to you guys news about yours propositions.
Thanks you
-
Hello guys !
So this what I had do today:
1st: I have reinstall a new clean 1.4.0 FOG server
2nd: I have upload 3 images directory, “dev” directory and the “postdownloadscripts” directory from the old server to the new in /images where I have replaced de two “dev” and “postdownloadscripts” directorys.
3dr: I have import the host_export.csv from the old server to the newest.
4th: I have recreated the 3 images in the new server (3 windows 7 with multipartions single disk option).
5th: I have test to deploy the 3 images with 3 différente way off partclone.
the first image was deployed with partclone gzip option.
the second image was deployed with partclone zstd option
and the third image was deployed with partclone uncompressed option.6th: For the partclone gzip and zstd I had an error at the end of deployement.
For the partclone uncompressed, the deployement doesn’t start.@Wayne-Workman I doesn’t had the time to test your script, maybe tomorrow.
This the exemple of error for partclone gzip and zstd:
![alt text]( image url)
On the old server I just know image are created with partclone but there are no options In this version of FOG.
-
Can you try again with image type of Single Disk Multiple Partition ?
And just to verify, you do recapture the image after changing the image settings, correct?
The partclone log would be very useful though, so hopefully you can provide this tomorrow.
-
@Quazz “4th: I have recreated the 3 images in the new server (3 windows 7 with multipartions single disk option).”
I have use the Single Disk Multiple Partition for the 3 images because there are W7
So no I don’t recapture the image after changing settings because the idea is the backup the images from the old server to the newest. (The images work perfectly with the old server)
Tomorrow I upload the partclone log
Thanks again for help
-
@EagleEnergy said in HOW to upgrade from trunk SVN 5850 to 1.4.0 stable?:
So no I don’t recapture the image after changing settings
If you change the image’s settings, you must re-capture that image.
-
@Wayne-Workman Ho OK. The once solution is to deploy an image with old server And recapture him with the New ?
And just in case off, in the future if I want to migrate images from a 1.4.0 server to an other 1.4.0, the process is the same or just moving images with ftp for exemple ?
-
@EagleEnergy The process is the same, but we do have a guide here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
The image only needs recaptured if the settings change. If you keep the same settings the old server had, you don’t need to re-capture.
-
@Wayne-Workman This is the problem I don’t found the same settings of the old server.
On the version of my old server I don’t have the choice between differents type of partclone or partimage. It’s just said the image was created with partclone but I don’t know what is the same option in 1.4.0 version
This is the capture from the old server
-
@EagleEnergy I don’t know when FOG started using partclone, but somewhere around 1.0 and lower used partimage with pigz compression. between 1.2 and 1.3 gzip was adopted. Somewhere between 1.3 and 1.4 zstd was adopted. When importing those old images, you’d just have to choose those settings.
-
@Wayne-Workman Thanks you for the clarifycation, I think I’m between 1.2 and 1.3 so the good option is partclone Gzip.
Here I redeploy an image with this option but an error appears again at the end of deployement (I expected that).
So now i’m trying to use you’r postinit.sh scripts to analyse the problem, but the scripts can’t work because he doesn’t found the funcs.sh file in /usr/share/fog/lib directory.
I don’t know if it’s because I use fedora but I don’t have /usr/share/fog directory in my server.
-
@EagleEnergy We need you to move to the latest stable fog release 1.4. I’m fairly certain the issue you have with zstd is already fixed in 1.4.
sudo -i dnf -y update dnf -y install git git clone https://github.com/FOGProject/fogproject.git cd fogproject/bin ./installfog.sh -y
-
@Wayne-Workman a couple minor corrections. the last official release to capture using partimage was 0.32, i think. images have always been gzip compressed. between 1.2 and 1.3 the program for decompressing was switched to pigz. pigz is a parallel (multi-threading) implementation of gzip compression, which sped it up a bit.
-
@Junkhacker pigz !! this the error I had when I’m trying to deploy with Gzip otpion on the 1.4.0.
Thanks for this precision
@Wayne Workman
I have tried many solution to import my images from the old server to a new in 1.4.0 but nothing working.
I think the one solution is two deploy each image from the old server to a master and capture this image with the new serveur.
So I have testing this way it’s working.
Next just in case off I have created an other 1.4.0 server (yes 3 servers in the story) to test a migration between the two 1.4.0 servers with this process : https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG. All work fine.
Even if this was not the aim methode I serched to migrate my old images to the new, I think we can close this topic ?
Thanks all for help it’s very nice.