@Junkhacker @Sebastian-Roth

I was able to get the OP going by doing this and that.

We are not sure if it was this or that that got the kernel to boot. What I did was unlocked the max CPUs (that was capped at in the kernel and I also enabled almost all of the ACPI modules in the kernel. We also tried the acpi_osi=Linux kernel parameter.

We ruled out the acpi_osi=Linux kernel parameter fixing the issue so it must be something I enabled in the kernel. Tomorrow AM I’m going to reset the kernel environment and only unlock the max CPUs. The OP is going to test that new kernel to see if it was unlocking the max cpu or it was the acpi modules I enabled.

Either way I’ll report where we ended up and which kernel change fixed the issue. I have also seen other recent CPU stalls like this that was fixed by setting acpi=off so we may need to move what ever fixed the issue into the main kernel build because new hardware/cpus may require it.

The issue ended up being a configuration problem with the dhcp server. Once that was straightened out the target system pxe booted like expected.

@robbit ok I just assumed since most people install ubuntu for some reason you had that. Let me translate it for centos (what I use)

yum update -y
yum install git -y
git clone https://github.com/FOGProject/fogproject.git /root/fogproject
cd /root/fogproject/bin
./installfog.sh

So its not staring WinSetup/OOBE at all? Only loops at reboot?

So the image you captured was it from a bios based VM or a uefi based VM?
The target computer you are deploying to, is it bios (legacy) or uefi based?

You can only deploy bios captured images to a bios based computer and the same thing goes for uefi.

FWIW, I develop my reference images on a VM and deploy them to physical computers. Our current base image is based on 1903 and it works fine when captured from a VM and deployed to a physical computer.

@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73

Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers.

If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address.

If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161

@Gamienator said in Choose the right location on PXE Boot - Is that possible?:

Wouldn’t it be possible to automate the meta data sync? I’m thinking of using the FOG API. It should be possible to grab all the needed Information and then update it on every other FOG server in the different locations.

The short answer is yes. The longer answer is that it will take a programmer to write an external application to query the api on the master node and then on the remote node to update. This probably could be done in powershell, but to make the finished product useful to the fog project writing the data migration module in php would be the best. Then at least we could setup a cron job to run the php script and migrate the data that way. It would be a bit of giving back to the fog project if you were so inclined.

/images != /Images linux is case sensitive. It appears that /images is on your root partition that is why fog is reporting 45GB. /Images (upper case I) is where your big disk is.

For this specific host manually register it and then in the host definition add the following to the kernel args field acpi=off. Lets see where that gets us.

@Brad-Schumann said in Blank Screen with Blinking cursor in top left corner:

Would a Windows, bios or driver update have this affect

The short answer is no. Older firmware on the target system might. So just for additional clarity the 5570 is in uefi mode? If so then we have an issue with rEFInd executable not finding the disk controller. When the FOG iPXE menu exists it calls refind to locate the hard drive boot device to boot the target computer.

You really didn’t supply enough information but looking at the error I can give you a direction to look in.

The error is http://192.168.2.10/bootimgs/18.04/casper/vmlinz… does not exist.

So that means you are using the http protocol which has a base directory of /var/www/html/fog from that directory bootimgs/18.04/casper/vmlinz needs to exist. Just looking at the directory you provided there is no base references but I see Ubuntu directory of 18.04_64 which if you translate that to the file not found path 18.04_64 != 18.04 assuming the base path was /var/www/html/fog/bootimgs

@humoss233 I recompiled the kernel last night after my post with the dm_crypt enabled. Give me a minute and I’ll upload it where you can get to it.

https://drive.google.com/open?id=1N6q6Oqmi7W7WkdtNPK1H0O8B1f-a4RFU
Note to future readers I may remove this file at any time so the link may not be valid in the future

To use this new kernel, download it from the link and save it in /var/www/html/fog/service/ipxe directory on the fog server as bzImageCrypt Then manually register one host and then go into the web ui in the host management for this target system. Update the kernel field with bzImageCrypt (watch the case because it IS important). Save the host management page and then schedule another debug capture. Then test your commands again with the modules loaded into the kernel.

ref Kernel patch file for differences between standard config and dm_crypt added config

--- kernelx64.config    2019-08-29 12:46:58.222184653 -0400
+++ .config     2019-10-20 00:20:29.579817034 -0400
@@ -1273,12 +1273,17 @@
 # CONFIG_BCACHE is not set
 CONFIG_BLK_DEV_DM_BUILTIN=y
 CONFIG_BLK_DEV_DM=y
-# CONFIG_DM_MQ_DEFAULT is not set
+CONFIG_DM_MQ_DEFAULT=y
 # CONFIG_DM_DEBUG is not set
-# CONFIG_DM_UNSTRIPED is not set
-# CONFIG_DM_CRYPT is not set
-# CONFIG_DM_SNAPSHOT is not set
-# CONFIG_DM_THIN_PROVISIONING is not set
+CONFIG_DM_BUFIO=y
+CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING=y
+CONFIG_DM_DEBUG_BLOCK_STACK_TRACING=y
+CONFIG_DM_BIO_PRISON=y
+CONFIG_DM_PERSISTENT_DATA=y
+CONFIG_DM_UNSTRIPED=y
+CONFIG_DM_CRYPT=y
+CONFIG_DM_SNAPSHOT=y
+CONFIG_DM_THIN_PROVISIONING=y
 # CONFIG_DM_CACHE is not set
 # CONFIG_DM_WRITECACHE is not set
 # CONFIG_DM_ERA is not set
@@ -3424,8 +3429,6 @@
 CONFIG_HAVE_ARCH_KASAN=y
 # CONFIG_KASAN is not set
 CONFIG_ARCH_HAS_KCOV=y
-CONFIG_CC_HAS_SANCOV_TRACE_PC=y
-# CONFIG_KCOV is not set
 # CONFIG_DEBUG_SHIRQ is not set

@humoss233 I’m not sure this will work, since you are linking the /dev/md126p3_crypt to /dev/md126p3 then deleted it and then recreating it as itself. You are kind of looping back to itself. I can see a circular link here.

I wonder if you can rename /dev/md126p3 right from the start to /dev/md126p3raw and then do your cryptsetup against the renamed raw device and linking.

@humoss233 Here are the inits that should have openssl application. For full disclosure I haven’t tested them myself yet, I ran out of time today. I’ll load it onto my usb stick in the morning USA time. But if you want to try to see if it works: https://drive.google.com/open?id=1OnVpqqGnFkVkS19B4OwNxP2FMoyustwT

You will just download them as initCrypt.xz and save it in /var/www/html/fog/service/ipxe directory. Then go into the host definition and add into the init field initCrypt.xz. As I said I don’t know if it will boot correctly (it should) but it also should have the openssl executable installed.

@Sebastian-Roth said in After 100% capture failed on database updaet.:

Upload of images always go to the master node.

From what I’m told, there is a way to configure fog to send its images to a storage node.

You need to have the location plugin installed and you need to create a new storage group. Place the remote server (i.e. storage node) in its own storage group as a master node. It can remain part of the default storage group as a storage node so it gets image pushed down to it.

Then make sure when you setup the image you pick the remote storage group to place the image. I think that’s how it goes.

@Sebastian-Roth said in Error decrypting LUKS partition prior to capture/imaging:

Should we add this to the official FOG kernel/init?

(??)

I’m seeing this as still a one off situation. Until now I didn’t know LUKS partition encryption existed. I can say if we see more requests like this we can add it to FOS Linux. I added the patch files here so the changes don’t get lost with time.

From a size perspective the added openssl executable is minimal as well as adding in the crypto drivers into the kernel. Looking at buildroot images directory I see the uncompressed inits at 268435456 and compressed 19986704. I would have to recompile it without openssl to give you a (like for like) comparison. So the question from a developer standpoint is there any additional utility can FOG get from including the openssl executable? The openssl libraries are already included in FOS Linux for other reasons. Are we passing things between FOS and FOG today that should be protected a bit better in the future? Possibly in 1.6.x it would add some value (??)

On your old FOG server you need to copy over the certificates to your new fog server. Then reboot the new fog server. I don’t know the path off the top of my head but it should be in /opt/fog/snapins and maybe ssl directory.

@Gilberto-Ferraz said in Upload Image From HDD 500GB to SSD 120GB:

@Sebastian-Roth Hello, thanks for the help!
I am afraid to upgrade to version 1.5.7 I am afraid of losing access to the images and inventoried hosts.

Do I get all this after the upgrade?

Unless you do something really bad, upgrading will only extend the sql database schema and not replace any of its contents. So upgrading will not loose any data or images on your fog server. The upgrade process does not touch anything in your /images directory either. While anything is possible historically we have not seen any such loss. If you are at all concerned make sure you have a backup or snapshot of the FOG server so you can restore it.

@holydonut Well I don’t have good news for you, because I just stood up a win10 1903 Pro CBB machine and the VM boots into the fog menu and compatibility check under hyper-v without issue. Now understand there may be windows updates pending. But on a fresh build it works out of the box.

@EBCF I’m pretty sure its related to not having a null terminated string.

Some pxe boot firmware will take the byte count (in this case 0x0d) and others need a null terminated string and just ignore the byte count. Its kind of a toss up.

So what can you do? Well you can install dnsmasq on your fog server to supply the pxe boot information and then just ignore your dhcp server for pxe boot information. That is what I do at home with my soho isp router. It sends out itself as the bootp server for some stupid reason. I use dnsmasq on the fog server to override it. I have a tutorial on installing dnsmasq on the fog server if you need it.

@Baessens So the point at which its hanging is when iPXE is transferred to the target computer. Nothing else with FOG is in play at the moment.

So it may be the version of undionly.kpxe that is working vs not working at the other location. Or the version of hypervisor being used.

So a quick test would be to copy undionly.kpxe from a working site to a non-working site. The files are in /var/www/html/fog/service/ipxe directory. Lets start here and see what happens when the file is copied.