Posts made by lperoma

@george1421 I can confirm my workaround worked, and sending 64bit kernel and initrd images boots FOS no problem.

From fog inventory:

System Manufacturer Dell Inc.
System Product OptiPlex 9020 AIO
System Version 01
System Serial Number 7DT9322
System UUID 4c4c4544-0044-5410-8039-b7c04f333232
System Type Type: All In One
BIOS Vendor Dell Inc.
BIOS Version A08
BIOS Date 05/15/2014
Motherboard Manufacturer Dell Inc.
Motherboard Product Name 0GXX2X
Motherboard Version A00
Motherboard Serial Number /7DT9322/CN7443133R001K/
Motherboard Asset Tag Not Specified
CPU Manufacturer Intel
CPU Version Intel Core i5-4570S CPU @ 2.90GHz
CPU Normal Speed Current Speed: 2900 MHz
CPU Max Speed Max Speed: 3000 MHz
Memory 7.68 GiB
Hard Disk Model KINGSTON SA400S37240G
Hard Disk Firmware SAJ20104
Hard Disk Serial Number 50026B7685C378B6
Chassis Manufacturer Dell Inc.
Chassis Version
Chassis Serial 7DT9322
Chassis Asset Not Specified
GPU-0 Vendor Advanced Micro Devices
GPU-0 Product Inc. [AMD/ATI]
GPU-1 Vendor Intel Corporation
GPU-1 Product Mars [Radeon HD 8670A/8670M/8750M / R7 M370]

Regards,

@george1421 All these Dell AIO PCs have this failure in fairness. BIOS mode. I guess it has to do something with dnspasq missidentifiying the computer ?

Fog settings appear correctly. I don’t have and will never have 32 bit clients, so I guess a workaround could be sending 64 bzimage and initrd files to these clients identified as 32 in the setting you suggest.

I will try to troubleshoot dnsmasq and see.

Any other idea? Can some one identify any issue with my dnsmasq ?

Thanks,

@george1421 I have no idea. This is a 8yr old dell AIO machine, 64bit.

Before, we only had BIOS machines. No DHPCproxy, just straight into undionly.kpxe, never had a problem with BIOS machines.

Lately I have also put in place a dnsmasq service to allow for UEFI and BIOS, This are the settings:

I am not sure if it has anything to do with this, I don’t really understand the PXE process, despite investing a bit of time on it.

This are the logs from dnsmasq

3722788871 available DHCP subnet: 192.168.0.0/255.255.252.0
3722788871 vendor class: PXEClient:Arch:00000:UNDI:002001
3722788871 PXE(eth0) 5c:f9:dd:e5:40:07 proxy
3722788871 tags: BIOS, eth0
3722788871 bootfile name: ipxe.kkpxe
3722788871 next server: 192.168.0.21
3722788871 broadcast response
3722788871 sent size: 1 option: 53 message-type 2
3722788871 sent size: 4 option: 54 server-identifier 192.168.0.40
3722788871 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
3722788871 sent size: 17 option: 97 client-machine-id 00:44:45:4c:4c:44:00:10:54:80:39:b7:c0:4f…
3722788871 sent size: 50 option: 43 vendor-encap 06:01:03:08:07:80:00:01:c0:a8:00:28:09:0e…
3722788871 available DHCP subnet: 192.168.0.0/255.255.252.0
3722788871 vendor class: PXEClient:Arch:00000:UNDI:002001
3722788871 available DHCP subnet: 192.168.0.0/255.255.252.0
3722788871 vendor class: PXEClient:Arch:00000:UNDI:002001
3722788871 PXE(eth0) 192.168.2.236 5c:f9:dd:e5:40:07 ipxe.kkpxe
3722788871 tags: BIOS, eth0
3722788871 bootfile name: ipxe.kkpxe
3722788871 next server: 192.168.0.40
3722788871 sent size: 1 option: 53 message-type 5
3722788871 sent size: 4 option: 54 server-identifier 192.168.0.40
3722788871 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
3722788871 sent size: 17 option: 97 client-machine-id 00:44:45:4c:4c:44:00:10:54:80:39:b7:c0:4f…
3722788871 sent size: 28 option: 43 vendor-encap 47:04:80:00:00:00:0a:13:01:42:6f:6f:74:69…
error 0 TFTP Aborted received from 192.168.2.236
sent /tftpboot/ipxe.kkpxe to 192.168.2.236
sent /tftpboot/ipxe.kkpxe to 192.168.2.236
3942607374 available DHCP subnet: 192.168.0.0/255.255.252.0
3942607374 vendor class: PXEClient:Arch:00000:UNDI:002001
3942607374 user class: iPXE
3942607374 PXE(eth0) 5c:f9:dd:e5:40:07 proxy
3942607374 tags: BIOS, eth0
3942607374 bootfile name: ipxe.kkpxe
3942607374 next server: 192.168.0.21
3942607374 broadcast response
3942607374 sent size: 1 option: 53 message-type 2
3942607374 sent size: 4 option: 54 server-identifier 192.168.0.40
3942607374 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
3942607374 sent size: 17 option: 97 client-machine-id 00:44:45:4c:4c:44:00:10:54:80:39:b7:c0:4f…
3942607374 sent size: 50 option: 43 vendor-encap 06:01:03:08:07:80:00:01:c0:a8:00:28:09:0e…
3942607374 available DHCP subnet: 192.168.0.0/255.255.252.0
3942607374 vendor class: PXEClient:Arch:00000:UNDI:002001
3942607374 user class: iPXE
2670414323 available DHCP subnet: 192.168.0.0/255.255.252.0
2670414323 vendor class: MSFT 5.0
2670414323 client provides name: PCAINF03.mad.mater.int
2203613339 available DHCP subnet: 192.168.0.0/255.255.252.0
2203613339 vendor class: MSFT 5.0
2203613339 client provides name: PCAINF03.mad.mater.int
4191863835 available DHCP subnet: 192.168.0.0/255.255.252.0

Am I doing something wrong ?

I am bit desperate here, have been trying different Kernels and initrd images, what would happen here ?

I was working perfectly win previous versions.

Switched to Kernel is 6.1.89 to avoid VM booting problem as per

https://forums.fogproject.org/topic/17663/capture-uefi-image-on-hyper-v-vm/2

Solved the VM issue but not the main one in this thread.

@Tom-Elliott I’ve been battling with this for a few days. This Kernel image solved the issue.

I should have said I am running 1.5.10.1662 on debian 12.

Before updating to this version, I was using Debian 11 with 1.5.10.10 and had no problems.
Thanks,

I hope you’re doing well. I’m seeking help with a PXE boot issue I’m experiencing. The system is encountering a “Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)” error, along with an “XZ decompressor ran out of memory” message, causing the boot process to fail.

The only troubleshooting step I’ve taken so far is updating to the latest development kernel, but the problem persists. I would greatly appreciate any guidance or suggestions you may have for resolving this issue, especially if there are specific configurations, settings, or other steps I should consider.

Thanks @Sebastian-Roth

Disabling the debug mode gave me a tip on the problem, as capture stopped with a failed to set permissions error.

In the end, I ended up narrowed down the problem to the type of filesystem presented to FOG from the KVM.

I had:

<filesystem type='mount' accessmode='passthrough'>
  <driver type='virtiofs'/>
  <source dir='/images/'/>
  <target dir='ximages'/>
</filesystem>

This is not quite OK for FOG, needs to be a raw disk presented to the guest. I changed it to a raw disk with :

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/disk/by-uuid/7c4cf625-18de-4bd8-852b-952b9bc7fdc5' index='1'/>
  <backingStore/>
  <target dev='vdb' bus='virtio'/>
  <alias name='virtio-disk1'/>
</disk>

And all worked just fine then. Looks like a /filesystem declaration is not a proper ext4 filesystem when mounting on the guest.

All is working fine now. Thank you all for your help.

Hi @Sebastian-Roth did you have the chance to see those 2 videos for capture and deploy ?

We are a bit stuck. Yesterday I tried reinstalling fog to no avail.

@Sebastian-Roth One more:

https://naks.es/downloads/fog-deploy.mov

Best, LP

@Sebastian-Roth Here you go:

https://naks.es/downloads/fog.mov

Hope this can clarify a bit.

Update:

I was suspecting the images folder mount into the virtual machine. I have unmounted the filesystem, and now I have the local /images file (no images there).

I still can’t capture images, no apparent error given, just the options to : ifconfig, gdisk, fdisk, fixparts, reboot. But no capture.

No ideas ? Troubleshooting tips ?

Hi all,

I recently migrated FOG (1.5.9.220) to KVM environment with images folder shared from a folder in the bare metal host.

I worked fine for some time. The host were is worked fine went belly up some weeks ago.

Not a big deal, I had a backup of both the guest KVM and the images.

Migrated all to new HW, fired up, working straight away. I can see the images folder from the guest (again shared via virtio from host), I can even create a new image (to be captured) of delete an old image.

However upon deploy, I get a “No image files found that would match partition to be restored” . The files are there. I’m puzzled.

Upon capture, all seems to go fine but when it’s time to start capture, I’m presented with a menu with options ifconfig, gdisk, fdisk, fixparts, reboot. And no capture.

What am I missing ? Thanks a lot in advance

@sebastian-roth Thanks Sebastian! That solved all issues!

Dear all,

I managed to migrate a FOG installation that had been running on a host with little or no problems for a good few years.

I managed to install and migrate database, all seems OK. DNS server A records for both fog and fogserver have been updated.

Also moved /opt/fog/snapins on to new system, but kept the newly installed /opt/fog/snapins/ssl directory.

Image deployment is working fine - or looks like so, client installation seems okay too (had a couple of “Can not install CA certificates” but not any more)

IP address / passwords have been updated as per the “Fix IP Addresses, Passwords, and Interface on new server” profedure.

However most clients show a red exclamation mark, a few show green.

I don’t seem to be able to send snapins of say shut down a host, unless I reinstall the client, then yes things seem to go back to normal.

Is there anything I am missing ?

Hi all, and sorry for any duplicate.

I have been generally lucky installing MSI snapins, but not with EXEs installers. There is currently no MSI for acrobat reader, unless you get a contract with Adobe I believe - I could be wrong.

I have tried installing the actual exe file with /sAll modifier for total silent install from a startup script via Active Directory GPO with success.

Trying to install AR via FOG snapin as a batch script, with the same option (/sAll) gets queued like for hours, I guess it stalls for some reason.

Anyone has had luck with Acrobat Reader ?

Thanks , all the best, Luis.

@Sebastian-Roth

Hi there.

I am using FOG on Debian 9. Previous install folder was /opt/fog, snapins are there.

Now that you say so, yes it’s possible due to a rsync that folder has been deleted.

I have recreated user & folder and looks like it’s working now. I get this error during install:

Locking fogproject as a system account…grep: /home/fogproject/.bashrc: No such file or directory
OK

Not sure it it’s important. Thanks so much for your help. Luis.

Hi there,

apologies if this is somewhere duplicate. I have recently updated from 1.5.5 to 1.5.7, all was fine in 1.5.5. Did not do any configuration changes during install.

Since update, I am unable to update or create snap-in that require a file upload, error reads:

Snapin Update Fail

Type:2, File: /var/www/fog/lib/fog/fogftp.class.php, Line:464, Message: ftp_login(): OOPS: cannot change directory:/home/fogproject, Host: 192.168.0.4, Username: fogproject

This path /home/fogproject has never been configured my installation (folder does not even exist), and can not find this config line in the fog options files. As a workaround, I have symlinked

ln -s /opt/fog/ /home/fogproject

and seems to do the trick, but would like a neater solution.

Anyone has an idea of where to cahneg that setting ?

Thanks a lot, best regards, Luis.