Please point me to 1.2.0 -> 1.3.4 for Centos 6.7 upgrade docs/guide.
-
@Tom-Elliott Thank’s for the reply but that’s not the issue. I have a (gen 1) system I had previously imaged with 1.2.0. FOG recognized it when I booted to the PXE menu. Although my screenshot shows what happens when trying to write a Thinkpad X1 image (gen 4) to a gen 5 machine, the system I mention above is both the master for the gen1 image and also has had no changes since I last imaged it. Meaning it’s the same image taken from the exact same machine with no hardware changes and the same message displays when attempting to write that image back. Something other than size is playing a part. P.S. I also updated to 1.3.5.RC-14. Same issue.
-
@BardWood I tested this and had no issues. I’m not sure where the disconnect is, but my guess is the partition layout is not able to be placed on that system.
You can say otherwise, my testing took an image from 1.2.0 captured, tested on three different systems.
Something is different somewhere. I am most sure of it. Now there is the possibility your disk is now a 4k disk? I’m only guessing based on the information I have. I assure you, the legacy placement is working as intended. The only difference I can think of is the way resizing occurred in 1.2.0 vs how it occurs in 1.3.x now. These changes were needed and are unlikely to change.
I’m not lying however, that the issue (even if it is as I suspect due to 4k vs 512 bytes) is because one disk size is different from the other.
-
Further looking over, it appears the “resize” code isn’t even to blame, but rather the
partedcommand is unable to create the partition.You could try running a debug session.
When it fails to run, try running:
parted -s /dev/sda mkpart primary ntfs 206848s -- -1s -
@Tom-Elliott I will double-check the block size on the ‘Gen 5’. That’s a solid lead. In the case of the ‘Gen 1’ master and attempting to write the image that came from it back to it, there is no change whatsoever. I’ll attempt to image a few more machines of different types (I’ll attempt one of our desktops, Dell Optiplex 7010). Both the Optiplex and Lenovo X1 ‘Gen 1’ images worked with 1.2.0 and I wrote both of those images back to their respective machine types last week. Is there a way to gather additional data? I see 'Log level 4" in the parameters but found no corresponding data on the Web interface.
-
@BardWood Just saw your message below. I’ll attempt debug.
-
@Tom-Elliott said in Please point me to 1.2.0 -> 1.3.4 for Centos 6.7 upgrade docs/guide.:
parted -s /dev/sda mkpart primary ntfs 206848s – -1s
Output of above command:
‘Error: The location 206848 is outside of the device /dev/sda’ -
PS. Same result as in my screenshot on our Dell Optiplex 7010 desktop.
-
X1 Carbon, gen1:
Output of above command:
‘Error: The location 206848 is outside of the device /dev/sda’
*This only has a 160G disk so 206848 may be too large.Optiplex 7010, 500GB disk:
Error: Can’t have overlapping partitions.X1 Carbon, Gen 5:
Error: Could not stat device /dev/sda - no such file or directoryUnsure if this is related but while FOG is booting the kernel, I see output stating:
“Populating /dev using udev: udevd[2536]: error creating epoll fd: Function not implemented”
-
@BardWood Not related.
Is this image a single partition image? Or do you have a recovery partition as well?
-
@Tom-Elliott I saw that in the screenshot, ‘recovery partition’. Thing is, I booted that machine off a Gparted live USB image (latest version as of today) and it only sees 2. The MS riser and primary (technically, both are primary but you know what I mean). I’m trying to deploy a Win7, full disk, multi-partition. No recovery partition spotted so far. The disk on the ‘Gen5’ is using NVMe on SATA3(6gb).
-
@BardWood The message of the “Output of above command: ’ Error: The location 206848 is outside of the device /dev/sda’” Was this on the machine with the NVMe disk?
-
@Tom-Elliott No, that was from the X1 ‘Gen1’. The NVMe machine (Gen5) error is: X1 Carbon, Gen 5:
Error: Could not stat device /dev/sda - no such file or directoryFYI: I updated to RC-15 but so far no change in the errors. I’ve only tested RC-15 on the ‘Gen1’. I’ll try to re-run the parted command on the Gen5.
-
@BardWood The debug, because you have nvme, probably needs:
/dev/nvmen0(a fdisk -l orlsblk -dpnomight prove more fruitful here) -
@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’
-
@Tom-Elliott Additional info from Optiplex Desktop:
-
@BardWood That message (the it exists is non-issue).
SO now that we know the device name (it’s not /dev/sda)
Try the
foguntil it fails.Then when it fails at the prompt try:
parted -s /dev/nvme0n1 mkpart primary ntfs 206848s -- -1s -
@Tom-Elliott Tried that (see below): Output = ‘Error: You requested a partition from 106mb to 512gb (sectors 206848… 1000215215)’
-
@BardWood It’s a 512 Gb disk?
-
can you try:
parted -s /dev/nvme0n1 mkpart primary ntfs 206848s 100% -
I see what the problem is.
What I don’t understand is what the OS is.
Can you get contents of
ls /images/<relevantimagehere>?
