Best posts made by george1421

@jflash In the computer’s firmware setting switch the disk mode from raid-on to ahci mode. That will unhide the disk.

@c4c The screen doesn’t wake up. I think I was focused on you adding things to the init based on your post subject.

You have to remember that FOG is intended for hit and run computing. It boots, it images, it reboots. There is no time for sleeping.

With that said I’m betting there are bits missing in the linux kernel, since the kernel is responsible for managing the computer’s hardware. The FOS Linux kernel is not a general purpose OS, its customized specifically for imaging (hit and run and run computing).

If it doesn’t come out of sleep then I would look at the ACPI settings in the kernel config. These values are not enabled in the FOS Linux kernel.

It may also be a display driver. If you want to go down this path (and learn a bunch more). (I would first just turn on all of the apci functions and rebuild the kernel to see how it goes then do the hard parts [next]) Load a full linux distro onto this hardware. Then run this command lsmod This will list all of the kernel drivers that are running. You will need to look at each one to decide what they do. There may be one specific for either the display or possibly back light that needs to be included in the FOS Linux kernel.

One thing you need to know about linux, you can either have dynamically linked drivers or integrated (compiled in). For speed and simplicity FOG uses compiled in select drivers, a traditional linux OS will typically used modular drivers to support a larger fleet of compute functions. The lsmod command will list those dynamically linked modules. You can not use the lsmod command to find the names of the compiled in modules, but there are other ways to determine that.

Building the linux kernel is much like building the initrd file with buildroot. The process is similar so what you know now will help you with the next phase if you want it.

@c4c Well that’s great you found a new way to extend fog beyond how the developers imagined it. Well done.

Through some testing I found that while FOS Linux is its own operating system it most closely resembles Ubuntu 16.04 in its libraries as shipped. So, I found that precompiled applications for Ubuntu 16.04 seem to work on FOS Linux built on buildroot 2020.02. So if the application you need is not in the buildroot catalog sometimes you can borrow it from other sources precompiled.

@c4c OK, Firstly I’ve detected you are a bit more advanced since what you have done so far. If you are not familiar with linux then don’t follow these directions since there will be holes and its not a complete step by step only a direction of the path you need to walk.

first let me say my buildroot environment is setup differently than the way the dev’s setup their buildroot environment. Mine’s different because I build other embedded OS images outside of FOG.

First you will need a linux computer to build the buildroot environment. Use current release of debian [10 or 11] or ubuntu 20.04 and install the build essentials package.

For FOG 1.5.9 use this version of buildroot: https://buildroot.org/downloads/buildroot-2020.02.tar.gz

Expand that tarball out to a working directory (i.e. ~/work). In the same working directory ~/work clone the FOS Linux repository on github. git clone https://github.com/FOGProject/fos That will create a fos directory (~/work/fos).

Copy ~/work/fos/Buildroot ~/work/buildroot-2020.02

edit ~/work/buildroot-2020.02/packages/Config.in add in the section from ``~/work/buildroot-2020.02/packages/newConfig.in` into near the bottom of the Config.in. This will add in the FOG package options into the buildroot menus.

Lastly you need to copy over the fog settings for buildroot into your buildroot tree.

Copy ~/work/fos/configs/fsx64.config to ~/work/buildroot-2020.02/.config (yes the hidden config file that starts with a dot).

Once you have everything in place from the buildroot base directory (~/work/buildroot-2020.02) key in make nconfig (you might get an error about missing libraries here, go back and load them then run it again).

You should now be in the buildroot configuration menu. I want you to check to see if the FOG package menus are listed and they are checked. This will confirm you have setup everything needed correctly. I know this is a lot of manual setup work, but in the end it will allow you to start at the same point FOS linux is for 1.5.9.

The FOG added in menus will appear as this:

Save the settings in the buildroot menu configuration and exit.

Now key in make -j4 and that will start the process. If you have more than 4 processors you can increase the number of threads to use to decrease the build time. The first time through it may take 1hr to build the init.xz file. This is because its building all of the programs needed to build the init.xz file. On the second run it will be much faster since its only building the programs needed to build the init.xz file.

Once the init.xz file is complete move it to the FOG server as init_test.xz (to not mess up the fog provided init.xz file). Now for your test target computer, go into the host management page for this specific computer and insert init_test.xz into the initrd field for this computer, save it. Now pxe boot the target computer, pick like hardware verification, watch the screen quickly as it will transfer bzImage and then init_test.xz to the test computer. If it does transfer init_test.xz then you have FOG configured correctly.

This first run don’t change any settings from what the FOG developers have provided. You want to test to make sure you can successfully build the init.xz file. From that basis then you can make changes to the configuration using the make nconfig command. If you need to include files or stuff into the init.xz file you can add them to the ~/work/buildroot-2020.02/board/FOG/FOS/rootfs_overlay directory structure. These files get copied into the init.xz file as its being created. Any tweaks you did by unpacking the init.xz file can be inserted here.

I know this is A LOT of information, because buildroot IS very complex. BUT you can modify the buildroot packages to include to give you the exact initrd you need.

@c4c If you need to add functions / additional programs into the inits FOS is built on buildroot. If you are extensively tweaking the inits, there may be value in setting up a buildroot environment to rebuild the inits with your added in modifications. While this is not hard to do, it does take a little time and then the first build while creating the toolchains will take some additional time.

If you need to go this far I can give you some guidance.

@rogerbrowntdl said in PXE Issue Ubuntu 20.04:

for future proofing if I extend the VHD on hyper-v to say 500gb

Unfortunately that was one of the options I didn’t feel would add value. I must have done a bad job of explaining the situation. My suggestion was to live in the walled garden that has been created for you until you grow out of it or rebuild from the ground up.

The ubuntu/OS disk only should consume about 30GB of space. I would suggest that you make it 50 GB for updates and whatnot. This is before you even load fog on it. Your Ubuntu install uses something called LVM (logical volume manager), which is a good thing, but in this instance it gets in the way.

Your current situation is that the ubuntu install has created 3 partitions on that current vhd. You have boot, swap, and then partition 3 where the root file system is (think windows c drive). On that 3rd partition is a LVM volume. That lvm volume is using 62GB of the 125GB volume… <thinking>

Edit: OK this may be the solution here to salvage what has been created for you.

On your /dev/sda3 (third partition on the first hard drive) it is 125GB in size. The lvm volume group (think of it as a virtual virtual disk) ubuntu–vg and lvm logical volume (think of it as a virtual virtual partition) ubuntu–lv (isn’t abstraction great!!) is only consuming 62GB of that 125GB physical partition.

So the first thing we need to do is backup or snapshot this VM, because the next steps could be destructive.

Goal here is to extend the VLM volume ubuntu–vg to the extent of the physical partition /dev/sda3 (this partition at the end of the disk will allow us something usable in the future.). I’m not sure that the logical volume group needs to be extended, but I think yes. I would try to extend the logical volume first and if it complains then extend the lvm group. I did find a tutorial on how to do this and its use case fits pretty closely with your situation. See ref below.

You should be able to start with the section Modify (extend) the LVM: In this case they reference /dev/vda1 you should use /dev/sda3 so your extend command should look something like this (follow along with their tutorial) sudo lvextend -l +100%FREE /dev/ubuntu--vg-ubuntu--lv (get the value from the lvdisplay not trust what I glued together. If all goes well it should extend that 62.8GB LVM to 125GB. You should use the lsblk command to confirm this happens. If it works correctly your root file system should grow from 62GB to 125GB after you run the resize2fs command.

If that works then it puts you in an OK place. Because if you need more than 125GB for images then you can extend the VHD file (leaving room after /dev/sda3. You can extend /dev/sda3 partition and then repeat the same process as above to extend the LVM to the new size of /dev/sda3.

While the above is surely possible I don’t know which would take more time, simply spinning up a new fog server as I mentioned before with a 50GB hard drive then before adding FOG add a second vhd and linking it into the /images directory before installing FOG, or just extending the VLM volumes.

ref: https://carleton.ca/scs/2019/extend-lvm-disk-space/

@joanmarzo ?? OK but I don’t think the problem is FOG but if you want to reinstall that is your choice. We will be here to help if you need it.

@rogalskij I can say based on HTML, in theory it can be done. From a HTML/CSS perspective the programmers can just defined the field as password and the browser will encode the password so it can’t be viewed. If we can point to the fields that need to be protected we can submit a feature request. I don’t use that feature in FOG so I don’t know what fields need to be protected other than what you’ve mentioned.

@joanmarzo Laptop bios/firmware settings.

@sebastian-roth said in How to disable "password viewing" in the web UI:

Not sure I get what you mean

I’m not totally sure either… I should have looked at the code and not guessed. Its good the OP was able to point to the screen with the visible password.

@sebastian-roth said in How to disable "password viewing" in the web UI:

There is no real concept of roles in FOG. So any FOG web UI is more or less an admin.

Could we do something like this? https://www.csestack.org/hide-show-password-eye-icon-html-javascript/ where the field would always be protected but the FOG admin could click on the eye to display the password?

FOG already uses font awesome library. But I might have a simplistic view of the problem because I don’t know the code.

@rotoi I just thought of something else to try to totally remove ipxe from the picture (just in case its leaving something behind causing issues. I don’t think so, but we never really know).

I have this tutorial on how to usb boot into iPXE: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

The idea is if we exchange ipxe.efi in this tutorial with the refind_x64.efi file (renamed according to the tutorial) then you should be able to boot into refind from the usb stick. You might get a warning because the config file is missing, but lets see if it get past initialization bit.

@rotoi Actually that is the easiest way.

When you get the hit s for command prompt, do that.

At the command prompt key in exit 1 and press enter. If that doesn’t work then try exit 2. This is just an experiment to see if what I read is accurate.

exit is a built in command into iPXE, where refind, ipxe chainloads refind.efi and lets refind boot the system. Exit and SANBOOT are built into to iPXE.

@elogan Ok that was the link I was going to give you. You can not connect through the fog server, but you can setup a synolgy nas as a “fake” fog storage node.

@zaboxmaster Just a bit of clarity that tutorial creates a usb bootable flash drive that uses grub as the menu manager not iPXE. We might use that if ipxe has a hardware compatibility issue with the target system. Or the system doesn’t have a network adapter that supports ipxe.

This tutorial here uses iPXE on a usb drive to jump into iPXE. https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way In this case it uses ipxe.efi file that is renamed to bootx64.efi . You could use this process with snponly.efi or snp.efi. Just rename the file accordingly. In your case you probably want to use snp.efi. Consider where ipxe.efi contains all known drivers for most network adapters, snp and snponly only contains the snp network driver that uses the network adapters built in firmware. But that should work.

Reading between the lines here, you might want to update ipxe to the latest version to support newer hardware than FOG 1.5.9 when it was release: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@tyrel-sonohara said in Max clientes Storage Node:

By default, the defaultmember node’s max clients have a value of 10. Can I simply increase this value if I want to deploy to more than 10 computers at the same time?

The quick answer is yes to increase the number to deploy to more clients.

A bit longer answer is that if you are deploying to more than 3 unicast images at the same time you will saturate (fill up) a 1GbE network connection. Depending on how fast your storage disk is in your server you will saturate your disk subsystem at 6 unicast image deployments at the same time.

So to your question if you need to deploy to more than 10 computers at a time you should use a different FOG imaging technology called multicast image deployment. In this case the fog server only sends out one image and that same image is deployed to all computers that are signed up to listen to that image deployment. Multicasting requires more cooperation with your network infrastructure than simple unicast imaging (sending the image to one computer at a time)

@mgoh said in Reinstating Images to the Web UI:

I tried that, and the size of the image is 0 GB. Is that expected?

This is expected if you manually create the image definition. If you were to upload an image then that field gets populated. Its only used for display and not for any imaging activity. So it can stay at 0B forever.

@ljh What I’m asking is that actively how many computers with FOG Client is installed, is currently hitting this fog server. Is 4,000 the right number? If yes then when you look at the top command and sort by Processor do you see mysql at the top and many php-fpm processes under it?

If you set the fog client check in from 5 minutes (300 seconds) to 15 minutes (900) seconds does that fix some of the performance issues with the FOG web ui?

If yes then we may need to make an adjustment to the FOG server db.

@celsoares said in ACPI BiOS Error:

I accept a way to fix it or a way to ignore the error.

Again I understand the messages that are being displayed. If we ignore the messages for now, what is else not working?

@tatanas I know I hacked a solution years ago to do just this. For the life of me I can’t seem to find that post. If you are willing to work with me I think I can give you guidance on what needs to be done, then I can create a tutorial for others.

At the end of fog.man.reg there is this section as you have found.

dots "Attempting to register host"
res=""
while [[ -z $res ]]; do
    res=$(curl -Lks --data "sysuuid=${sysuuid}&mac=$mac&advanced=$(echo -n 1 | base64)&host=$host&imageid=$imageid&primaryuser=$primaryuser&other1=$other1&other2=$other2&doimage=$realdoimage&doad=$blDoAD&location=$location64&username=$user64&groupid=$group64&snapinid=$snapin64&productKey=$productKey" ${web}service/auto.register.php 2>/dev/null)
    echo "$res"
    usleep 2000000
done
. /bin/fog.inventory
usleep 2000000

The curl call registers the system with FOG and also posts an imaging deploy task, because this variable is set doimage=$realdoimage

So this sets the stage for imaging.

After the call to fog.inventory what you need to do is make a call to import the new environment (from the action of registering this computer with FOG) so it can pick up the imaging task.

I wrote a hack many years ago that go incorporate into the base image for USB imaging since iPXE was not being used.

That is in the master fog script: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
### If USB Boot device we need a way to get the kernel args properly
if [[ $boottype == usb && ! -z $web ]]; then
    sysuuid=$(dmidecode -s system-uuid)
    sysuuid=${sysuuid,,}
    mac=$(getMACAddresses)
    curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A ''
    [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt
fi

So what I would do is incorporate that section (minus the if statement) and once you stat the hinfo.txt file the environment should be properly setup to then jump to the /bin/fog.download command.

Will it work? It should. The fix I created at the time worked. Does it need a bit of debugging, yes it does. I think if you have made it this far with tweaking the fog.man.reg file you have the needed skills to take this next step.