@fredlwal Files are files, if you move them with the gui or with the command line. They are the same.
Best posts made by george1421
-
RE: mysql
-
RE: Custom Full Host Registration Menu for 1.4.0.rc2 and later
@jgallo We must be aware of a few things here.
- The github site always contains the latest release. So (currently) the files contained are for FOG 1.5.0. If you are working on a down level version of FOG then you need to take the route of extracting the inits. You don’t need to repack the inits, because you only need the file you want to tweak. Once you have the file you want to patch, then you may unmount the loop directory and remove the unpacked init.
- The structure of files may change from release to release. In the case of FOS, it was split out into its own branch. The correct path (as of 1.5.0) to the file in question is: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg (full disclosure, it took me a bit to find the right path too).
- The only caution is as newer versions of FOG are released, your patch file may become stale, where you might need to update a newer versions of fog.man.reg as newer versions of FOG are released. The risk is that you might be applying an older version of fog.man.reg over an updated version fog.man.reg breaking FOG without a clue why.
The rest of the instructions by @JGallo are still accurate (at least for 1.5.0). You can still use the post init scripts to “patch” the current FOS image as in the original post.
-
RE: mysql
@fredlwal Is there a button on that screen to do just that?
Also what version of FOG is on the new server?
-
RE: Simplest tutorials
@kabaiz As Wayne has said there are many tutorials on the wiki. It just depends on which operating system you pick as your fog server OS (linux only at this time). For example here is how to install FOG on Centos: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7 Just be aware that there is nothing simple with imaging. There are a lot of parts to imaging and any of them can cause imaging to fail. FOG is a great software for the price, but FOG is only a small part of the entire imaging process.
FOG has many options depending on your current network environment. You do not need to use FOG as your DNS or DHCP server. Those options are available if you don’t currently have the networking resources. If you do have existing services then don’t enable them during FOG setup.
You can do unattended imaging, or require a technician at the target computer to start the process. The decision is yours and how much risk you want. Risk in the idea you might accidentally tell FOG to image the wrong computer if you have a completely no touch imaging.
FOG handles both uefi and bios booting and imaging. FOG does support LVM but it can’t currently resize the LVM partitions like it can do for standard partitions. So if you are imaging linux and want FOG to resize the partitions to the size of the target computer, then create your master linux images using traditional disk partitions and not LVM.
You can decide if you want the clients to pxe boot into the fog menu each time (which will grant the unatteded imaging option), or require the IT technician to be at the target computer to call up the boot menu to select pxe booting into FOG. That decision is a business workflow that you need to decide.
-
RE: mysql
@fredlwal Ok this post confuses me a bit. Where did the .gz file come from?
The typical process for installing FOG on a new system is this.
cd <path_where_you_want_the_install_files_install_files> git clone https://github.com/fogproject/fogproject.git cd <path_to_your_install_files>/fogproject cd bin ./installfog.sh -y
That process requires internet access of the fog server. But it will build your fog server for you. There is a step during the build process where it will ask you to go to the management page and create the database. The installer will wait until you go to the web site to create the database. Once the database has been created then go back to the installer and press enter to continue the setup. That is the process.
-
RE: Simplest tutorials
@tiagoluz I agree either Debian or Centos is a good choice for a first time FOG installation. Ubuntu sometimes causes FOG issues.
But FOG is tested against 9 linux distributions every day to ensure FOG installs using an automated process that Wayne developed.
-
RE: mysql
@fredlwal The quickest is to manually recreate the image definitions.
If you have 1.2.0 still functional. Just copy and paste between the management interfaces. If you have more than a handful of images (<10) the copy/paste process is the quickest and best.
-
RE: USB Boot UEFI client into FOG menu (easy way)
@boyan-biandov I feel with FOG 1.2.0 (read pretty sure) you are going to have other issues. But lets get you past your request. If you are looking for ipxe.efi you can probably get them from one of the FOG tarball distributions, here: https://github.com/FOGProject/fogproject/releases
Look in packages/tftp directory for the files of one of the tar.gz files.
I would look in the 1.3.x releases for the first ipxe.efi boot loader. You don’t want to deviate to far from 1.2.0. On the other hand you may need to try the 1.5.x release ipxe.efi to get later hardware support.
Extract it with tar to a working directory and then search the path for ipxe.efi.
Beyond pxe booting into uefi mode, if your new systems have NVMe drivers, GPT disks and newer hardware your FOG 1.2.0 install will have problems digesting that hardware. I’m even questing if FOS (customized linux OS) will boot on a uefi system since its 32 bits for 1.2.0. But I guess you won’t know until you try.
-
RE: mysql
@fredlwal You copy the files from your portable hard drive back to the /images directory on new server.
Then you have to manually recreate the image definitions via the web gui. This will then link the the physical files with the web gui
-
RE: USB Boot UEFI client into FOG menu (easy way)
@boyan-biandov This tells me the FOS linux kernel you are using is not matched to the virtual hard drive (init.xz) or you are attempting to pxe boot using pxelinux.0 both will give you this error.
-
RE: mysql
@fredlwal You would make that choice when you ran the fog installer to enable the dhcp server in the FOG server.
Do you have an isolated deployment network or does your FOG server span two networks?
-
RE: Synology NAS as FOG Storage node
@Vincent-Caraby Well lets see if I can explain this, but the answer is simple and complicated at the same time.
The FOS engine connects to the master node as
root
so the synology nas needs to allowroot
to connect to the /volume1/images and /volume1/images/dev as root.Also the FOS engine will use ftp to connect to the NAS using the
adminfog
user and password you defined in the Storage Node configuration to move the files from /images/dev to /images directory. -
RE: mysql
@fredlwal I can say that its easier for you to keep it on the business network, or at least can reach the business network. Many systems require access to a Windows DC as part of their setup (to connect to the domain, and such).
To answer your question (and anticipate the next one).
On your dhcp server you need to enter:
DHCP Option 66 {boot-server}: <ip address of fog server>
DHCP Option 67 {boot-file}: undionly.kpxe (for bios/legacy clients) ipxe.efi (for uefi clients)If you have a windows 2012 dhcp server you can configure it to dynamically send out the right file name during dhcp setup.
-
Dynamically Patching FOS using a PostInit script
Postinit scripts are scripts called by FOS just after the FOS Linux system inits and before the main FOS imaging program starts. The postinit scripts give us the opportunity to make adjustments to FOS before imaging occurs. These adjustments can be to initialize raid controllers, bring up specialized hardware, or in the case of this post replace or patch parts of FOS imaging scripts before imaging begins.
One example of patching or replacing FOS components might be if you wanted a customized registration process. The FOG registration process is managed by a FOG script called
fog.man.reg
that’s located in the/bin
in the inits. One way to update this fog.man.reg files is by unpacking the inits, updating the script and then repacking the inits and then moving the inits to the proper location on the FOG server. Instructions on unpacking and packing the inits can be found in the FOG Wiki page hereThe method I’m going to cover here is to place the updated fog.man.reg file on the FOG server in the
/images/dev/postinitscripts
script directory where FOS Linux will see it and execute the postinitscripts before it starts imaging.- Create a file
/images/dev/postinitscripts/fog.patch.man.reg
- Paste the contents below into fog.patch.man.reg
#!/bin/bash # Current File in FOS Linux to be replaced currfile="/bin/fog.man.reg" #Patch file to send to FOS Linux virtual hard drive newfile="${postinitpath}fog.reg.man.fix" # --------------------------------------------- # DO NOT edit any text below this line # --------------------------------------------- . /usr/share/fog/lib/funcs.sh # Test path and run copy if found and matched. if [[ -r $newfile ]]; then cp -f $newfile $currfile >/dev/null 2>&1 [[ ! $? -eq 0 ]] && echo -n "patch copy failed " || echo -n "Patch copy succeeded " else echo -n "Patch not found" debugPause fi debugPause
- Make the script executable
chmod 755 /images/dev/postinitscripts/fog.patch.man.reg
- Edit
/images/dev/postinitscripts/fog.postinit
and add the following line to the bottom of the fog.postinit script
. ${postinitpath}fog.patch.man.reg
note: that leading period is not a mistake it needs to be the first character on that line. Its (dot)(space)${postinitpath} to ensure your custom patch script is called correctly.
- Download the latest version of
fog.man.reg
wget -O /images/dev/postinitscripts/fog.reg.man.fix https://github.com/FOGProject/fos/raw/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg chmod 755 /images/dev/postinitscripts/fog.reg.man.fix
- Modify
/images/dev/postinitscripts/fog.reg.man.fix
file as needed…
Original script credit Tom Elliot
ref: https://forums.fogproject.org/topic/9754/custom-full-host-registration-for-1-3-4/46 - Create a file
-
RE: mysql
@fredlwal No you do not. All files stay on the fog server.
All you are changing is the dhcp options for the subnet scope you want to pxe boot.
This document may be too complex for what you are doing right now, but it does explain how to setup the windows dhcp server to send out both file names (not the actual file)
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy -
RE: FOG: 1.5.4 -> How to setup NAS - Synology DiskStation as Master Node
@jeremyvdv Well I guess we have 2 things.
-
While this is not a fix, you can save the failed upload by manually moving the folder /volume1/Images2/dev/<mac_address> to /volume1/Images2/<image_name> . Understand this is not a fix only a work around.
-
Do you have teamviewer capabilities? I would like to see what you are seeing, because its impossible to happen the way you say it does. Understand I am not doubting you, only don’t understand how its possible.
-
-
RE: Imaging Causes Phone Problems.
I’m not sure I can explain this with a post but here goes.
For an accurate test the machine that was being imaged and caused phone issues. Is there a way to move it only to the same vlan as the fog server.
What is important here is 2 points.
- The network switch to network switch data path between the fog server and the PC that was causing the issue must remain consistent.
- By changing the target system to the same VLAN as the FOG server, you are bypassing the router between the vlans, but keeping the same data path.
So what’s not clear in my mind. Is the issue caused by your router not being fast enough, or having the proper QoS rules in place.
OR, you have a bottle neck in the communication path between the FOG server and the target system that is causing the problem.
IF all you change is the vlan association with the target computer, does the voip communications exist.
If you can answer that you should be able to narrow in on the problem.
I can tell you one other thing. QoS should be an end to end solution. Meaning that all switches on your campus should have QoS setup and defined, not just your router. Because any link between the FOG server and the target computer can become saturated causing the communications problems.
-
RE: FOG: 1.5.4 -> How to setup NAS - Synology DiskStation as Master Node
@george1421 After having a chat session with @jeremyvdv which we had to cut short I discovered somethings.
I asked him to post the output of the kernel parameters from a debug session.
cat /proc/cmdline loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10.16.3.129/fog/ consoleblank=0 rootfstype=ext4 mac=00:00:00:00:00:00 ftp=10.1.5.8 storage=10.1.5.8:/volume1/images2/dev/ storageip=10.1.5.8 osid=5 irqpoll hostname=LP0045 chkdsk=0 img=test10 imgType=n imgPartitionType=all imgid=5 imgFormat=5 PIGZ_COMP=-10 hostearly=1 pct=5 ignorepg=1 isdebug=yes type=up
Where we can see the storage path for NFS is
10.1.5.8:/volume1/images2/dev
but looking on the nas via FTP there is no reference to /volume1/images2 its just /images2, yet there is data in /images2/dev/<mac_address> directory. So NFS is working and FTP is not.If we looked at what he posted as a screen shot of the nas storage node
We can see that he is clearly calling out
/volume1/images2
When he connected via ftp to the nas the path was /images2/dev/<mac_address> like we see from the top picture here.
So what I’m thinking is that we leave storage path at /volume1/images2 and set the FTP path to /images2 then it should work. I think NFS is looking at it form the filesystem view where ftp is looking at the path from a logical view. They technically point to the same location, just how they get there is via two different paths.
-
RE: Change default /images directory
@finvader While this doesn’t speak directly to your current situation, if you ever rebuild your fog server I’ve recommended that you move your images (and if you are a heavy snapin user) off the root partition all together. This way you can prevent a full root partition from taking down your fog server. If you fill up the images partition or disk just that disk has issues and not the OS.
https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition -
RE: Using FOG to PXE boot into your favorite installer images
Ubuntu 1910 Desktop
- First we’ll create the required directories:
mkdir -p /images/os/ubuntu/Desk19.10 mkdir -p /tftpboot/os/ubuntu/Desk19.10
- Now we’ll mount the Ubuntu 19.10 installer over the loop directory. Then we’ll copy the contents of the DVD to the directory we built above.
mount -o loop -t iso9660 /{full path where you have the iso stored}/ubuntu-19.10-desktop-amd64.iso /mnt/loop cp -R /mnt/loop/* /images/os/ubuntu/Desk19.10 umount /mnt/loop
- Finally we’ll copy the pxe boot kernel and intfs to the tftpboot directory. We’ll need to download the netboot version from here: http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/netboot/netboot.tar.gz This version of bzlinuz.efi and initrd.lz support booting over an NFS share instead of the local DVD Drive.
wget http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/netboot/netboot.tar.gz tar -zxf netboot.tar.gz cp ./ubuntu-installer/amd64/linux /tftpboot/os/ubuntu/Desk19.10 cp ./ubuntu-installer/amd64/initrd.gz /tftpboot/os/ubuntu/Desk19.10
- The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
- In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields
Menu Item: os.Ubuntu.Desktop.19.10
Description: Ubuntu Desktop 19.10
Parameters:
kernel tftp://${fog-ip}/os/ubuntu/Desk19.10/linux
initrd tftp://${fog-ip}/os/ubuntu/Desk19.10/initrd.gz
imgargs linux root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/ubuntu/Desk19.10/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash ip=dhcp rw
boot || goto MENU
Menu Show with: All Hosts - That’s it, just pxe boot your target system and pick
Ubuntu Desktop 19.10
from the FOG iPXE boot menu.
References: