Best posts made by george1421

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.

I guess a few things we can try.

1. If you switch to bios (legacy mode) is the hard drive discovered?
2. Does in your bios can you change the disk mode to ahci? Does that provide any usable information?
3. You were able to issue the lsblk command and no disk was visible, what do you get when you issue lspci -nn hint if you want to make it easier to copy and paste commands into debug mode do the following.
   3.1 PXE boot into debug mode as you have done before
   3.2 Give the root user a password with passwd make it something simple like hello
   3.3 Key in ip addr show and get the IP address of the target computer.
   3.4 Use putty or other ssh application to remote into the target computer as root using the password and IP address you collected above. Then issue the lspci -nn command via putty. With putty you can copy and paste the output easier. Posts the output of lspci command here
4. Please tell us the version of FOG you are using
5. What version of the FOS Linux kernel are you using?

@rogalskij https://drive.google.com/open?id=1thopskSYJd7ueDQeFg_VT4eeNcrNHvIx

Download this as bzImage553 and move it to the fog server in /var/www/html/fog/service/ipxe directory. Then go into the host configuration and add bzImage553 to the kernel field.

Its interesting to hear you have this slowness from 1.5.7 to 1.5.7.102.

If the kernel doesn’t fix the issue lets do similar to the other thread. In your case lets download the 1.5.7 kernel and inits to see if the speed changes between 1.5.7 and 1.5.7.102 as you said.

For part 2 of this test download this zip file to your windows computer. https://fogproject.org/binaries1.5.7.zip

Extract bzImage and init.xz from the zip file (you only need these specific files) and move to /var/www/html/fog/service/ipxe directory on your fog server. This will overwrite the FOS Linux files from 1.5.7.102. Now attempt to image one of those impacted systems. While imaging pay attention to the blue screen that has the bargraph. This is the partclone screen. Please record the version of partclone you see. It may be 0.2.89 or 0.3.11 or something else. I’m curious to see if updating partclone did something unexpected. Does restoring FOS Linux back to 1.5.7 resolve the slowness issue??

To restore the 1.5.7.102 kernel and inits we’ll just rerun the installer. The 5.5.3 kernel will be safe since we called it bzImage553.

@rogalskij in the host definition for that specific computer (via the web ui) go to that target host. On the main page there is a field called kernel. In that field enter the custom kernel name bzImage553 (watch your case). Then capture/deploy the image. When you pxe boot the computer watch the iPXE screen you should see it transfer bzImage553 to the target computer along with init.xz

@Sebastian-Roth Thanks… I JUST finished reverse engineering the answer…
I happened to come up with the same answer too…

vi lib/fog/service.class.php

        $types = array(
            'sanboot',
            'grub',
            'grub_first_hdd',
            'grub_first_cdrom',
            'grub_first_found_windows',
            'refind_efi',
            'refind2_efi',
            'exit',
        );

and vi lib/fog/bootmenu.class.php

        $refind2 = sprintf(
            'imgfetch ${boot-url}/service/ipxe/refind2.conf%s'
            . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi',
            "\n"
        );

        self::$_exitTypes = array(
            'sanboot' => $sanboot,
            'grub' => $grub['basic'],
            'grub_first_hdd' => $grub['basic'],
            'grub_first_cdrom' => $grub['1cd'],
            'grub_first_found_windows' => $grub['1fw'],
            'refind_efi' => $refind,
            'refind2_efi' => $refind2,
            'exit' => 'exit',
        );

systemctl restart httpd

@Sebastian-Roth Both Pi2 and Pi3. But I never used the udpcast from my FOG-Pi servers. I do have a solar powered FOG server though.