Please point me to 1.2.0 -> 1.3.4 for Centos 6.7 upgrade docs/guide.

[BardWood]

@Tom-Elliott

Optiplex 7010
Image path: /images/O7010V3
Contents of d1.original.partitions:
/dev/sda1 : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2 : start= 206848, size=976566320, Id= 7
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0

Lenovo X1 (non-carbon, AKA ‘Gen1’)
Image path: /images/X1NCV2
Contents of d1.original.partitions:
/dev/sda1 : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2 : start= 206848, size=312374960, Id= 7
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0

Lenovo X1 Carbon (NVMe/AKA ‘Gen5’)
Image path: /images/X1CG4V3
Contents of d1.original.partitions:
/dev/sda1 : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2 : start= 206848, size=499911344, Id= 7
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0

[Tom Elliott]

@BardWood I’m rebuilding init’s that I hope might help you out with this. I’ll let you know when it’s ready if you’d be so kind as to see if your images will work after this?

[Tom Elliott]

Init’s are up at:

http://mastacontrola.com/init.xz
http://mastacontrola.com/init_32.xz

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

[BardWood]

@Tom-Elliott No luck. Fails the same way when trying to recreate the main partition at init. This was on the ‘Gen1’. I’ll try a couple others.

[Wayne Workman]

@BardWood I know this thread has gone a little off topic and is now all about getting the old images to work with fog 1.3.x, however - After Tom assists with getting the old images working correctly (this has to be done no matter what), you could migrate to a newer OS using this guide: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
That guide is Linux Distribution Agnostic.

[Tom Elliott]

@BardWood I see and I think I see why too.

Essentially, if you’re wondering, because you have the d1.original.partitions file, I’m trying to get it to stop trying to use the parted command at all to build your layout. If this doesn’t exist, it should still fall back to the parted layout.

I just had a bad file checker element and I’m hoping it’s fixed now.

If you don’t mind redoing the download (from the same point) and retry again? I know I’m having you try many things, but it’s all to try to get your images back to an operational state.

[BardWood]

@Wayne-Workman Actually, it’s about getting any images to work. I can’t record new images either. I definitely want to upgrade CentOS at some point. I do have VMWare. Perhaps on the side I’ll start building a CentOS 7 server. I did have an early beta of 1.3 working on CentOS 7. The master worked great but wasn’t having luck with the storage nodes so I wiped it out. In fact, I’m going to do this tomorrow. Our imaging system has been down for a week but I could really use some of the features in 1.3.

[Tom Elliott]

@BardWood What do you mean you haven’t been able to capture? Is it because you want to deploy the image to a system first, then capture, or are you having issues capturing altogether?

[BardWood]

@Tom-Elliott Didn’t work but I did get a different message:

[Tom Elliott]

@BardWood Building another new set, just waiting for them to complete their compression cycles.

I’ll let you know, and again thanks for all the help so far.

[Tom Elliott]

Updated init’s are up again.

[BardWood]

@Tom-Elliott When I wrote this, I had only tried to capture once, many RCs ago. I just tried again and it did work. I love the new status bar in the web interface showing progress, size, and estimated task time.

[Tom Elliott]

@BardWood Progress isn’t new, persay, I just have it always showing now.

[Tom Elliott]

Any luck on the deploy?

[BardWood]

@Tom-Elliott No. Also, yes. Initiating ‘Plan B’.

I still had the CentOS 7 VM from a prior BETA of 1.3 so I dusted it off and installed 1.3.5. Did some tests with new images (just a junk, non-prepped image) and that worked. So please tell me how feasible this is:

I currently have 2 FOG servers on CentOS 6.7 and 7.3. I want to keep the 7.3 but it has no (real) images.

I’d like to roll the 6.7 back to 1.2.0, write the images to like hardware, re-direct clients to 7.3 and do fresh captures. The images themselves could use an update so if I can’t roll back to 1.2.0 it’s not a huge deal but would save some time. Is it as simple as just running the 1.2.0 install script?

[Tom Elliott]

@BardWood If you still have the original backup file from when you upgraded the server originally, this would be your best bet. It should be in /home/fogDBbackups

It typically is time stamped.

Once you reinstall 1.2.0, you’ll need to use the backup sql file to restore it as a lot changed in the DB between the two.