Posts made by drumnj

@Sebastian-Roth Overall the current solution isn’t bad, so no real rush to figure out. I just think it isn’t the best solution. I suppose another option for people is to always make a golden image on a drive smaller than any other drive they plan to deploy to. Doing this I have found does allow the recovery partition to be used (did this with 2004 to make a clean OOBE Win10 image…with Chrome included).

@Sebastian-Roth said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:

@drumnj I am sure you have read all those posts top to bottom and seen that quite often they are not all describing the exact same issue.

Sure the Recovery Partition thing might be a common one but I don’t think a mega-thread with everyone posting details will lead us to a general solution unless we have a full unterstanding of this.

If it’s the only solution that is consistently given out, is there really a difference?
So it’s a negative having multiple data points in one location where you guys can potentially say…“Everyone with this problem post your d1 parts file(s).” Giving you a lot of data where you could see a trend. Could even use it to seek out those with successful images (who may have a recovery partition) and get their info.

@Sebastian-Roth said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:

@drumnj By the way, I may phrase point about UEFI more directly. Is your image UEFI based?

@drumnj said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:

--------Here’s my info--------

Golden Image

• Windows 10 ver2004
• UEFI/GPT
• Fresh install (windows installer/or through Windows Update/grade)
• 4 partitions (EFI, Reserved, Windows, Recovery)

I’m sure you guys have noticed a lot of these posts showing up. Any thoughts on doing like an announcement pertaining to this issue or some kind of mega-thread to address those having problems?

I’m having trouble getting my resizable image to work on smaller drives. It’s about 45GB total and setup on a VM with a dynamically expanding HDD set for 500GB (~465GB base-2).

It only shows up when deploying on smaller drives (even those labeled as 500GB, but I think the usable (base-2) space is a little less). I’m testing it on another VM with a 128GB dynamic HDD.

--------Here’s my info--------

Golden Image

• Windows 10 ver2004
• UEFI/GPT
• Fresh install (windows installer/or through Windows Update/grade)
• 4 partitions (EFI, Reserved, Windows, Recovery)

FOG Installation
Ubuntu Server 18.04.5 LTS
1.5.9-RC2.11
bzImage Version: 4.19.123
bzImage32 Version: 4.19.123

Image Info
fixed_size_parts

1:2

minimum.parts

label: gpt
label-id: 60C1AD92-592D-4318-B576-C3591A345666
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 977272798
sector-size: 512

/dev/sda1 : start=        2048, size=     1021952, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=981988EA-AC00-40AF-BA82-EE611393B7F5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=     1024000, size=      262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=83F97CA4-C157-4F04-85F7-5A8444119211, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=     1286144, size=    74770610, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=627BF0E9-B41A-4554-B3EB-E116897D7073, name="Basic data partition"
/dev/sda4 : start=   967507968, size=       43370, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE6D871E-AD70-41AE-8986-698E993FE369, name="Basic data partition", attrs="GUID:63"

parts

label: gpt
label-id: 60C1AD92-592D-4318-B576-C3591A345666
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 977272798
sector-size: 512

/dev/sda1 : start=        2048, size=     1021952, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=981988EA-AC00-40AF-BA82-EE611393B7F5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=     1024000, size=      262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=83F97CA4-C157-4F04-85F7-5A8444119211, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=     1286144, size=   966221824, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=627BF0E9-B41A-4554-B3EB-E116897D7073, name="Basic data partition"
/dev/sda4 : start=   967507968, size=     9762816, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE6D871E-AD70-41AE-8986-698E993FE369, name="Basic data partition", attrs="GUID:63"

fstypes

/dev/sda3 ntfs
/dev/sda4 ntfs

Error

 * Restoring Partition Tables (GPT)..................Failed
 *  * Press [Enter] key to continue
 * Creating new GPT entries in memory.
 * Warning! Current disk size doesn't match that of the backup!
 * Adjusting sizes to match, but subsequent problems are possible!
 * 
 * Warning! Secondary partition table overlaps the last partition by
 * 699115915 blocks!
 * You will need to delete this partition or resize it in another utility.
 * 
 * Problem: partition 4 is too big for the disk.
 * Aborting write operation!
 * Aborting write of new partition table.
 * Find the detailed error message above this line. Use Shift-PageUp to scroll upwards.
 * ##############################################################################
 * #                                                                            #
 * #                         An error has been detected!                        #
 * #                                                                            #
 * ##############################################################################
 * Init Version: 20200517
 * Error trying to restore GPT partition tables (restorePartitionTablesAndBootLoaders)
 *    Args Passed: /dev/sda 1 /images/VAGMaster 9 all
 *     CMD Tried: sgdisk -gl /images/VAGMaster/d1.mbr /dev/sda
 *     Exit returned code: 4
 * 
 * Kernel variables and settings:
 * bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10.99.199.22/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac=00:15:5d:e9:47:06 ftp=10.99.199.22 storage=10.99.199.22:/images/ storageip=10.99.199.22 osid=9 irqpoll hostname=PXE_test chkdsk=0 img=VAGMaster imgType=n imgPartitionType=all imgid=4 imgFormat=5 PIGZ_COMP=-4 hostearly=1 isdebug=yes type=down

Debug
sgdisk

Creating new GPT entries in memory.
Warning! Current disk size doesn't match that of the backup!
Adjusting sizes to match, but subsequent problems are possible!

Warning! Secondary partition table overlaps the last partition by
699115915 blocks!
You will need to delete this partition or resize it in another utility.

Problem: partition 4 is too big for the disk.
Aborting write operation!
Aborting write of new partition table.

fdisk

GPT PMBR size mismatch (977272831 != 268435455) will be corrected by write.
Disk /dev/sda: 128 GiB, 137438953472 bytes, 268435456 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1           1 268435455 268435455  128G ee GPT

Partition 1 does not start on physical sector boundary.

sfdisk

GPT PMBR size mismatch (977272831 != 268435455) will be corrected by write.
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=           1, size=   268435455, type=ee

gdisk

GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.
Disk /dev/sda: 268435456 sectors, 128.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): D595642A-3893-4A85-B4A6-CDDCEC1CD04F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 268435422
Partitions will be aligned on 2048-sector boundaries
Total free space is 268435389 sectors (128.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Getting it “working” (not ideal)
The solution, or workaround, I have found is to delete that 4th partition. The recovery volume, and merge it with the primary C volume. Then no GPT error on any smaller size drive. However, I don’t think is a great solution. I would prefer not to delete the recovery partition as it can be useful. Plus Windows apparently re-adds it with major updates. I had to do this before as it’s been happening since I believe FOG 1.5.6 (https://forums.fogproject.org/post/124538)
 
 
 
Refrence
https://forums.fogproject.org/topic/13220/error-trying-to-restore-gpt-partition-deploying-an-image-to-smaller-disk

That’s a bingo.

However I found this topic: https://forums.fogproject.org/topic/13172/how-to-create-a-fog-ipxe-menu-entry-that-deploys-a-specific-image
A nicer representation with of args through pictures. That topic does go into creating a new iPXE menu entry, which is what I plan to do in preventing fog.deployimage from getting mucked up.

Oh this topic too: https://forums.fogproject.org/topic/8760/pxe-boot-menu-advanced
Though it’s a little dated.

@george1421 you provided some good keywords to help me find those topics.

 

For those that find this post. The steps to my solution:

• Use the link george provided, though you don’t need mac:
  http://<fog_server_ip>/fog/service/ipxe/boot.php?qihost=1&username=<fog>&password=<password>&imageID=<image_id>
• To get a better understanding of what you are copying and what is all defined and how they are reprosented read this post:
  https://forums.fogproject.org/topic/13172/how-to-create-a-fog-ipxe-menu-entry-that-deploys-a-specific-image
• In your iPXE menu Parameters text box you just need the long line that starts with kernel making sure to replace bzImage32 with bzImage and init_32.xz with init.xz
  Next line: imgfetch init.xz
  Then boot as the last line

Thanks again for the help @george1421

@george1421 said in Autodeploy a default image without any intervention (pressing Enter) - for non-registered hosts:

The system would then basically be in autopilot mode and deploy an image without any human intervention to say, “yes lets really do that”.

What’s wrong with that. It’s in house for our IT staff to use and only setup when imaging a large amount of machines at once. Anything that accidentally runs PXE would still format in an environment where we want it to format.

So there is no param to edit/add under fog.deployimage?
So “Image List Menu” disabled serves no purpose to auto selecting a default image?
Would Non-Registered Host Image be of any use?

I know this won’t be an issue with registering a host, but we deploy images at sites then ship them out. Likely never to show up again. So, often have dozens of machines new out of box to get imaged 1 time at our main office. Utilizing KVM and numerous other station setup benches it would be nice to not have to still press Enter with “Deploy Image” for 10 machines or so at a time.

I am running 1.5.9-RC2.9
I have fog.deployimage set as the Default Item, for Not Registered Hosts.
I have replaced login under “Parameters” with set username [myUsername] set password [myPassword]
This will then load an image list screen:
ImageName1 (1)
ImageName2 (2)
Return to menu

At this screen I have to press enter for the Default image (one at the top), even if there is no other image. I would like for it to just auto select the top/default image and continue on with deploying.

I found this topic: https://forums.fogproject.org/topic/9209/autodeployment-default-image-fog-1-30/2
But it doesn’t outline how to get it to be fully automated. The OP on that topic specified changing out param qihost 1 though I’m not sure with what.

I also found this topic: https://forums.fogproject.org/topic/12244/deploy-associed-image-on-boot-menu
However that gives another error when disabling (unchecking) “Image List Menu” under “FOG Boot Settings”. It will load up the Deploy Image menu option, but then state:
“Host is not valid, host has no image assigned, or there are no images defined on the server.”

I’m not sure what I’m missing, but the goal is to have the ability to image new computers once without any need to intervene at the keyboard (aside from booting to PXE) and do not need them registered as they get shipped out to another location after being imaged and setup.

I recently got a Lenovo ThinkPad L15 (Gen 1) that needed to be imaged. I could not get it to go with 1.5.8, so I updated to 1.5.9-RC2.9 and still no go. I then changed the Kernel to 5.6.18 (64) and it finally loaded up partclone. It was giving an error of no network interfaces found.

Possible FOG 1.5.8 would have worked if I had changed the Kernel then.
Using: ipxe.efi

@george1421
Thanks george, I had a feeling this was the case with the 2nd workflow. Always going to have to touch the computer at some point during it’s workplace life cycle (when it comes to image deployment).

You said you return yours to “normal” boot (I take it hd 1st). Does this mean whenever you need to run a new FOG deployment you need to run a program/script/policy, a hardware utility, to the machine to change boot order before you can deploy an image again?

Throughout my time reading up on FOG guides, errors, questions and just learning everything I can about image based deployment I’ve not come across a simplified way to setup numerous computers to network boot.

The main function for all mass deployment is have the machines boot from the network card to initiate through PXE to a boot server. However, how is everyone getting all their machines to do this for the first time (and every time after) with hundreds or thousands of computers? I know you can change the boot priority order, but is that what everyone does, manually change the order for each machine? I know Dell, HP and Lenovo have BIOS deployment tools, but those works after Windows is setup…so if you’re running SCCM you still have to get those machines to boot onto the network at least once. Even with vPro you still need to apply the settings once to control the BIOS remotely afterwards

Is there a way to mass change BIOS settings on lots of computers for the first time without spamming the bios setup/boot menu key for each one? Is there no way around having to touch each machine at least once the first time? This seems like quite the time investment if you have 1000s of machines and beginning an image deployment operation. Every computer we’ve received from vendors always has the harddrive 1st as the default.

@Sebastian-Roth Looks like it’s the same type of error. I did my tests using the same checkpoint on my image, multiple times, so nothing changed with my partitions, just the FOG version. I’m just going to stick with 1.5.5 since it works. I’ll test again when another version comes out.

I ran into the same issue. Upgraded to 1.5.6 and got this error when deploying my image. It was working on 1.5.5 before I updated, then recaptured a new image. If it helps…the 1.5.6 captured image doesn’t work, but the 1.5.5 captured image does. Used the same image that was captured on 1.5.6 on both versions, get this error. Using the 1.5.5 captured image on both versions, no error.

Running:
Ubuntu 18.04.2 LTS
Hyper-V