@Tom-Elliott

Organization Name: Tribunal Regional Eleitoral do Paraná
Location: Paraná - Brazil
Approximate Number of systems: about 2500 registered hosts and 158 different locations
How long: since early 2018

Tribunal Regional Eleitoral do Paraná, a.k.a. TRE-PR, is the government body responsible for the electoral process (election, electronic ballot box, tabulation of results, etc.)

We’re proud to post here because at this very date, we concluded our implementation of FOG in our entire state (Paraná), wich means:

• a central location at our state capital (Curitiba), with our main server, and about 500 hosts
• 157 remote locations in the entire state of Paraná, each one with about 5 to 40 hosts, totaling about 2500 hosts, each one with a Storage Node.

So, hurray and thanks for all the efforts of the development team and your support!

Sorry for bringing this back to life, but I guess this needs a disclosure: i fixed the issue incresing the max connections on my DB and by reducing the time that MySQL keeps the idle connections active. Sorry for not bringing this earlier.

@Sebastian-Roth said in Updating FOG and Storages from 1.5.4 to lattest version:

ClusterSSH

thanks for the hints and sorry for the delay in answering! another question, running the install script would do the trick on an existing and running 1.5.4 server?

Hello everyone, hope you all are alright in this troubled times!

I’m planning on finally upgrading my FOG server from version 1.5.4 to lattest stable version available, but I have some concerns I must address first, maybe you can provide me some insight!

1. im running the server in version 1.5.4, and with it, about 160 remote locations running Storages. Will I have any serious issues if I update only the main server to lattest version, leaving the storages on older versions?

2. About the Storages, I know the best to do when updating main server is to update the Storages at the same time to ensure compatibility. BUT the large maiority of my remote storages dont have Internet access. Considering this, is there any way I could upload everything to my Storages via local network and then make then offline update? In this case, updating the main server first or the storages first? Ah, my storages are all running on CentOS7.

thanks in advance, and stay safe!

@Sebastian-Roth said in Help with GPT partitioning:

Why is you EFI boot partition (type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B) at the end of the disk? It’s quite strange. Did you do this install yourself?

I did not. Unfortunally I got a base image to work with from higher ranks of my organization to work with. If it was all my work from scratch, I would never do this nosense. Do you think is there any way to move the EFI boot partition to the beggining of the disk without compromising the entire system or I’m doomed to restart from scratch?

Sorry for bringing this back to life, but I guess this needs a disclosure: i fixed the issue incresing the max connections on my DB and by reducing the time that MySQL keeps the idle connections active. Sorry for not bringing this earlier.

Hello guys, and sorry if this is the wrong place for this kind of question. I’ve been working on a Windows 10 Golden Image on a VM with a 200Gb HD, one partition for the SO and another for Data. As soon I finished building it, I did the capture with FOG, version 1.5.5.

Now I’m in the phase of deploying and testing the image against our hardwares, and one of them has a hd of 120Gb, wich is presenting problem on deploy, some error in the moment of restoring the GPT table.

My guess the problem involes the GPT partition being in the end of the disk, but I would like an insight from you guys, and if there’s any ways of making this work without restart building my image from scratch. Here follows the infos on the capture files and the error screen.

d1.partitions:

label: gpt
label-id: 594FBEB8-B041-4144-93F7-E40896645CC8
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 419430366

/dev/sda1 : start=        2048, size=   218431488, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CA86F564-26DF-4F24-892B-8D895CA56995, name="Basic data partition"
/dev/sda2 : start=   218433536, size=   200585216, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=734653A0-99BF-4CE4-B30C-B56E2C63F1BF, name="Basic data partition"
/dev/sda3 : start=   419018752, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=4B808A8E-70C8-4555-B027-31D0FAED65F8, name="EFI system partition", attrs="GUID:63"

d1.minimum.partitions

label: gpt
label-id: 594FBEB8-B041-4144-93F7-E40896645CC8
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 419430366

/dev/sda1 : start=        2048, size=    40209666, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CA86F564-26DF-4F24-892B-8D895CA56995, name="Basic data partition"
/dev/sda2 : start=   218433536, size=     4442810, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=734653A0-99BF-4CE4-B30C-B56E2C63F1BF, name="Basic data partition"
/dev/sda3 : start=   419018752, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=4B808A8E-70C8-4555-B027-31D0FAED65F8, name="EFI system partition", attrs="GUID:63"

d1.fixed_size_partitions

:3

d1.original.fstypes

/dev/sda1 ntfs
/dev/sda2 ntfs

Any insights if my conjectures are right, and if theres any way to fix it, would be very welcome
Thanks again in advance

@Tom-Elliott

Organization Name: Tribunal Regional Eleitoral do Paraná
Location: Paraná - Brazil
Approximate Number of systems: about 2500 registered hosts and 158 different locations
How long: since early 2018

Tribunal Regional Eleitoral do Paraná, a.k.a. TRE-PR, is the government body responsible for the electoral process (election, electronic ballot box, tabulation of results, etc.)

We’re proud to post here because at this very date, we concluded our implementation of FOG in our entire state (Paraná), wich means:

• a central location at our state capital (Curitiba), with our main server, and about 500 hosts
• 157 remote locations in the entire state of Paraná, each one with about 5 to 40 hosts, totaling about 2500 hosts, each one with a Storage Node.

So, hurray and thanks for all the efforts of the development team and your support!

@Sebastian-Roth said in Error trying to restore GPT partition deploying an Image to Smaller Disk:

it doesn’t make much sense to me to set fixed to “:2:3:4”

indeed it does not make sense, because i confused myself haha =D
i meant to set fixed to “:1:2:3”, intending to keep the 3 first partitions fixed and the last one resizable as need. that also did not work.

i really don’t mind changing the files to achieve the desired result, but if fixed_size_partitions works, it would be a LOT more easier

@Sebastian-Roth yeah, we did… To solve the problem i did that HEX edition on the d1.mbr file you suggested and it fixed my issue. what still intrigues me is the fact that using d1.fixed_size_partitions, i.e. changing it to :2:3:4 is not ensuring those partitions to stay with fixed size as i needed. to make it happen, i had to make the sizes on both d1.partitions and d1.minium.partitions the same.

i’ll take a look on this other forum link you mentioned.

I noticed sometimes it happened because my database max connections were exceeded, leading to an error on loading the menu.

Is there a way to change this behavior of iPXE commanding a reboot?

Hello everyone! Here’s my scenario: I have my computer’s boot order set to:
1st boot: Lan with PXE
2nd boot: Hard Disk.

Lets say that, for any mysterious reasons, the iPXE booting fails to load the FOG Boot Menu, in this case I would expect that it would continue to booting on the 2nd boot configured, Hard Disk in my case. But it’s not happening, after the iPXE fails happens, seconds later the machine reboots and the machine gets stuck in a loop boot->ipxe fail->reboot .

Am I doing anything wrong? Is there any setting in FOG i’m missing?