@Tom-Elliott said in Dell Latitude 3340 with USB-C Ethernet Adapter - bad mac address registered:
posted a different init.xz image file, I don’t know if that file is still available.
I can confirm that the file still exists.
I would have hoped that the later kernels would support mac pass through by now.
@1337darkin My initial reaction is don’t use virtual box, my second thought is don’t use virtual box…
The thing is that vb uses iPXE as its own internal boot loader, and the issue is chaining with FOG’s version of iPXE. The screen shot you show is VB’s version of iPXE running trying to call snponly.efi where its failing. This is an issue with VB and not specifically with FOG.
I think there is a fix for this but I can’t seem to find it at the moment, google-fu is weak today.
On a totally abstract note. You can capture a uefi image with FOG in bios mode. And on the flip side you can capture a bios disk image in uefi mode. BUT to be able to boot that image after image/deployment the target computer’s firmware needs to match the disk image.
@hwa I’m not a parted magic user or have knowledge of. But can you point me to the iso you are using? I probably can convert a grub or syslinux config file into iPXE format.
@llino said in Configure iVentoy as netboot-Option in boot menu:
i’m thinking of adding another virtual Network to the to my fog server so I can run iventoy
Just be aware that FOG was not designed to have 2 imaging network interfaces. So it will be difficult to have fog respond to both subnets independently.
@youzersef I don’t have an immediate answer for you, but I can point you in a direction. The FOG Project has a wiki page on how to setup policies in windows dhcp server. The first section of your code is outlined in the policy. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
You might be able to do the user class part too, but I don’t know. Windows dhcp server policies are very similar to what you can do in linux.
@enginbey8108 If you don’t have an unattend.xml file to start with you can always use an online generator to give you an initial configuration file. You can use the one here: https://www.windowsafg.com/win10x86_x64_uefi.html
@youzersef said in add Ventoy to boot menu:
if you want i can post the configuration that i used to configure iventoy as next server after fog server
If this info would help the next guy, I would say yes. That way we can all learn from someone that has already walked the bloody path to victory. That’s what makes opensource and a community lead project work.
@youzersef Understand I’m just making some guesses here because I don’t know ventoy. But if you look at the ventoy document link I provided. There is a section that talks about a drop down list on the configuration page where you need to change the dhcp server mode to ExternalNet.
The second thing is it looks like they are running a customized version of iPXE (same thing fog uses as boot loader) but its qualifying the name and it doesn’t like ipxe.efi as the file name because its not its own app. I think this is why the error is being thrown.
@youzersef OK I find a few things. I still think we can make it work.
ref: https://ipxe.org/settings
To call microsoft wds server
set netX/next-server 192.168.1.2
set netX/filename boot\x86\wdsnbp.com
chain tftp://192.168.1.2/boot/x86/wdsnbp.com
translated
set newserver:ipv4 10.xy.xy.113
set newbootfile iventoy_loader_16000_uefi # I will explain later
set net0/next-server ${newserver}
set net0/filename ${newbootfile}
chain tftp://${newserver}/${newbootfile}
Now to the ${newbootfile} , why did I pick that file name? From this document: https://www.iventoy.com/en/doc_ext_dhcp.html It appears that they can use dnsmasq for auto boot file identification, based on they say how external mode works. What we want is to use “ExternalNet Mode” in this case we will let iPXE decide what boot file to use. And then instruct the client to boot the proper file. So when you use the code from above, you must test with a uefi based computer. Right now I want to see if you can boot into iVentoy. We can work on the next steps after we can verity we can chain into their app.
I think its possible to use this software we just need to find the right path.
There is another ref site that I’m just logging here but I think the above is right since it from the ipxe developers directly.
https://www.rcannings.com/pxe-chain-loading-from-pxelinux-to-ipxe-and-back-again/
@youzersef said in add Ventoy to boot menu:
what do you see in the boot gui is the ip adresse of the dhcp server.
What my confusion is if .1 is the dhcp server, why is iVentoy using that server to download ipxe.efi from? The .1 server should be referenced. If I saw .62 or .113 that might be understandable, but not .1.
Is your dhcp server a soho router? And for FOG are you using dnsmasq to make FOG boot correctly?
Also is this iVentoy app open source where I can see the ISO contents?
@abolajioriola Well this makes no sense at all. Same model and same firmware and same FOS linux kernel they should act the same.
If you have one laptop you know that works and one you know not work we can try to figure out the differences.
It will take some work on your side to get me the info I need. Its not hard but has a few steps.
First start with one or the other, for this discussion lets use the no working keyboard. Take that computer and schedule a deployment task to it, but before you hit the schedule task button, tick the debug checkbox. Now schedule the task (no worries we will not deploy anything at this time). Now pxe boot the computer, you should see several screens of text you need to clear with the enter key. Eventually you will be dropped to the fos linux command prompt.
This next part will make your debugging a bit easier. We will enable you to connect to the FOS Linux (target) computer over the network.
passwd give it a simple password like hello. Since we are discussing the not working keyboard, you may need to use an external keyboard here. It will be interesting to know if you can type on the not working keyboard at this point.ip a sFrom the ssh/putty shell to the target computer key in and copy out the following.
uname -a
lspci -knn
Copy those results out and post in this thread. Next use WinSCP/scp program to remote into the target computer and download the file /var/log/syslog to your computer and rename it to not_working.txt Post the results in this thread.
Now do the same with the other computer (working one) and post the results here. I will review the information and see if I can identify what is or isn’t working between the two.
Now finally you will need to go into the fog server and tasks and purge the two tasks related to these computers.
@youzersef I can explain why its doing what its doing. It has to do with the boot file name, its still picking up the ipxe.efi from dhcp. So the filename bit we are stuffing into dhcp is not being passed on to the target boot loader or its querying dhcp and still seeing fog stuff.
Its also not helpful to blank out the private ip addresses. I can’t tell where you are in the world from 10.x.x.x that is a non-internet routable IP address. Masking it just makes things a little harder.
What I did find interesting from the error message is how did 10.x.x.1 get into the conversation? The error message surely said iVentoy so some bits of it has to be loading.
@inconnu Ok if you can move the files via ftp then you have the permissions right. Now the login information you used for FTP, go into the web ui and look at the storage node (probably master or default) make sure the ftp settings there are correct. If not correct them.
Make sure the /opt/fog/.fogsettings password match what you used for logging into ftp. If yes then rerun the installer.
I have not seen issues with the database, but its always possible. In the same .fogsettings file there should be a user name and password for mysql.
From the fog server’s linux command line key in mysql -u <fog_use_name_from_settings_file> -p <password_from_file> fog
Make sure you can login with the mysql passwords from the config file.
If you want to make sure it works you can key in the following from the mysql console.
use fog;
show tables;
exit;
It should show you more than just an error message. Especially the show tables command.
@youzersef Here is from another recent thread. I have not tested this code, but it is for chain loading to another pxe boot loader. There are two methods. I also have doubt with the second method because I find references to both ways to set the new boot file. If the code below doesn’t work for setting the file name try this. But the way I set it in the below section seems right. Its iPXE that is responsible for chain loading a new boot loader.
set filename ${newbootfile}
The simples form is to add this to the fog ipxe menu builder parameter block.
chain tftp://192.168.1.12/nextboot.xyz || goto Menu
If nextboot.xyz uses dhcp information (which will point to the fog server unless we alter it.
set newserver:ipv4 192.168.1.12
set newbootfile nextboot.xyz
set net0.dhcp/next-server ${newserver}
set net0.dhcp/filename ${newbootfile}
set proxydhcp/filename ${newbootfile}
chain tftp://${newserver}/${newbootfile} || goto Menu
@youzersef The iso image appears to give you what you need. Looking in the grub.cfg file this menu entry really gives you the clues to what files you need from the iso.
menuentry 'Ventoy 1.0.97 LiveCD GUI' --id=LiveCD {
echo downloading kernel ...
linux /EFI/boot/vmlinuz quiet first_run rdinit=/VTOY/init
echo downloading initrd ...
initrd /EFI/boot/initrd
echo booting LiveCD ...
boot
}
Using the link that Tom provided and the above info it looks like you have what you need. Specifically you need vmlinuz and initrd from the iso image.
@Cire3 said in Chainloading Simple Next Server ?:
server:ipv4 10.22.24.8
set newbootfile netboot.xyz.efi
set net0.dhcp/next-server ${newserver}
You are missing the word set in the first line.
So I looked at the autoexec.ipxe file and this is what is in it :
OK then it looks like netboot.xyz uses ipxe (because of your autoexec.ipxe script)
So you might not need all of those set commands. Because FOG used iPXE as its boot loader AND netboot.xyz also uses iPXE, AND iPXE is already running in memory, all you should need to do is call that autoexec.ipxe script.
This is all that should be needed in the parameter block of the fog menu.
chain tftp://192.168.1.1/autoexec.ipxe || goto Menu
Where 192.168.1.1 is the ip address of your netboot.xyz boot server. There is a 50/50% chance of this not working because if they compiled custom stuff in iPXE that might be dependent.
@jaapvdpol Well lets see if we can get a few things sorted out here.
Scale: I have not seen an install yet with 100 storage nodes. Each storage node will need to be managed at some point in time.
I kind of see this as a two phase project.
Now in regards to dnsmasq, that is a service we can install on the FOG server. With our configuration it will send out pxe boot information to the local subnet its connected to. You don’t need to touch anything on the router or network. So when the mobile fog server arrives, so does the pxe boot information. When the mobile fog server leaves, so does the concept of pxe booting. In this design (mobile deployment server) the target computers are not designed to pxe boot through the fog server, but instead a tech sitting in front of the computer presses F10 or F12 during booting to get to the efi boot manager where the tech picks pxe boot.
Understand I’m just trying to tell you what’s possible. Since I don’t know 100% of your use case I can only give suggestions based on how FOG works.
@Thiago-Ryuiti said in Error generating image:
We did the entire procedure regarding changing the password and reinstalling fogproject,
Can you explain this? The reason why i ask is that there was some bad instructions on the internet that said to log into the fog server with the user fog and then install FOG. People were getting locked out of the fog account because the installer would reset the password. There was never an intent by the developers for admins to use the fog service account. So the developers changed the name of the service account to fogproject. So you saying “changing the password” is a bit suspect since you should never touch this account.
So what state is your install in at the moment? Can you ftp to the fog server using the account information in the .fogsettings file (ignoring the bit about sql server for the moment)?
@Cire3 The short answer is that it’s possible, but it depends on how nextboot.xyz handles dhcp information.
The simples form is to add this to the fog ipxe menu builder parameter block.
chain tftp://192.168.1.12/nextboot.xyz || goto Menu
If nextboot.xyz uses dhcp information (which will point to the fog server unless we alter it.
set newserver:ipv4 192.168.1.12
set newbootfile nextboot.xyz
set net0.dhcp/next-server ${newserver}
set net0.dhcp/filename ${newbootfile}
set proxydhcp/filename ${newbootfile}
chain tftp://${newserver}/${newbootfile} || goto Menu
@Thiago-Ryuiti The error is saying that the service account fogproject doesn’t have rights to the /images directory.
This typically happens for two reasons.