Best posts made by george1421

@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.

@Sebastian-Roth I realize we are discussion nvme drives here and only for a point of reference, but in 2017 I created a benchmark post to compare the differences in different technologies (one being disk subsystem) and its impact on imaging. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast/6

From there I had these two commands:

… the simple disk baseline I’m using the following linux command to create a sequential 1GB file on disk and then to read it back. This process is designed to simulate the single unicast workload. The command used to write the 1GB file is this:
dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=direct
The command to read it back is:
echo 3 | tee /proc/sys/vm/drop_caches && time dd if=/tmp/test1.img of=/dev/null bs=8k
The echo command is intended to disable the read cache so we get a true read back value.

@Sebastian-Roth I pulled the latest FOS files from the github repo and built this: https://drive.google.com/open?id=1eHF9HlTEGlWPYXpfcmvuV0CcqCIV1pyr

I confirmed that the bin files were updated. One note, you have to remove the 0.2.89.x patch or partclone.0.3.12 will not build correctly (it could have been residue from a previous build too). Once the patch was removed and the build restarted it completed without error.

@OP Download the new init and save it as initFIX01.xz (watch your case, because it is important) and move it to the fog server in /var/www/html/fog/service/ipxe directory. Go into the host definition for the one in question and enter initFIX01.xz for the init field parameter, save the host definition and then schedule a new capture/deploy task. PXE boot the target computer, if you look quickly you will sett it transfer bzImage and then initFIX01.xz to the target computer then start FOS Linux. As long as you see initFIX01.xz being downloaded then it should be running the updated scripts that Sebastian created.

I believe the wiki page is based on my tutorial page: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

If you use my dnsmasq configuration file exactly then it will work. In my config file make sure you replace <fog_server_IP> completely with the IP address of your fog server. It appears several places in the config file.

Understand out of the box dnsmasq will only work when the pxe booting client and dnsmasq server are on the same subnet. If they are on different subnets then you will need to update your dhcp-relay/helper service on your subnet router. Add the fog (dnsmasq) server as the last dhcp server in the dhcp-relay list. This will make the dnsmasq server aware of the dhcp requests from other subnets.

If you still can’t get it we can debug the dhcp/pxe boot process pretty easily.

@kmonroe79 said in Starting cmain( )...:

However, my Lenovo M73 desktop gets hung up on reboot with the following message: Launching GRUB… begin pxe scan … Starting cmain

I would recommend that you set the BIOS exit mode to SANBOOT and only use GRUB if SANBOOT is giving a problem. The default for uefi is rEFInd. If refind has issues there is a config file you can use to boot. But circling back SANBOOT works for 99.5% of the bios based systems just fine.

@Peter365 I’ve got a different tutorial, lets run through this and see if we can resync the passwords. Something has gone astray with the service account: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

When you complete the process, you should be able to log into the FOG server using command line FTP from a windows computer (Filezilla should work too, but I’ve only tested with command line ftp). Use the user id of fogproject and the password found in the /opt/fog/.fogsettings file. If you can get logged in via FTP with that account and you have all of the spots in the web ui matching, the capture should work well.