Posts made by 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

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

@Tom-Elliott Additional info from Optiplex Desktop:

@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 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 directory

FYI: 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.

@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).

@Tom-Elliott

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 directory

Unsure 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”

PS. Same result as in my screenshot on our Dell Optiplex 7010 desktop.

@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’

@BardWood Just saw your message below. I’ll attempt debug.

@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.

@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.

The upgrade was smooth in the sense that all my images are there, no account issues, I can get to the portal, etc. However, I can no longer actually deploy any images. Whether I deploy an existing image or try to create a new one I get a screen such as the one displayed in my attachment

PS. I assume you mean ‘FOG 1.3.5 RC 13’ when you say “RC series”? Is that the latest RC build?

Thank you. So, I should upgrade to trunk. Got it. Can you point me to the most appropriate howto or at least outline the steps? I’d really like to keep the existing mysql DB intact if possible. I have installed 1.3 beta on CentOS 7 as a test and it did function but I’m just wondering if the process is different if I’m upgrading 1.2.0->1.3.X on Centos 6.7. Does the 1.3.X install script make accommodations for an existing installation of 1.2.0?

Greetings,

I need 1.3.X because 1.2.0 has a kernel which isn’t compatible with the brand-new Lenovo Thinkpad Gen5. Compatibility test fails. I’ve been looking around for a how-to but everything I’ve seen is in regards to Ubuntu. Please point me to the best documentation for Centos 6.7. I see docs for Centos 7. Should I upgrade to 7 before attempting the upgrade?

Server

• FOG Version: 1.2.0
• OS: CentOS 6.7

Client

• Service Version:
• OS:

Description

Understood. So it is supposed to be exporting the entire image and not just a CSV?

Server

• FOG Version: 1.3.0-RC-14
• OS: CentOS 7.2

Client (none)

• Service Version:
• OS:

Description

This isn’t really a problem (unless it is) but I need some clarity on what is supposed to happen when I click ‘export images’.

What I expected is a ‘Save As’ type box to pop up asking me where to save an image. Instead, I get a CSV. What I’m trying to do is independently extract an image, save it to a DropBox-like service from the San Francisco office and have an employee in Dublin pull the image down and import it into his storage node. We have a VPLS link which is only 20mb wide to Dublin (of which we get maybe 3-5mb for IT stuff). However they have 100mb down from the internet and we have over 100mb up. The goal is significantly faster image transfer.

Regardless of whether this or something like it is possible, I want to say great job and thanks for RC14. The last time I visited Trunk was about 6+ months ago but it didn’t feel ready for prime time. I notice a massive improvement in RC14. Keep it up guys!

@Wayne-Workman That may be but we have verified the entries there and they are accurate. 66 is pointing to the IP of San Francisco’s FOG/TFTP server and 67 is specifying undionly.kpxe.

I do have multiple DHCP servers.

San Francisco DHCP = MS DHCP = Works fine over 2 subnets. FOG is x.x.70.x. local clients are x.x.40.x.
Dublin DHCP = Cisco DHCP via the switch. DHCP points PXE clients to SF TFTP. DUB clients get an IP but timeout on TFTP attempts. Using a DUB client on 40.x, and attempting to retrieve undionly.kpxe from SF is successful within the OS. There is no firewall issue.

Dublin client begins PXE boot as displayed in the screenshot but never gets the PXE boot file.