Posts made by Dan_Ansel

@george1421

I did it !!

So I basically made a Frankenstein’s monster version of my image.

As I’ve stated in my last comment, I had an issue where the windows drive did not have the same partition number.

I created a new legacy windows 10 VM, with a smaller C Drive than I created the very first time I worked on that image. I converted that installation into UEFI.
So now my newly installed win10 and my oversized image have the exact same disk structure.

I deployed the partition containing all my data onto the new VM, and I had an issue where the UEFI boot was broken.

I used the tools in the installation media to repair the EFI partition. I used diskpart to assign a letter to the EFI partition, exited diskpart and ran this command :

bcdboot C:\Windows fr-fr /s B: /f

Windows booted.
Now I’m capturing the image and I’ll deploy it to make sure it’s working fine
Thanks for all the help and ideas!!

Regards,
Dan

@george1421

There’s an issue when deploying.

First, I’ll tel you what I’ve done exactly :

1. I capture the specific partition containing the fully installed windows 10 (it was on /dev/sda2). I used the option Single Disk - Resizable, Partition 2 only

2. I installed a brand new virtual machine in UEFI from the get go to get a proper disk structure, I remove the last partition

3. I created the deploy task, and that’s when the problom occurs : since the partition captured wad /dev/sda2 , the task is trying to deploy over the /dev/sda2 of the new installation, and if I change the partition number in the web GUI for the image, I have an other error message telling me that there is not partition with that number to deploy in the image.

Is there a way to tell fog to deploy a partition that was /dev/sda2 over a new one that is /dev/sda3 ?

Regards,
Dan

@george1421

Thank you for taking the time to make this a bit clearer to me.

I’m trying this right now.
I just hope the fact that the C Drive partition will not have the same number won’t be an issue (it was /dev/sda2 on the completed install, and will be /dev/sda3 on the new one if all goes well)

It really feels like surgery

I’ll keep you updated on how it will go (you’ll probably here from me tomorrow)

Regards,
Dan

@george1421

If I understand you correctly :

1. I create a new VM with a brand new Win10 install for the disk structure.
2. I remove the last partition, and it should normally be the recovery
3. I capture the C Drive partition where I have installed everything I need (I capture this specific partition)
4. I deploy that partition on the brand new install of Win10, writing over the empty C Drive

I’m not sure that’s exactly what you said, hence my question to confirm the steps

@george1421 yeah I know, I believe it’s because the image was originally in Legacy mode, and I converted it to UEFI (using mbr2pgt), so the EFI partition was created last.

@george1421 the partition causing all the trouble is the EFI system one
If i remove it entirely, my OS won’t boot at all, will it ?

@george1421

OK thanks for your anwser.
I’ll get working on a new image then since time is of the essence here.

I’ll keep an eye on this thread and try out ideas thrown here.
If my problem can be used as a template on how to resolve this issue, it might help others as well.

Regards,
Dan

@Sebastian-Roth @george1421

Do I just need to change the start value in both files (d1.partitions and d1.minimum.partitions) for /dev/sda3, and the size value of /dev/sda2 in d1.partitions ?

Regards,
Dan

@Sebastian-Roth

Here’s the content of the d1.minimum :

label: gpt
label-id: 38CF0A2B-CD00-11EA-B7E0-000C29541530
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 536870878
sector-size: 512

/dev/sda1 : start=        2048, size=     1185792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=38CF0A28-CD00-11EA-B7E0-000C29541530, name="attrs=\x22RequiredPartition GUID:63"
/dev/sda2 : start=     1187840, size=   282008362, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38CF0A29-CD00-11EA-B7E0-000C29541530
/dev/sda3 : start=   536662016, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=38CF0A2A-CD00-11EA-B7E0-000C29541530, name="attrs=\x22GUID:63"

EDIT: bad copy paste, sorry

@george1421

There it is :

d1.fixed_size_partitions :

1:3

d1.partitions :

label: gpt
label-id: 38CF0A2B-CD00-11EA-B7E0-000C29541530
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 536870878
sector-size: 512

/dev/sda1 : start=        2048, size=     1185792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=38CF0A28-CD00-11EA-B7E0-000C29541530, attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1187840, size=   535474176, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38CF0A29-CD00-11EA-B7E0-000C29541530
/dev/sda3 : start=   536662016, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=38CF0A2A-CD00-11EA-B7E0-000C29541530, attrs="GUID:63"

@george1421

Hello, thanks for your answer.

I’m trying to deploy Windows 10 1909, I did not make the jump to the 2004.

I’m desperately trying to avoid re creating my images.
As for the hacking way, i’m not too sure where to start.

Regards,
Dan

Hello everyone,

I’m trying to deploy multiple classrooms, and I have a problem with computers equipped with a 256 GB SSD.

When I’m trying to deploy, I get this on screen :

Warning! Current disk size doesn’t match that of backup!
Adjusting sizes to match, but subsequent problems are possible!

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

Problem : partition 3 is too big for the disk.
Aborting write operation!
Aborting write of new partition table.
Find the detailed error message above the 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/IMAGE_NAME 9 all
CMD Tried : sgdisk -gl /images/IMAGE_NAME/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://MY_FOG_IP/fog consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac=HOST_MAC ftp=MY_FOG_IP storage=My_FOG_IP:/images/ storageip=MY_FOG_IP osid=9 irqpoll hostname=CLIENT_NAME chkdsk=0 img=IMAGE_NAME imgType=n ImgPartitionTupe=all imgid=141 imgFormat=5 PIGZ_COMP=-5 tupe=down

The image I’m trying to deploy is a Windows 10 installation.
I ran a mbr2gpt conversion (I did that aswell previous years and had no issue).

I’m running the 1.5.9-RC2 version of FOG

I tried to remove the partition responsible for the error, but when I do so, my OS is not booting at all anymore.

On my image, when I check the partition I have this :

Obviously I know the removing the EFI system partition is exactly why my VM is not booting anymore, but I do not see what I can do to resolve this issue.

If anyone has any idea, I’d love to hear it.

Thank you (and sorry for the long and quite difficult to read post)

Regards,
Dan

On a side note, I always have this error message poping up when I capture any image :

udevd [3760] failed to executre ‘/lib/udev/${exec_prefix}/bin/udevadm’ ‘${exect_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0’ : No such file or directory

@Sebastian-Roth

Hello,

The image size is indicated in two different places.
First when the capture progress is under way, it is indicated that the image size will be 510Go
Second, in the image list, where the size on client is indicated.

I updated my fog server to the newest version just in case.

That specific issue is on the back burner as I’m currently trying to figure out why another image is failing to deploy (something about failing to restore GPT partition tables).

I don’t have the exact block size in mind, only the detected capacity of 502000 MB.

Thanks for your answer.

Best Regards,
Dan

Hello,

I’m currently facing a strange issue.

I’m capturing an image containing multiple partition (Windows 10 and Debian both present on the OS).

I usually capture my image using the option All Partition, Single Disk, Not resizable.
But this year, I have a small issue with the GRUB not finding any OS, even though it was working just fine on the VM before the capture.

So I decided to use the RAW option for the capture, and after deployment it works just fine.
But now my problem lies within the image size.
I’ve given my virtual machine a disk size of 475 GB, but the image captured is 510 GB.
That small difference is making it impossible to deploy the image on a few classrooms (where I have installed news bought SSD).

Has anyone seen that problem before ?

PS : My fog server is still in version 1.5.7

It’s all good.
The database is up and running again.
Sorry for the inconvenience, I should’ve found out about the /tmp permissions shenanigans.

Thank You again.

Dan

It seems to have done it!
I’m running the updater again
It’s doing more than the first time, installing and updating packages.

I have absolutely no idea how the permission on the /tmp changed.

Thank You very much.

There it is :

ls -lah /tmp
total 40M
drwxrwxr-x 12 root root 4,0K sept. 19 16:11 .
drwxr-xr-x 25 root root 4,0K sept. 19 14:20 …

I did not touch the permission on /tmp, is it safe to change them with chmod?

I don’t have a /var/log/mariadb directory, only /var/log/mysql

Here’s what inside /var/log/mysql/error.log

2019-09-19 15:43:54 140433339829632 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2019-09-19 15:43:54 140433339829632 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: The InnoDB memory heap is disabled
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: Using Linux native AIO
2019-09-19 15:43:54 140433339829632 [Note] InnoDB: Using SSE crc32 instructions
2019-09-19 15:43:54 140433339829632 [ERROR] mysqld: Can’t create/write to file ‘/tmp/ib4RWGdN’ (Errcode: 13 “Permission denied”)
2019-09-19 15:43:54 7fb92f55cd80 InnoDB: Error: unable to create temporary file; errno: 13
2019-09-19 15:43:54 140433339829632 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-09-19 15:43:54 140433339829632 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-09-19 15:43:54 140433339829632 [Note] Plugin ‘FEEDBACK’ is disabled.
2019-09-19 15:43:54 140433339829632 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-09-19 15:43:54 140433339829632 [ERROR] Aborting

2019-09-19 15:45:55 139812706057600 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2019-09-19 15:45:55 139812706057600 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: The InnoDB memory heap is disabled
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: Using Linux native AIO
2019-09-19 15:45:55 139812706057600 [Note] InnoDB: Using SSE crc32 instructions
2019-09-19 15:45:55 139812706057600 [ERROR] mysqld: Can’t create/write to file ‘/tmp/ibDn1xvV’ (Errcode: 13 “Permission denied”)
2019-09-19 15:45:55 7f28aeadfd80 InnoDB: Error: unable to create temporary file; errno: 13
2019-09-19 15:45:55 139812706057600 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-09-19 15:45:55 139812706057600 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-09-19 15:45:55 139812706057600 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-09-19 15:45:55 139812706057600 [ERROR] Aborting

2019-09-19 15:50:17 140527244000640 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2019-09-19 15:50:17 140527244000640 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: The InnoDB memory heap is disabled
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: Using Linux native AIO
2019-09-19 15:50:17 140527244000640 [Note] InnoDB: Using SSE crc32 instructions
2019-09-19 15:50:17 140527244000640 [ERROR] mysqld: Can’t create/write to file ‘/tmp/ib5rDzMm’ (Errcode: 13 “Permission denied”)
2019-09-19 15:50:17 7fcf0c75bd80 InnoDB: Error: unable to create temporary file; errno: 13
2019-09-19 15:50:17 140527244000640 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-09-19 15:50:17 140527244000640 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-09-19 15:50:17 140527244000640 [Note] Plugin ‘FEEDBACK’ is disabled.
2019-09-19 15:50:17 140527244000640 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-09-19 15:50:17 140527244000640 [ERROR] Aborting

For information, MySQL was installed during the fog installation.

Hello,

I’m running into some database connectivity issue after updating FoG.
I can’t start the mysql service anymore.
When I check what happened with the journalctl -xe command and I get this :

sept. 19 14:54:43 [server] mysqld[9653]: 2019-09-19 14:54:43 140399207951744 [Note] /usr/sbin/mysqld (mysqld 10.1.38-MariaDB-0+deb9u1) starting as process 9653 …
sept. 19 14:54:43 [server] systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
sept. 19 14:54:43 [server] systemd[1]: Failed to start MariaDB 10.1.38 database server.
sept. 19 14:54:43 [server] systemd[1]: mariadb.service: Unit entered failed state.
sept. 19 14:54:43 [server] systemd[1]: mariadb.service: Failed with result ‘exit-code’.

I read on the forum about the database connection issue but it’s all about Ubuntu, and I’m running Debian 9.
I would really appreciate any help to get my database up and running again.

Thank You

Dan

Edit : I forgot the write down the error I get when trying to start MySQL :
Job for mariadb.service failed because the control process exited with error code.
See “systemctl status mariadb.service” and “journalctl -xe” for details.
The /var/run/mysqld directory is empty too