@cdutko The simplest way to do it is via this wiki page.
https://docs.fogproject.org/en/latest/installation/install_fog_server.html
Using the git method is real easy. Performing upgrades are even easier. But lets get things setup on the 20.04 server first then you can follow this wiki page: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
The migration will leave the existing fog server in place but migrate (copy) the data over.
@adukes40 I agree I updated my dev environment first thing this AM (6a EDT) and then tried to deploy around 1p EDT and received the same exact error. I checked a few things and saw some errors in the apache log and the ipxe boot menu (construction) was messed up, so I updated again and they the image pxe booted correctly. This is life with the trunk build, you have to tolerate a little instability but the benefits are well worth it.
Please update your installer to the latest release and then run the bin/installfog.sh script again.
@Developers I don’t work with github but can you tell from this document if this feature has been added to the master branch in iPXE? https://github.com/ipxe/ipxe/pull/612 This looks like it might solve both the OPs issue as well as could be utilized in FOG as a possible exit mode in addition to rEFInd for uefi exit modes.
Also in researching this I also came across this post that talked about the Exit , where it chains to the next device in the uefi boot order. https://forum.ipxe.org/showthread.php?tid=6775 post #8 Specifically some uefi firmware needs Exit 1 (to see the failure level) to chain to the next boot item in the uefi boot order. So if I understand this if the boot order is {PXE, Windows OS} the Exit 1 ipxe menu item would make it boot uefi boot menu {Windows}.
@koni The commands you use are specific to syslinux. They are unknown to iPXE. FOG uses refind.efi (typically) as an exit mode from the iPXE menu. Meaning that iPXE doesn’t directly manage booting from the local hard drive. It appears the patch I referenced above for iPXE will give us that ability. Please give us some time to get this sorted out. There is a way (I’ve done before) to chain load grub.efi so we can make a grub menu to do what you want. Also we can do something similar with rEFInd and have a custom refind menu to boot locally. It would be cleaner to do in iPXE directly as the patch has mentioned. Lets see what solution we can find.
@Data31337 said in Kernel panic - not syncing: VFS:
[edit] DHCP is pushing out the pxelinux.0 [/edit]
Great find. It looks like legacy iPXE stuff [ edit legacy syslinux] bit us twice in a short period of time. Just so we know where, where did you get the instructions to use pxelinux.0 from in dhcp?
@masterofus said in Security concerns:
I’ve lurked the forums searching for NFS security to find answers. Maybe I’m wrong, I don’t know?
- NFS is faster
- No security needed in intranet
- Don’t put FOG on the public side
- Use an IP filter or limit IPs in exportfile
- SMB is slower and not native to Linux
I can not refute anything you found. It is as you listed. NFSv3 is insecure (more on this later). That is why a FOG server should never be connected to a public internet.
What are the solutions ? You’d think students would not try anything but in fact they will.
Especially CS students.
- Are the DD images crypted on the fly ?
The image files are not encrypted, but they are compressed/decompressed dynamically. You can’t just technically read the file and get anything of value out. Consider that this is a disk sector copy, with block crc hashing, that is compressed and packed into a partition based image file. Its not a simple as a straight DD dump. If you knew what you were doing, could you extract the disk image, Yes. If you knew what you were doing, could you mount the extracted partitions, yes. So what would you have? FOG is not a backup solution.
So I just have to say this part, so what if someone gets a copy of the image? What harm will it cause? There should be no PII or user created data in it. It should be just a clean image. So what are the risks. We want to make sure we put the effort into the project where its going to return the best results based on the investment of time.
- Is there a way to hide, on screen, the NFS path used when deploying ? That way, you can randomize a NFS folder. (security thru obscurity)
Hiding the NFS path, that’s possible since if its printed, the print command can be removed. We’d have to identify where in the imaging process its being displayed. Can you randomize the nfs folder, no since nfs doesn’t work that way. You would have to restart the nfs server on the fog server every time you wanted to change the export path.
If you only allowed imaging from a specific network, yes you could add the IP filters on the nfs export to limit who could connect to the nfs share.
I’m just trying to secure the image depot and it’s strange nobody cares ? Maybe the users don’t know their files aren’t secure at all?
You have to consider that the majority of the sites that use FOG is for windows based imaging, not linux. So in the case of NFS, MS Windows is a bit ignorant of the protocol (yes I know you can add services to allow NFS). So since windows can’t nativly communicate with an NFS share then that data is pretty protected. As well if the windows box does get ahold of the image file, they will have a 25GB blob. What will they do with it? In the linux world, someone with the intent and a bit of skill could extract the image file.
Now one of the things I experimented with was NFSv4. I have imaged computers with NFSv4. The structure of NFSv4 is a bit different than v3 so its not a straight migration but it can be done. Moving to NFSv4 would go a long way to increase the security of the FOG imaging, plus make creating firewall rules much easier since nfsv4 uses a single data port for communications.
So the final thought is this. What you have pointed out is definitely a flaw in the FOG imaging environment, here in the year 2022. Security should be the primary focus. But with limited developer resources at the moment some of these advanced security features are on the roadmap but not being actively implemented.
Installing inside setupcomplete.cmd. That may be an option but then the MSI must be reachable during the execution of the setupcomplete.cmd script. This script executes as SYSTEM user so that msi must be on the target computer so it can be installed by setupcomplete.cmd.
From a practical standpoint there is no need for the fog client on the reference image (other than not having to install it later). In my case I install it in the reference image and then stop and disable it right away. I would think if you had an automated process to install the client you can do that, or if the client is installed during audit mode, they will have to take the steps to disable it manually.
Just had an idea, what if the developers could put a command line switch in to install it but set the service to disabled. Then through one action of installing the msi the environment would be setup. Leave the default setting as it is now to install and run, but then create a command line switch to install, not run, and set the service to disabled.
@brakcounty OK I have two ideas here.
First method low tech:
At a previous job we would image computers for deployment across the country and the numbering scheme was similar to your SiteLUN code plus serial number. We had a laminated sheet of paper that had a barcode with the site lun code (i.e. USNYC) and human readable text next to it. When we were registering the computers we would plug a usb barcode reader into the target machine. Then when the full registration asked for the computer name, we would zap the destination LUN code then the serial number on the dell asset tag. We could use the FOG standard full registration code since nothing inside fog would have changed.
Second method:
I can remember for sure, but I think you are using a version of this script to create the default system name: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg?_=1675820625786
You could prompt in the fog.customhostname script for a department name and then let the script concatenate the entered department name with the collected system serial number.
@Bob-Henderson Understand this is not an official comment, but if you are at a road block until the devs can resolve this issue, I have a way to hack around it.
You need to have access to the linux console and edit the following file.
/var/www/html/fog/lib/fog/bootmenu.class.php
Search for rootfstype There should be two in that file. The first one is what we need to edit.
It should look something like this
$this->kernel = sprintf('kernel %s %s initrd=%s root=/dev/ram0 rw ramdisk_size=%s keymap=%s web=%s consoleblank=0%s rootfstype=ext4%s%s',
Just insert a space between ext4%s%s making it look like this
$this->kernel = sprintf('kernel %s %s initrd=%s root=/dev/ram0 rw ramdisk_size=%s keymap=%s web=%s consoleblank=0%s rootfstype=ext4 %s%s',
Save the file and you should now be able to boot into the FOS kernel. Of course we should wait for an official fix, but this will get you going.
@Kram-Man Is your main ipxe server running ipxe as the bootloader or syslinux? If its truely iPXE then on the FOG server, in the tftpboot directory there is a file called default.ipxe At the bottom of that is a chain load command or chain load the default.ipxe You can look at this line on github. https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src/ipxescript#L32 Just replace ${next-server} with the IP address of your fog server.
For clarity, will you confirm that you DO NOT have the following section in your unattend.xml file? The reason why I ask is that I could see a potential for a race condition between the unattend.xml connecting the device to the domain and then the fog client doing its bit since the fog client does have a check in interval that also impacts timing of when things happen.
<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
@jfernandz said in FOG and Secure Boot:
The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.
You are correct I really missed the refind files. I will update that info too. While I had 1.6k viewers of the file not many people have returned comments. I have that turned off in the tutorial because it makes the multipart tutorial a bit messy because of the way the forum works.
I think the signing process (with sbsign) may be automated in a bash script
Towards the bottom of the document there is a bash script easter egg. I initially wrote the bash script then broke it up to explain what each part did. For those that never made it to the bottom of the post, they missed out on the bash script. I intentionally did it that way so people knew how it worked before they simply cut and pasted the script.
@jpmartin That’s great!! I’ll have to write this up in a tutorial so that its document properly now.
(Shameless donation request)
Please, if your company finds value in the FOG management tools, please consider donating to the FOG Project. The level of support, bug fixes, and rapid feature advancements companies receive from the FOG Project are at levels much higher than almost all Tier 1 support groups. If all companies and organizations that productively use FOG within their site(s), just contributed $50USD to the FOG project, it would really help to support a very worthwhile ecosystem.
@jfernandz said in FOG and Secure Boot:
You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist
I can’t believe I wrote that article in 2021, man time goes by quickly. The dbx file is created for black listed certificates. It is kind of an optional for the vendors to include in the firmware. The idea is if a secure boot certificate gets compromised the vendor can add it to that database. So I can see if the database is empty on the target system then the file might not get created. I should add a note into the document explaining this, thank you for the catch here.
For reference my notes say that I referenced this document as I was writing my document: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC
Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi
Thank you I will fix that.
@Wayne-Workman Just for clarity if the OP is able to run fixparts then PXE booting is not an issue (unless I missed something). Fixparts requires the FOS engine to be running on the target computer.
What is the real issue here?
Sorry for putting it this way, but there is a lot of noise (unimportant information) in the OP. For the OP a screen shot of the exact error is what is needed here. Pictures speak better than words when trying to pinpoint the error.
@jfernandz Looking at your video, can you confirm that 172.120.1.4 is your fog server?
From your post it looks like “time” solves the problem, because you can repeat the same steps after a few seconds and it works??
If this is the case, intuition is telling me spanning tree issue. One network switches using standard spanning tree it take about 27 seconds to start forwarding the data while the switch ports listens for a BPU packet. This timer starts every time the network port “winks”, and it will “wink” (go down and up quickly) as each kernel starts (ipxe firmware, ipxe.efi, and then bzImage. To test this idea, get a dumb/umanaged/cheap network switch, like one of those 5 port monoprice switches. These do not support (typically) spanning tree. Place this switch between the pxe booting computer and the building network switch. See if this fixes this refind issue. -OR- contact your network infrastructure team to verify that one of the fast spanning tree protocols are configured on the port (portfast, fast-STP, RSTP, MSTP, etc). At this point I don’t think your issue has anything to do with secureboot.
It sounds like you might have 2 dhcp servers on this subnet. When iPXE asks for the tftp server address this means that your dhcp server did not deliver this information correctly. If you say that dhcp options 66 is set to the ip address then it sounds like there is more going on than we know right now.
If your dhcp server, fog server and booting target computer are on the same subnet then you can run the following command on your fog server to capture the dhcp traffic. Post the pcap file here so the devs can review the dhcp process.
tcpdump -w output.pcap port 67 or port 68 or port 69
Please also take a picture of the error screen with your mobile and post the picture here. Sometimes we can see errors that posters don’t notice.
Interesting… the first thought is to get a live boot linux distro and see what the real device is called. I would still think it would be /dev/sda something since its still … maybe not using the sata interface (just reread your post).
I was also thinking the trunk build had a debug mode where you could boot to a command prompt to inspect the devices. I know the live boot will work.
[Edit] Ok, if you boot into the fog menu then check system compatibility. Once in system compatibility select partition information. If that shows up blank then we will have to go the live linux route [/Edit]
@jhuesser OK now that you have it working with an external keyboard can we collect some additional details on this surface pro 4? Is there a sub version that we need to be aware of (remember I’m ignorant of the surface pro tablets). So is there like a surface pro 4 model XXXXX or something like that. I would expect the linux kernel developers will add support for this internal keyboard at some time in the future. Eventually it may make it into the FOS engine.
I’m kind of surprised that others that have imaged the surface pro 4 with FOG didn’t report keyboard issues before now. That is what is making me think there are different models to the surface pro.4. It would be interesting to see if a commercial linux distribution would have the same issue. Something current like ubuntu desktop live would answer that.
Either way I’m glad you have it worked out and can move forward.
@Arrowhead-IT I was just editing my previous post about using compatibility menu to get the info.
Now this is just me guessing out loud here (since I haven’t had this exact issue just yet). But if you look in the FOG GUI, and the host management details for this specific computer. Note there is a field called “Host Primary Disk”, it would be interesting to know if you entered /dev/nvme0n1 in that field, would it blow up (Err… work as intended)?
@ecicerkofski You can review this thread: https://forums.fogproject.org/topic/8323/several-problems-with-surface-pro-4
The OP there [ @jhuesser ] had success with the ipxe boot file ipxe7156.efi Please set your dhcp option 67 {boot-file} to that and try again.
Also what version of FOG are you using?
