@sebastian-roth said in Is it possible to update bios setting via FOG server.:

I am fairly sure this is a legacy BIOS install.

Maybe its time to mix things up a bit and go uefi and flat partitions on the image to get the maximum flexibility.

@emreonder Just for clarity are you running these motherboards in bios mode or uefi mode?

This part is only me thinking out loud, but in theory if they are in uefi mode you should be able to use the efibootmgr application in linux to change the boot order. That can be deployed as an FOG snapin.

So the idea has two parts, but initially you will need to start the process by pxe booting at least once.

At the end of imaging FOG has a place to call an external bash script. That script is called a fog post install script. In that script you would make a call to the efibootmgr to set the hard drive as the first boot item. Upon the first reboot after imaging the computer will boot from the hard drive and complete ubuntu setup.

Now when you want to image it again, you will call a snapin (fog application deployment tool) to call the efibootmgr on the target computer and change the boot order to pxe booting then when you issue the reimaging task the fog client will reboot and pxe boot into imaging. At the end of imaging the post install script will run again to change the boot order to hard drive first.

@jj-fullmer Great I’ll take bonus points whenever I can get them.

The keyboard thing has me a bit confused because that is native to the linux kernel. I made no adjustments in that area between 5.6.18 and 5.9.3 so it must be a “feature” of the linux kernel.

@emreonder said in Need to install Fog Server. Urgent remote support needed.:

nomater all the options i try with the Host Bios Exit Type or Host EFI Exit Type ( i guess i tried all the combinations) but never passes this step.

Ok the first thing we need to know is the gigabyte mobo in bios or uefi mode. Knowing that then you can focus on the right Host Exit type.

The default for bios exit type is SANBOOT. That works 95% of the time. For the UEFI exit type that is typically rEFInd.

So if you have a uefi type firmware and rEFInd hangs on exit there are a few things you can try with refind to make it work. The first thing I think I would have you do is update a few settings in the refind.conf file to see if adjust refind to locate your boot media.

@emreonder Ok I have a few ideas for you.

1. Since these are bare metal builds you will have a tech in front of the computer at some point during staging. If this is the case you can use the firmware boot manager to pick a one time pxe boot. Then you can leave the default to the local boot media. Upon system reboot the system will always boot to the local media. The only downside to this approach is if you need to reimage the computer in an unattended manner (i.e. reimage a entire classroom of computers between classes without visiting each machine). Since you made a comment about if the fog server is down then you don’t have a system boot. I think this manual boot menu pxe boot might fit here.

2. FOG doesn’t change or update the firmware boot order. So if these systems are true bare metal builds the uefi firmware may not be configured in a sane configuration for the image you are deploying to the computer. In this case you should create a FOG post install script that will call the efibootmgr application with the proper parameters to configure the uefi firmware so it can find the boot media.

@foggymind IMO the first step is to ensure that the clients are being told the proper information to boot. So wireshark/tcpdump is the first step. If the pxe clients are being told the right thing then focus on the tftp server or something getting in the way of tftp booting.

What devices are your dhcp servers? Are they windows dhcp servers?

I have seen where someone pluged in a home wifi router into a company business network that caused this random pxe boot information because it was giving out bad data. SOHO routers will often give their LAN IP address out as the {next-server} value. Depending on which DHCP server answers the client first (rouge dhcp or company dhcp) it caused pxe booting issues.

@blema2213 It looks like I need to create an updated post. The intent was for you to follow this process https://forums.fogproject.org/post/103323 until you get to step 18 then jump to the first link I posted to you.

The idea/problem is just as I mentioned, Win10 expects to see local or network based media not in RAM media. Also the issue with the above link is that you can not use the memdisk program with uefi. So what I’m recommending is that you copy the win10 media to a windows server and share it out as read only. Then build a WinPE image that will mount the network share you created and run the winsetup program. Windows will allow you to install over a CIFS share.

So the steps are to

1. Copy the windows media to a windows based server (or SAMBA) share.
2. Create a WinPE boot media
3. Launch that WinPE image from the fog server over pxe
4. Install Windows from the share created in step 1

@emreonder said in Is it possible to update bios setting via FOG server.:

gigabyte mother board

Do you have an operating OS on these systems or are they bare metal build?

If these are physical machines, will you be upacking them prior to imaging?

Are these systems already registered in FOG?

IN short, if the gigabyte mother board have a utility like the Dell’s do, you can change the boot order or set to pxe boot on the next boot only from within an operating OS. If there isn’t a specific there may be a windows application to change the boot order. I know for linux there is a efibootmgr application that you can use to change the uefi boot order.

@jj-fullmer No worries on testing 5.9.3 since you have a working path forward. With 5.9.3 that is just a stop gap kernel until 5.10.x LTS branch is released and tested.

@foggymind ok with the fog server and cleints on the same subnet we can get the fog server to listen in on the dhcp process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

This will capture the pxe booting process. Once captured you can load into wireshark or upload so one of us can look at it. What you want to look for is multiple OFFER packets. You should have one from each DHCP that hears the clients DISCOVER packet. Look to see if you have more offer packets than known dhcp servers.

Also look into the Discover packet, there should be the bootp settings in the ethernet header. You should see a {next-server} this should point to your fog server’s IP as well as a {boot-file} that should be the name of the boot loader (undionly.kpxe for bios and ipxe.efi for uefi systems). Then down in the dhcp options make sure 66 is the ip address of the fog server and 67 is the proper boot loader. Do this for every offer packet making sure they ALL point to the same settings.

@foggymind Are all three DHCP server, fog server and target computer on the same subnet? If not can you install wireshark on a witness computer (second computer on the same subnet as the pxe booting computer)? If so please run with a capture filter of port 67 or port 68 and then upload the contents to a file share site and post the link here. Ideally if you can capture the error being generated that would tell us what is broke.

@blema2213 That is a problem with windows and not related to fog. The FOG developers can’t help.

I can tell you what is wrong and where to look. You booted the .wim file via pxe boot. The problem is the winpe image that is running is looking for the install media locally on a usb drive or cdrom. It will not see the in memory wim file.

It IS possible to pxe boot into the WinSetup program. I can tell you where you need to look/begin: https://forums.fogproject.org/post/103331

@wayne-workman said in Simplifying Deployment with Official Virtual Appliance:

Yeah, at this point Fedora would be a better pick for RPM based Linux than CentOS.

I agree 100%. At this point CentOS is dead to me.

I think people should learn Debian.

As we roll out new linux VMs, they will be Debian at my company. As you said Ubuntu is very popular, but (IMO) Canonical could go the same route as RH or go a totally different route causing a new bunch of problems. Heck, Canonical could get sucked into Microsoft, then what? (Embrace, enhance, extinguish. You know the drill.)

@seppim said in Booting Rescue ISO:

isolinux.cfg

Your kernel parameters will most likely be found in this file.

@foggymind Please open a new thread because your conditions are probably different than the OP of this thread. In his case it was a setting on their firewall that was causing this issue.

BUT confirm that you only have 1 dhcp server on your network. I’ve seen rouge dhcp servers cause random pxe boot errors.

@navarro I’m surprised you got here with this error message.

On your fog server that file should be in /tftpboot. Does that directory have files in it? Is default.ipxe in that directory? I can see that file not being there if you didn’t go back and complete the second half of the install. FOG linux console install fog -> Web ui to install database -> linux console and press enter to complete the install. Some people miss that second part.

@sebastian-roth said in EFI_exit failed error when leaving FOG Menu on Dell Optiplex 7010 and Lenovo M83:

Let us know if this works on your Dell Optiplex 7010

I realize you are talking about EFI exit mode but the 7010s have an issue when ipxe initializes on the 7010. It will hang at initializing… in uefi mode and never proceed. Unless this fix addresses that part too it might not be possible to test the efi exit function.

@jj-fullmer I just updated the 5.9.3 with the updated realtek driver. https://drive.google.com/file/d/1O-4tvx4DywWef75qfSxLRK9M6CoDS9pd/view?usp=sharing

For documentation purposes, for 5.9.3 the 8152/8153 driver version in the mainstream kernel is 1.11.11 and the updated (patched) driver I’ve been installing from realtek is 2.13.0 dated April 2020

@jj-fullmer said in Lenovo L13 yoga 'Maybe the usb cable is bad' error when trying to register:

Did you change anything else other than this driver and firmware for this kernel? Would it be safe to try using this one as default for all hosts? Or is there something else in there that might cause pause?

No that is the base image with the updated firmware for the realtek nics plus the updated realtek driver. Its possible that the 5.9.3 doesn’t have the patched realtek driver. I was working with 5.9.3 specifically for the realtek 8125 nic.

Yes it is safe to use bzImage5618RT3 kernel for everyday imaging.

@boriquaboy115 I would like to say yes for LUKS encryption. I created a one off kernel for that a while ago for a specific use case.

Part 2: LVM isn’t a problem for FOG, it just can’t resize the disk image, so you can only deploy it to the same size disk or larger if you have an LVM partition.

ref: https://forums.fogproject.org/topic/13845/error-decrypting-luks-partition-prior-to-capture-imaging/8