@Greg-Plamondon and @Clebboli are the Storage nodes associated to the same storage group?

For example:

Site 1 -> Default Group
Site 2 -> Default Group

Or are each storage node associated to their own Storage Groups?

The idea of storage groups is to spread the load of imaging. So if all storage nodes are part of the same storage group, then it makes sense the “jumping to different storage nodes within the group”.

While seemingly unexpected, the idea of jumping to other nodes within the same storage group is intended to balance the workload around as best it can. Sure this can probably be better handled, though I don’t know when I might get around to refactoring it. Just saying what I suspect might be happening.

Hi @rodluz

Just wanted to confirm that this update has worked. Now deploying my images in <5mins.

Thank you for your help.

I discovered my problem…it was the name and password for the stored image. They were incorrect.

@george1421 Its DHCP snooping

I guess I found my problem, it was autoexec.ipxe. I don’t remember where, but I read that I can use context of default.ipxe to autoexec.ipxe, because on fresh FOG server, there isn’t the file and every time when client boot, I get:

autoexec.ipxe not found

now i don’t use any autoexec.ipxe file and everything works fine.

So I think we can close, and problem was on Switch configuration and my autoexec.ipxe file.

Thanks a lot!

@Aaexy said in Deploying FOG in a Secure‑Boot‑Mandated UEFI Environment:

Secure Boot policy Must remain enabled at all times; only Microsoft‑signed keys are in the firmware (no option to enrol custom keys).

If this is the case there is nothing you can do with FOG. You will need to get the ipxe kernel (ipxe.efi / snp.efi) and bzImage signed with the microsoft keys so they can boot in your environment. While this pains me to say, you would probably be better off with a different imaging solution than FOG.

@george1421 Thank you so much! I enabled portfast on the switch port, and it works on physical PCs.

Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0) Kernel Offset: disabled ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0)

But sometimes this error appears even if I haven’t changed anything in the configuration and files. Even if I update or roll back the init.xz or bzImage file to a previous version, it doesn’t help. The only thing that seems to work is setting up a completely new FOG server, but after some time, the problem can come back. How I can find right version or how I can solve this problem? Most time it error on PCs with UEFI

@uzee FOG doesn’t change or really step into the target system during deployment. You CAN do this if you write a post install script that will get called once the target image is deployed to the target computer. In the case of a linux computer you could potentially set the target computer’s name here by updating the /etc/hostname file or anything else you can do with a bash script. The FOG Client can also be configured to make changes to the target computer or install applications based on instructions from the fog server. Its really identifying what you want to do and how much automation you want to script. Its all possible with FOG and a little creativity on your end. Since you already know Ubuntu (linux) bending FOG to what you want will be easier than coming strictly from a MS Windows background.

version is 1.5.10

I was not able to figure out capturing the image from a VM, I decided to use an actual desktop as the master/golden image. It made more sense as it would include the right hardware type, drivers, etc. I have captured the image finally. Now on to deployment

@Ryxn I checked and that nic has been in the linux kernel for several years.

And secondly when you checked for missing firmware the kernel wasn’t complaining about missing something.

Its a good thing you were able to get the error while in debug mode. Because that was going to be the next quest for you. To get the system when its behaving badly.

So when you get it into debug mode and its complaining about no nic lets do the following.

ip a s should show if the network interface has an ip address, I’m going to suspect no because it complained about it earlier in the boot process.

lspci -k -nn | more Look through this list until you find the entry. The number in the square brackets will be what you posted earlier. [8086&1502]. See if the nic is visible to the kernel. AND if it is it should mention what kernel driver its using. I’ll give you a for example using my laptop.

0000:00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection ( 13) I219-V [8086:15fc] (rev 20) Subsystem: Dell Ethernet Connection (13) I219-V [1028:0a22] Kernel driver in use: e1000e Kernel modules: e1000e

lastly if everything looks good, kernel sees the nic, there is a kernel driver assigned. Lets see if time fixes your problem.

When you ran the ip a s command it listed all of the network interfaces and if it has IP addresses. You will need to know the interface name for your network adapter. It may be something like eno1 or ens192, or something else. Get that device name.

Now run this command /sbin/udhcpc -i $iface --now replacing the whole word $iface with the device name listed from the ip command. This will tell the network adapter to again poll for an IP address from your dhcp server. If it picks up an IP address this time, then time does solve your problem and you will need to look into your network configuration and make sure that port-fast or fast-stp is enabled on your network port.

@ProfessorFow OK what I want you to do is on the master node, go into the storage group where this remote node is. Look at this remote node. There should be a ftp user ID and password listed there (said from memory). Use those credentials to connect like you did with the ftp CLI from the master node to the remote node. See if you can login using ftp to the remote node. Then issue a ls command, Its not important what the answer is as long as it gives you an answer and not an error.

If you can’t login using those credentials then on the remote storage node look at the /opt/fog directory. There is a hidden file called .fogsettings. issue the command cat /opt/fog/.fogsettings In that file should be the password for the account used when the fog server was installed. Make sure they match what is on the master node.

There is something with ftp that is not working correctly, that is why the replication is not happening.

@Tom-Elliott said in Fog iPXE Menu no input:

@SotY The files of console.h/general.h/settings.h were updated 2 - 4 months ago. I don’t think anything here is the cause of the failure. I’ve attempted building and am seeing the same error.

This leads me to think something changed with ipxe code particularly surrounding USB_HCD_USBIO and efi built binaries. It seems the efi builder has a native compiler point for it’s own USBIO that’s being constructed separately from the “common” source.

If you just build the binaries without the USBIO configured, does it break things? I know you found a fix and wanted to try it, but it seems mcb30 (main developer of ipxe) made a change that seems to make the usbio drivers act differently in the past. What those changes were, I do not know at this time.

I am more surprised, in my quick review of things, that this even worked before as the components I see erroring haven’t change significantly.

If I change the usbio_driver line to efi_usbio_driver in the drivers/usb/usbio.c file, and re-run the builder, things build successfully. (Including the ncm–ecm-axge.).

If that works, I can put my diff file and copy it with the build script but I’m scared something I’m doing in the driver/usb/usb.c file might be unintentionally making things worse (not better) even though I’m getting successful builds now.

I have config files from previous version and all 3 were changed. I just narrowed it down to changes in general.h file. Compiling with USB_HCD_USBIO enabled works fine when using previous general.h and new console.h and settings.h files. I need more time to find out which change broke it. These are the changes:

------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ #define NET_PROTO_EAPOL /* EAP over LAN protocol */ #define NET_PROTO_LLDP /* Link Layer Discovery protocol */ ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ * 802.1x EAP authentication methods * */ #define EAP_METHOD_MD5 /* MD5-Challenge port authentication */ //#define EAP_METHOD_MSCHAPV2 /* MS-CHAPv2 port authentication */ /* ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ #define IMAGE_ZLIB /* ZLIB image support */ #define IMAGE_GZIP /* GZIP image support */ //#define IMAGE_UCODE /* Microcode update image support */ ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ #define FORM_CMD /* Form commands */ ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ //#define IMAGE_CRYPT_CMD /* Image encryption management commands */ ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ #define PARAM_CMD /* Form parameter commands */ <> #define PARAM_CMD /* Request parameter commands */ ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -+ #define IMAGE_MEM_CMD /* Read memory command */ #define IMAGE_ARCHIVE_CMD /* Archive image management commands */ #define SHIM_CMD /* EFI shim command (or dummy command) */ #define USB_CMD /* USB commands */ //#define FDT_CMD /* Flattened Device Tree commands */ /* * Certificate sources * */ //#undef CERTS_EFI /* EFI certificate sources */ ------------------------------------------------------------------------------------------------------------------------

It’s weird, git shows the last update for general.h on May 11, but I installed FOG on June 10 and that’s when I did git clone and back then the files were different than they are now. These are the files I got on June 10:

console.h: https://pastebin.com/wmy449T0
general.h: https://pastebin.com/GUyqbY3F
settings.h: https://pastebin.com/Ta738Fmn

@tacOS said in Literally cant even run ./installfog.sh -_-:

I keep getting told to run “su -” or “sudo -i”, while and after having run one, the other, or BOTH. just the same error over and over.

It’s a workaround but I managed to continue by editing installfog.sh and deleting the if-fi block that has this message. I think it’s using a very specific way of testing that might not work in every distro ( like the previous block that checks if the user ID is 0 to see if it’s root and it won’t work on distros that randomize the root’s ID). I’m working on Garuda Linux (Arch based), and I’ve hit another wall at the end with TFT but at least it’s installed.

@Small0145 No, it’s not.

@george1421 said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:

If undionly.kpxe worked in bios mode then snp.efi should work in uefi mode

Hi George, the BIOS claims its in UEFI mode but when booting it looks suspiciously like legacy (larger text etc). Its an old Viglin with a second generation i3 which is being retired this October so its not too much of a deal now I have a workaround.

@aurfalien said in Mellanox ConnectX 3 imaging issues.:

So all good here.

Did FOS Linux have the driver enabled for that 10GbE card (i.e. were you able to image with FOG once you got past the iPXE menu)?

FWIW: For uefi mode snp.efi or snponly.efi should work if undionly.kpxe worked in bios mode. I’m saying it should because ConnectX3 is a somewhat older card (circa 2017/2018).