Moderators

@george1421 Thinking about this you have one more layer in the mix. Since you are using lvm, you need to extend the lvm partition if its not matching the size of the disk.

TBH if this is a vm I would personally just create a new disk and create a standard partition, format it and then migrate your files over to this new disk. I’ve been thinking about creating a new recommendation tutorial to show how I would go about setting up fog to allow storage expansion easily after the fact. LVM adds quite a bit of flexibility but also adds some management overhead that isn’t needed.

@sjensen well this is a linux issue not specifically a fog issue.

I would look in /etc/fstab to find out what file system your partition is formatted as. Once you know the file system (its probably xfs or ext4) then I can give you a hint how to extend it.

@maxwellmw In your for service loop I don’t see ssh in the list.

in the console window of your fog server key in
firewall-cmd --permanent --zone=public --add-service=ssh

@sjensen You need to extend the file system too. From a virtual machine stand point you extend the vmdk, partition, then the file system. How you extend the file system is based on what filesystem your fog server is using. xfs is the easiest to extend others are not bad either.

@emreonder I guess I would have to say its impossible what you want to do. Its possible but not by Saturday even if you have the fog server already setup.

I also would say you have too many unknown conditions for a 2 days deployment.

1. How big is your master image?
2. Are these new servers all located at one location?
3. If they are remote does the remote locations have a connection back to where the FOG server is 100% of the time?
4. If they are remote what is the network speed between the locations
5. Are these virtual or physical servers?
6. If they are virtual what hypervisor are you using?
7. Does your remote hardware support pxe booting?
8. If your 1000 servers are remote do you have technical people on site to start the imaging process?

I’m sure there are a few more.

Can fog image 1000 computer, yes
Can fog image 1000 computers at the same time, no
Can fog deploy ubuntu images, yes
Can fog deploy 40 computers all at one in the same class room, yes
Does fog support both uefi and bios based computers, yes

On a well managed local 1GbE LAN FOG can deploy a 25GB image in about 4 minutes to a modern (0-3 years old) computer. So using those numbers FOG can unicast-image 12 systems per hour or 288 per day or 576 in 48 hours non-stop. There is no way to get to 1000s by Saturday. Any imaging solution would have troubles getting there from nothing, as you have today.

@dangbird That above boot parameters seem a bit nonsensical because they are loading two kernels into memory one with kernel and one with module. But only the kernel loaded module will start with the boot command.

I’ve found that most current linux kernels support both bios and uefi. So it should work for linux.

For the uefi boot. Since it uses grub to start things off, see if you can locate the grub.cfg file and post that here. Lets see what they are doing different for uefi mode.

@vemoya All I can say you get what you’re paying for.

Create a new iPXE menu that looks similar to this.

Menu Item: os.chainwdsimaging
Description: Boot WDS Imaging Solution
Parameters:
cpuid --ext 29 && set warch x64 || set warch wx86
iseq ${platform} pcbios && set bootfname wdsnbp.com ||
iseq ${platform} efi && set bootfname wdsmgfw.efi ||
chain -ar tftp://10.254.0.155\\boot\\${warch}\\${bootfname}
boot || goto MENU
Menu Show with: All Hosts

The script parameters looks a bit complicated but it basically checks to see if the target is x86 or x64 and uefi or bios to pick the right location and file name to boot.

Understand that for pxe booting there is two methods and it appears you are using both in your setup.

There is the static mode where you define dhcp options 66 and 67 listing statically the boot server and file name to use. In your case your dhcp server looks like you have policies defined to switch between uefi and bios boot files this is good.

The second method you are using is called proxy dhcp this is where you add your pxe boot server (WDS or FOG running dnsmasq) to the last host in your dhcp-helper service on your router. Both WDS and FOG running dnsmasq will respond with the proper boot file when it hears a dhcp discover from the target computer (this is why you have it listed in the dhcp helper service). The proxydhcp server (WDS or dnsmasq) will only provide the pxe boot information leaving your main dhcp server to provide the rest of the boot information. If you have a proxydhcp server configured its settings will override the static settings you have defined in dhcp options 66 and 67.

The reason why I’m telling you this, if you don’t stop the proxydhcp service on WDS it could respond to proxy boot requests giving you a random boot experience. Its ok to have static and dynamic assigned boot files, just know that proxydhcp will override static settings, when you can’t figure out why things are working as intended.

Be aware I did not test the script above only wrote it on the fly without much thought. YMMV

@vemoya I’ll have an answer in about 5 minutes on the next step. Almost there.

@vemoya Yeah that’s going to be a difficult path to walk. Both systems rely in the same technology to pxe boot.

I would stick with the latest dev branch for FOG. SO 1.5.9.49 is the most current.

Now you HAVE TO pick one as your primary imaging server. This probably would easiest to do with FOG being your primary imaging server.

On your wds server turn off the proxydhcp server (I don’t know what its called in WDS land). You don’t want your WDS server to respond to any dhcp boot requests.

From there you will need to craft a custom fog iPXE menu to call the bootstrap loader on your wds server. So the idea is you pxe boot into fog then if the IT Tech wants WDS they will pick a menu item that will chain into WDS bootstrap.

@john-l-clark Here are the exact key sequences I used to build this driver on a brand now Ubuntu 20.04 image in my virtual lab.

sudo su -
apt update
apt upgrade

apt-get install wget git build-essentials -y

reboot

git clone https://github.com/acooks/tn40xx-driver
cd tn40xx-driver
make
sudo make install

modprobe tn40xx
tail /var/log/syslog
lsmod | grep tn40xx

When you review syslog look for errors regarding this network adapter. Ignore the one about the tainted kernel.

If everything goes ok then you will need to create a startup file in /etc/modules.d so that this network driver loads on every boot up. Once its there then reboot and it should pick up an IP address, if not make sure its listed with the lsmod command like above. For ubuntu you may have to use the network manager to assign an IP address for it. I’m not a big ubuntu user, so I’m just guessing. But it took me longer to install ubuntu than it did for me to build this network kernel driver. Keep the installer files because when you upgrade your linux kernel you will need to recompile this network adapter driver.