Hello

I had a problem when deploying an image with the FOG

Error message :
read ERROR: No such file or directory
Args Passed: /images/<image>/d1p2.img /dev/<disk>*

For me, it was a problem of user rights on the FOG

Before :
drwxrwxrwx. 2 root root 190 Jun 29 15:07 <image>

After:
drwxrwxrwx. 2 fogproject root 190 Jun 29 15:07 <image>

I had to do a “chown” on my image folder in the /images directory to add the owner to “fogproject”

When creating a new image in the FOG GUI, the folder rights management is not well handled

Sincerely

@fogcc Make sure you update to the latest FOS Linux kernel by going to FOG Web ui -> FOG Configuration -> Kernel update. You want 5.15.x (latest version) for both x64 and x32 platforms.

The boot order is pxe -> ipxe (FOG Menu) -> bzImage (FOS Linux kernel). Each step has their own network drivers.

@george1421 Hi we look through the article that you have send to us and it doesn’t work, the computer doesn’t recognize fog. We have done all the things that appears on the article. If you have another thing to help, I would appreciate.

Thank you

solved, ip on dhcp server option was incorrect

@fabritrento For others that might find this thread, the FOG installer doesn’t support and has not been tested on ubuntu 22.04 as of this post. Since 22.04 is an LTS release it will be supported in the near future with FOG 1.5.10 when its released. For now use 20.04 as the OP of the thread found.

@coe Ok, so for the ones that don’t get renamed by the client, we need the relevant portion of the fog.log file. This is where the client logs events and errors. Please be sure to copy/paste the whole portion, not just a line.

@amartinez said in Multicast-Unable to find image:

So storage nodes are limited to unicast imaging

That is correct. Storage nodes are kind of like a network drive for remote locations. They are missing the active services bits that make them a full fog server.

@george1421 I got it working again. Thanks for responding so fast. I haven’t been at my desk, so I just now saw your post.

@jmroc85 The problem is that ipxe.efi that ships with FOG 1.5.9 is 2 years old and we are finding compatibility issues with currently shipping hardware.

So you used the tarball method of installing FOG? Was there a specific reason for going that route?

@zaqen This one could be a difficult problem to solve. From FOG’s standpoint there is no technical difference between a SATA hard drive and SATA SSD. If it boots on a Hard drive it should boot on a SATA SSD. Many people run into the issue that the SATA SSD is typically smaller than the Hard Drive. The larger source disk to smaller target drive causes an issue. FOG will move partition start blocks to help resizing of the disk.

Where the problem comes in is if a partition is marked as non-movable. This means that the partition can not be squeezed or relocated on the target drive. What happens if this partition exists at a starting location that doesn’t exist in the target drive because the target drive is smaller than the source drive. This is a problem.

As long as you are on the dev branch of FOG v1.5.9.110 or later and FOS Linux kernel 5.15.x your fog install is up to date and the problem is with the structure of the source disk.

@riry I’m glad to hear that everything is back in order in your house. The dnsmasq solution is a solid one in that you don’t have to mess with your existing infrastructure if your current dhcp server doesn’t support dynamic pxe booting. Secondly if you power off your FOG server so dnsmasq is off line so no pxe boot info is sent out. As soon as the FOG server is back online so is PXE boot support via dnsmasq.

Well done getting everything working in your environment.

@bylkem said in Snapin queued bash:

The task does not start and remains in queue.

Have you checked fog-client service is actually running on the machine and communication to the server is alright? Please post the fog.log here if you are in doubt.

@Eric-Johnson Take a look at FOG Configuration -> FOG Settings -> FOG Client - Host Register -> QUICKREG PENDING MAC FILTER. Just set to 0A:00:27 and it should ignore any MAC matching this pattern.

@george1421
Well I’ll be damned

35f04c28-e6a6-4fff-80c2-fb2738c82298-image.png

cross linking posts that appear to have similar issues: https://forums.fogproject.org/topic/16327/windows-10-21h2-fogservice-not-starting

@jas777 nevermind, turned out to be a TP-Link switch not multicasting properly for some reason, everything works now!

@nadachowski

I also have the drivers copied from the FOGServer to the PC after deployment. If the script does not find the path, because I forgot to create it or it is written incorrectly, I also have the problem.

Although the actual image was transferred, FOG thinks that it is not complete, although only the drivers are missing.

Maybe it is similar with you?
At the end of the deployment come with me still some notes or halt the error message.

@george1421 said in FOS fails to capture image from md RAID host:

since you referenced my tutorial I assumed you are using the intel raid.

I referenced your Intel RAID tutorial because I found another forum post on mdadm where you linked to it and stated that it was similar in principle. I am actually working on capturing an image from a Linux host with md RAID, and deploying the same image to other hosts with identical hardware.

By way of update, I removed the large sda device (a hardware RAID) and the USB stick, so my disk layout was thus (from the running host OS):

# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 139.8G 0 disk ├─sda1 8:1 0 300M 0 part ├─sda2 8:2 0 30G 0 part │ └─md0 9:0 0 30G 0 raid1 / └─sda3 8:3 0 2G 0 part └─md127 9:127 0 2G 0 raid1 sdb 8:16 0 139.8G 0 disk ├─sdb1 8:17 0 300M 0 part /boot/efi ├─sdb2 8:18 0 30G 0 part │ └─md0 9:0 0 30G 0 raid1 / └─sdb3 8:19 0 2G 0 part └─md127 9:127 0 2G 0 raid1

I then configured the following in FOG, with the noted outcomes:

Host Primary Disk: /dev/md126 (equivalent to md0 on live system above)
Image Type: Multiple Partition Image - All Disks (3)
Host Kernel Arguments: mdraid=true
Outcome: fails to find disks

Host Primary Disk: /dev/md126 (equivalent to md0 on live system above)
Image Type: Multiple Partition Image - Single Disk (2)
Host Kernel Arguments: mdraid=true
Outcome: fails to read partition table

Host Primary Disk: /dev/sdb
Image Type: Multiple Partition Image - Single Disk (2)
Host Kernel Arguments: [not noted. I forget]
Outcome: fails to read partition table

Host Primary Disk: /dev/sda
Image Type: Multiple Partition Image - All Disks (3)
Host Kernel Arguments: [none]
Outcome: capture succeeds. Deployment on new system succeeds. System boots and partition table on sda looks correct. md127 is lost. Partition table on sdb is not correct:

# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 139.8G 0 disk ├─sda1 8:1 0 300M 0 part ├─sda2 8:2 0 30G 0 part │ └─md0 9:0 0 30G 0 raid1 / └─sda3 8:3 0 2G 0 part sdb 8:16 0 139.8G 0 disk ├─sdb1 8:17 0 1G 0 part └─sdb2 8:18 0 138.8G 0 part

I’m not sure if the deployment procedure touched sdb or not. I suspect not. I will try again and watch closer or record it. I suppose I can rebuild my RAIDs from here, but I would of course prefer to have FOG automate that process to the extent possible.

Edit: added FOG settings detail.

@duemti I added an entry in DNS of the router with hostname of a computer. I can ping it from host shell yet in gui it is still connection timed out!
fe8206ef-9c6b-4c6e-a7d8-1075a26f82e6-image.png

9edbc8ed-dbc4-4ec8-aa27-ccb897de0e9a-image.png

Also i can’t do a full registration because it fails with: ‘unsafe hostname entered please try again’

@david-burgess @Wayne-Workman Using the latest dev-branch version you should be able to use disk size or WWN or disk identifier to force disk order. It’s a known issue that NVMe drives get enumerated in different order by the Linux kernel.

Search the forums for “nvme wwn” and you should find a topic with helpful information on this.