Posts made by sonic136

Solved. It was the init.xz file that was customised for our environment, The default was applied and seems to be working now.

Hi Fog community

We have just upgraded our fog application from 1.5.9 to 1.15.10.

After the update, we are now unable to boot our client machines to pull an image from the fog server.

We assume that all the settings would have stayed the same as prior to the update.

The error on the client machines is as follows:
Kernel panic - not syncing: UFS: Unable to mount root fs on unknown-block(1,0)
Kernel Offset: disabled
-[ end Kernel panic - not syncing: UFS: Unable to mount root fs on unknown-block(1,0) 1

we have no idea how to fix this.

@george1421 We have assigned a new flag and applied the ipxe.efi file to the flag. Seems like it has worked.

Thank you @george1421

@george1421

yes, the BIOS is set to use UEFI mode only, and the NIC is set to first boot in the priority. We have complied the lastest build and still not able to successfully PXE

Hi fog community

We are unable to PXE boot to fog on an Asus B660 m-c motherboard.

We are running 2pxe files - namely, the snponly and undionly - these files are linked to flags on the network - the flag system works perfectly.

The machine BIOS has been updated and is set to network boot.

It seems like the drivers for the B660 are not included in the efi file set.

Is there any way to get the boot files loaded and to get the machine to PXE boot?

We had to enable 2 flags on the network side of things a C flag has been set to ipxe.efi and a d flag as been assigned to snponly.efi. when a new machine comes in, its registered on the network and assigned either one of these flags. The machine then “knows” to pull the corresponding file for a successful PXE boot.

turns out that the image had to be set to “Multiple partition image - single disk (not resizeable)”

@Sebastian-Roth for future reference, I will be sure to mention version numbers

Everything else worked including the .xml file.

Thank you for the assistance!!

Hi there

we’ve experienced similar issues. We updated the BIOS to the latest stable version - do version-by-version to avoid bricking the machine. Then:

1. disable secure boot
2. make sure that the boot order is set to PXE first (for obvious reasons)
3. set the boot mode to UEFI boot as the partition is set to EFI mode - as seen in the disk management screenshot (partition 1)
4. perhaps try to move your efi partition to the end of the disk - download gparted and make it a bootable flash/thumb drive and you will be able to move the efi partition. you’d want to see your disk looking something like this (attached

boot see what happens?.. ps it of course goes without saying that you should backup your image/disk before playing around with the partitions…

Good day Fog community

I have an image that is not capturing to 100%, it stops and 99% and stays in the active task list. The machine reboots and goes into a BSOD loop.

When checking the image size (size on client), it tells me its 500mb - this seems to me that its the System reserve partition ( its first in the partition table)

The image itself on Fog is set to capture the whole disk “partition = everything”, the "image type = single disk- resizeable.

The same thing happens whether capturing from a VM or a physical machine.

Before closing the image, a chkdsk /f is run and machine rebooted successfully.

Then a .bat file that links to an .xml file that runs specific closure commands ( this process works perfectly for other images)

We have 2 storage nodes - both with more than enough space to hold the image. The above mentioned happens when changing the storage location “image path”

What or where can I start looking for a solution to capture the image to completion (100%) and stop the machine from BSOD boot looping.

Please let me know if you; the community, needs some screenshots or more info, happy to share!

SOLVED! Thank you for the assistance!

@sebastian-roth Upon further investigation, it turns out that older boards dont really like the snponly.efi when PXE booting.

The machines just hang on the PXE boot screen and does not boot to Windows. The snponly.efi if default (I.E, no changes made).

This machine worked with the ipxe.efi file applied to it.

Are/ is there an option that will work across the all types of motherboards? old to new or is there something in the snponly.efi file that needs to be changed or added for the machine to complete pxe booting. side note: pxe boot - no image applied, just needs to boot to windows, but if there is an image applied then obviously the machine will complete the PXE command and the machine will begin the re-image sequence.

Hi

Thanks for the guidance, the file changes have worked!

I now have another issue related to this, how do I get my EFI files to a thumb drive?

I have a test network running that does not have any flags set, so a thumb drive is used to get to the fog console where images can be selected. Seeing that the changes have been made to /tftpboot can the efi files be updated on the flash drives for my support team to use on these new motherboards? If so, how?

Hi Community

I have an Asus B560m-k motherboard with the latest version of BIOS patch. The settings for network boot is correct as it boots to the Fog tasked sequence. It then gives the attached message and then loops back.![alt text]

The Fog kernel has been updated to 5.10.50 TomElliot64 and is on version 1.5.9.

How can this be fixed?

The image that needs to be loaded is UEFI enabled (it has to be this way as the new Windows LTSC version will require this) . The machine also has a single m.2 1TB installed.

@sebastian-roth Thank you. Will look into it!

Good Afternoon Community

We have 2 nodes (a nas with slower HDDS and a node in a DC with SSDs)

We use the nas storage for building and testing images, after this are forced to re-deploy our golden image and then re-capture the image on Fog.

Is there a way to move the captured image from one storage node to another.

Both the nodes are set to master so im not sure if the replication would work (as read on a different thread).

Is there a feature in the console that would allow the moving of images from dev (nas) to production (DC storage)

Thanks All!..

Solution has worked perfectly!

@Sebastian-Roth Thank you

What option would i select here then when creating a capture image?

Hello Forum world

I would like to find out if its is possible to do Single Partition Imaging.

Scenario

We have a 2Tb HDD partitioned 50/50 I.E C:\ and D:\

We only need to image C:\ without loosing data on D:\

Would time image have to be closed (syspreped) differently?

How would i go about imaging only C:\ partition?

@george1421 Fog is a waaaaaaayyyyyyyyyyy better fit than Zenworks at the moment, it images 4x faster and its more stable. Fog is actually working very well without these refinements that I want to do

@george1421 the sites and locations wont work.

we also have multiple images for various locations. ie. library, library training room, law, general lab and so on…