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

A couple of things here.

1. The linux service account was changed from fog to fogproject because there were bad instructions on the internet that said to create a user account called fog and install FOG using that account. The FOG installer takes over that account changing its password and effectively locking out the user. And/Or people would reset the password for the linux account fog and then just make a mess of things.

2. It sounds like the fogproject account doesn’t have write access to the /images directory. FOG uploads the captured image to the /images/dev share then logs into the FOG server (from the target computer) using the FTP program and uses the FTP server to move the uploaded files to the /images directory from the /images/dev directory. This is the point where the upload is failing in your message. You should see a similar error message on the target computer during image capture.

So for number 1 run through this tutorial and ensure the user ID is fogproject and the password matches the password found in the /opt/fog/.fogsettings file. https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

For the second issue what do you get when you key in these two commands. Post the resluts from both here.

ls -la /

ls -la /images

@Jpolk91 OK with the fogproject user set correctly then it must be a permission issue. Before we go resetting permissions at will lets confirm the issue.

From a windows computer use the command line ftp program to connect to your FOG server. use the login of fogproject and the password gleaned from the .fogsettings file.

Then execute these commands in the ftp session.

cd /images/dev
mkdir test1
rmdir test1
cd /images
mkdir test1
rmdir test1
exit

That is basically the permissions fog uses when capturing images. If you can’t perform the steps above then run these commands.

To reset the ownership of the files in the /images share you can run this command sudo chown -R fogproject:root /images

And then to reset the permissions (its a bit lax but will for sure fix any permission issue) sudo chmod -R 777 /images The -R means directories and all files below and 777 is read/write for everyone.

@Sebastian-Roth said in Unable to update Kernel after upgrade:

While George is pointing out the right configs to look at I think the issue is not about upload/download an image but only the error message initially posted about kernel update, right??

Ugh, I needed to “read” what it said vs what normally is wrong. Thanks Sebastian for slapping me back to reality, its still 2019 right…

There is/was a bug in FOG 1.4.4 where the permissions were not set correctly on /var/www/html/fog/service/ipxe to allow downloading of the kernels via the web gui. You could do this manually as root or sudo as root but not from the web gui. I would have thought a later fog installer script would have fixed that issue??

Lets get the output on the ipxe directory using the same commands we used on /images:
ls -la /var/www/html/fog/service
ls -la /var/www/html/fog/service/ipxe

We need to make sure that apache has write access into the ipxe directory for the web ui kernel updater to work correctly.

@Jpolk91 said in Unable to update Kernel after upgrade:

yep, that did it. I’ve got 5.1.16 (NVME fix) installed which is what I wanted since this machine has a (i think) newer NVME drive and figured it may help, unfortunately my image is still hanging so all that and still work to do but no worries there I’ll go make another post on that in the appropriate forum if I can’t get it going!

Yes please create a new post for this. There is a potential fix for this not related to the kernel. We do like to keep the problems and solutions to match the forum subject line so not to confuse future readers. The solution “depending on what the actual problem is” could be as simple as a kernel parameter change. Having pictures of errors will also help us understand the context of the error over just having the error message.

While I haven’t used virtualbox a lot, you do need to make sure the virtual box network adapter is bridged to the physical network adapter. You don’t want nat or local only (my words not VB)

@jhumpf said in Clients will not consistently boot into PXE environment - dnsmasq:

now its working just fine for some reason

OK great, now don’t change anything and you should be fine…

I’m glad you have it sorted out. Not sure if its really fixed or kind of working but we’ll take a win whenever we can get one.

@alesser said in PXE-Booting a Modern Ubuntu live CD via UEFI mode:

I simply want to boot a linux live CD in EFI mode when the option is selected, run a script, and then stop.

Reading between the lines here, I wonder if another approach would be better/faster/greener?

Let me tell you a bit how fog images computers. The iPXE menu in conjunction with the boot.php program send 2 files to the target computer with some kernel parameters that tell the target computer what to do. Those two files are bzImage (the kernel) and init.xz (virtual hard drive a.k.a initrd). Those two files make up the os known as FOS (Fog Operating System). FOG uses buildroot to construct the initrd as well as compiles bzImage.

So one might wonder, do you need a full commercial OS run your script or just a linux OS? Do you need a persistent disk storage or once the script runs can the virtual machine just disappear?

So the grey beard hacker in me wonders if you could take FOS Linux delivered by the FOG server to do your bidding? Unless you are doing something crazy (like vlans, wireless, packet filtering) FOG’s bzImage should do what you need. It supports both uefi and bios modes, as well as init.xz. FOG supplies both a 64 bit and 32 bit version of FOS Linux.

So how do you hack init.xz to not image your target computer? Simply unpack the inits https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Once you unpack the inits then look in the /etc/init.d directory for S99fog and delete it. Repack the inits and then pxe boot the computer again. Now you have a command line linux OS to play with that boots in under 15 seconds and disappears when powered off. The entire OS fits into 512MB of RAM, so its very VM friendly. If you need persistence memory just map an NFS share and grab your persistent data from there.

You might want to look into the /etc/init.d/S99fog file a bit deeper since you want to run a script the S99fog to do your task. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S99fog

Now what do you do if FOS Linux doesn’t contain the linux programs you need. Welp, then you need to turn to build root and build your own init.xz (initrd) file. No worries since the FOG Project also provides the buildroot config file and fs overlay you need in the github site. https://github.com/FOGProject/fos/tree/master/Buildroot

@stu Once you get the system registered, I’d like you to do something for us.

1. Schedule a capture/deploy it doesn’t matter, but before you hit the schedule task button tick the debug checkbox. Then schedule the task.
2. PXE boot the target computer. Plug a traditional keyboard in for this test.
3. After several screens of text on the target computer that you need to clear by pressing the enter key, you will be dropped to the FOS Linux command prompt in debug mode.
4. At the command prompt key in lspci and take a clear picture of the numbers it prints.
5. Plug in the KVM switch (but leave the traditional keyboard connected). Confirm that the KVM is selected towards the target computer.
6. Run the same lspci command again. Hopefully you have 1 or more new PCI devices listed. Take a picture of the new output (you can probably get both outputs in one screen shot as long as I can read the numbers we will be good.

The difference between the two commands will be the hardware IDs of the kvm switch. We can then take those IDs and confirm that the linux kernel supports the KVM.

Have you already moved the mysql server (service) to its own server instance and not running directly on the FOG server?

Is the disk where the database stored been moved to a flash based media (SSD or NVMe)?

Have you run the mysqltuner script against your mysql server? Have you implemented any of its recommendations?

In your installation, do you use the FOG client? If so what is the check in time you set?

@banana123 As a point of data collection, how did this disk get created in this state? This is not how the M$ installer creates the disk layout.

Through MDT its efi, c drive 99% of free, recovery partition 100% of free space.

Someone/thing had to create this format structure intentionally.

@Sebastian-Roth Collecting the pcap from a witness computer if the target is on a different vlan from the FOG server, or from the FOG server to get the best info if the target computer is on the same vlan as the FOG server.

@fernando-martinez if your target computer is on a different vlan than the fog server install wireshark on a witness computer and use the capture filter of port 67 or port 68

If the target computers is on the same subnet as the fog server then use the instructions in the tutorial.

Upload the pcap to a file share site (i.e. google drive, dropbox, etc) and share as public read. Either post the link here or DM either Sebastian or myself and we will look at the pcap and tell you what we see. Be sure to use the capture filter outlined so we do see things we shouldn’t in your packet capture.

@fernando-martinez I’ll be able to look at the pcap file in detail in a few minutes.

The first pass at it I see a problem. The client is asking for undionly.kpxe.0 which is an indication that you have a version of dnsmasq on your fog server that is older than version 2.75. Older versions than that always appended .0 for some legacy reason. You should upgrade to a newer version of dnsmaq, but you can trick it by creating a sym link between undionly.kpxe.0 and undionly.kpxe in the /tftpboot directory. You will need to do the same for ipxe.efi to ipxe.efi.0

@SBrady Looking at your pcap, you have 3 servers responding to the bootp request from your target computer. It appears the real dhcp server is at the .181 address and the 2 proxyDHCP servers are at .44 and .45. Both of the proxyDHCP servers are overriding what your main dhcp server is telling the target computer for where to get the boot file from.

I can’t tell from the proxyDHCP response what type of computer it is. The response doesn’t look like a Microsoft SCCM or WDS response because it is so short. I would focus on what .44 and .45 are and why they are responding to the bootp request.

Edit: Looking a bit more into the pcap there is also a WDS server responding to the DHCP DISCOVER query at the .217 address. That makes a total of 4 dhcp (and proxy servers responding) overriding what the main dhcp server was sending for dhcp options 66 and 67.

Ok we have a solution here after debugging and chatting for quite a bit.

This Yoga L13 has a built in network adapter that is connected to ethernet through a port replicator/dongle. It is not a USB/USBC type adapter its just a port replicator.

Debugging showed us that two nics installed.

Network Controller 8086:02F0
Ethernet Controller 8086:0D4F

The 8086:0D4F ethernet adapters comes back to a Intel I219-V. Looking at the kernel driver database that network adapter was first added to the 5.5.x linux kernel. Both 4.19.101 and 5.1.6 kernels that the FOG Project offers are too old for this hardware.
ref: https://cateee.net/lkddb/web-lkddb/E1000E.html

To test/solve this problem I built a one-off linux kernel v5.5.3 using the FOG configuration file from a recently create one off kernel I had for Mac T2 workaround. The 5.5.3 kernel built ok and tested ok in the OPs environment. With the 5.5.3 linux kernel the target computer was able to complete a full registration and the OP said he was going to test imaging later.

So for this issue the answer was to create a one off kernel of version 5.5.3 until the FOG Project releases an official kernel that is at linux version 5.5 or later.

@Sebastian-Roth The driver was enabled. The issue is the hardware ID were not in the driver. It was introduced in the 5.5 kernel. So I took the same config I used for the 5.4.6 one off kernel I used for the Mac T2 chip work around and just recomplied it with 5.5.3. No changes were made to the config file other than opening it with make nconfig and then saving the config to strip out any deprecated settings.