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

[BardWood]

@Tom-Elliott Results of your suggestions (on Gen5/NVMe):

parted -s /dev/nvmen0 mkpart primary ntfs 206848s – -1s
‘Could not stat device /dev/nvmen0 - No such file or directory’

So I re-ran with a slight syntax change based on lsblk output
Input:
‘parted -s /dev/nvmen0n1 mkpart primary ntfs 206848s – -1s’
Output:
Error: You requested a partition from 106mb to 512gb
(sectors 206848… 1000215215)
The closest location we can manage is 512GB to 512GB (sectors 1000212480… 1000215215.
So, at least parted sees it now. Small victories.

Results of lsblk -dpn (-dpno spit out the help file. -d/-dp/-dpn had similar output. ‘-o’ either on its own or in combo with other switches resulted in help file).

Results of ‘fdisk -l’

[BardWood]

@Tom-Elliott Additional info from Optiplex Desktop:

[Tom Elliott]

@BardWood That message (the it exists is non-issue).

SO now that we know the device name (it’s not /dev/sda)

Try the fog until it fails.

Then when it fails at the prompt try:

parted -s /dev/nvme0n1 mkpart primary ntfs 206848s -- -1s

[BardWood]

@Tom-Elliott Tried that (see below): Output = ‘Error: You requested a partition from 106mb to 512gb (sectors 206848… 1000215215)’

[Tom Elliott]

@BardWood It’s a 512 Gb disk?

[Tom Elliott]

can you try:
parted -s /dev/nvme0n1 mkpart primary ntfs 206848s 100%

[Tom Elliott]

I see what the problem is.

What I don’t understand is what the OS is.

Can you get contents of ls /images/<relevantimagehere>?

[BardWood]

@Tom-Elliott I’ll post the gen1\gen5\Optiplex7010 directory listing(s) but it’s affecting ALL images. All deploys fail with 1.3.X. This isn’t some system I casually use from time-to-time. This is a production system with storage nodes in NY, Dublin, Zurich and Singapore. These images are battle-tested and have been deployed hundreds of times each. That said…:

Optiplex 7010
Image path: /images/O7010V3
Dir listing:
-rwxrwxrwx 1 fog root 2 Oct 12 14:42 d1.fixed_size_partitions
-rwxrwxrwx 1 fog root 15 Oct 12 14:42 d1.original.fstypes
-rwxrwxrwx 1 fog root 259 Oct 12 14:42 d1.original.partitions
-rwxrwxrwx 1 fog root 0 Oct 12 14:42 d1.original.swapuuids
-rwxrwxrwx 1 fog root 8822083 Oct 12 14:45 rec.img.000
-rwxrwxrwx 1 fog root 18137848997 Oct 12 14:59 sys.img.000

Lenovo X1 (non-carbon, AKA ‘Gen1’)
Image path: /images/X1CG1V2
Dir listing:
-rwxrwxrwx 1 fog root 2 Oct 11 14:00 d1.fixed_size_partitions
-rwxrwxrwx 1 fog root 15 Oct 11 14:00 d1.original.fstypes
-rwxrwxrwx 1 fog root 259 Oct 11 14:00 d1.original.partitions
-rwxrwxrwx 1 fog root 0 Oct 11 14:00 d1.original.swapuuids
-rwxrwxrwx 1 fog root 8686938 Oct 11 14:01 rec.img.000
-rwxrwxrwx 1 fog root 16026941814 Oct 11 14:33 sys.img.000

Lenovo X1 Carbon (NVMe/AKA ‘Gen5’)
note: This is using a Kaby Lake Intel chipset. This chipset is only a minor iteration on the Skylake chipset which the Gen4 (Gen4 is also NVMe) used. For this reason, I’m attempting to write the ‘Gen4’ image to the ‘Gen5’

Image path: /images/X1CG4V3
Dir listing:
-rwxrwxrwx 1 fog root 2 Oct 12 12:24 d1.fixed_size_partitions
-rwxrwxrwx 1 fog root 15 Oct 12 12:24 d1.original.fstypes
-rwxrwxrwx 1 fog root 259 Oct 12 12:24 d1.original.partitions
-rwxrwxrwx 1 fog root 0 Oct 12 12:24 d1.original.swapuuids
-rwxrwxrwx 1 fog root 8822643 Oct 12 12:25 rec.img.000
-rwxrwxrwx 1 fog root 15994261402 Oct 12 12:52 sys.img.000

[BardWood]

@Tom-Elliott I will try the 100% switch. Also, no change with RC16.

[BardWood]

@Tom-Elliott Parted - 100% switch:

[Tom Elliott]

@BardWood What’s the contents of the d1.original.partitions files you have?

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