Hey Tom, take your time and get yourself settled!
I am wondering if this is a good point too where we reach out to the community for people to join into the FOG team to help work on the code, fix issues, improve stuff here and there.
Hey Tom, take your time and get yourself settled!
I am wondering if this is a good point too where we reach out to the community for people to join into the FOG team to help work on the code, fix issues, improve stuff here and there.
@Tom-Elliott, @Developers, @Moderators
I got carried away trying to improve the current iPXE script. Now that I’ve dug into the syntax and found some interesting new stuff I want to see what you guys think about this:
#!ipxe
isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck
:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto proxycheck
:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot
:proxycheck
isset ${proxydhcp/next-server} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck
:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv
:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv
:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot
Feel free to comment and improve. I’ve tested the script and tried to remember all the issues I came across in the last months but I am sure we’re not there yet.
@TrialAndError said:
Obviously the development of FOG stopped after a long time of hard work.
It would be friendly by the developers to inform the users about that.
I am not sure what exactly you mean. This is an open source project and we have no time schedule for new releases and we don’t have a set list of features to add or bugs to resolve. We simply do what we can and like.
It’s quite bizarre to state that FOG development stopped… totally wrong!
I want to thank Tom again for this! I tried to assist and help but I just don’t know the code (and its history) as much as Tom does. He’s done all the hard work to find and fix this issue. Along the way he also fixed a couple other things as well.
@Tom-Elliott Don’t say sorry. FOG is work in progress and you are pushing things way forward!! :metal:
We are working towards a most stable release of the 1.5.x line of FOG and will publish release candidates of FOG 1.5.9 for this over the next weeks. We ask people to participate and help test to get the final release as good as we can.
@Wirefall Great you posted the full kernel messages listing. At first I didn’t notice any issue but looking closer I found the issue:
igb: probe of 0000:01:00.0 failed with error -2
The PCI ID perfectly matches the one you mentioned in your fist post. Didn’t take long to find several reports on this issue that came in just lately:
https://lkml.org/lkml/2016/11/24/172
https://bugzilla.suse.com/show_bug.cgi?id=1009911
https://patchwork.ozlabs.org/patch/700615/
Some say that it might possibly work if you disable PXE boot for this NIC in BIOS. I don’t think this is a great solution as FOG heavily relies on PXE booting the clients. Let’s hope that this will be fixed in the latest kernel fairly soon!
@sudburr Why not re-install the whole system from scratch?
@Developers @Moderators Ok, I just opened a pull request to remove the 7156 binaries. Please all keep that in mind. Might cause some minor confusion in the next weeks. But it’s good to get rid of it.
As you all can see the tests of the most recent iPXE version shows that things are back to normal again. I reported back to Michael Brown on the iPXE devel mailing list. So he’s got that in mind as well.
@Avaryan To me this sounds like a different issue. Would you mind opening a new thread on this and posting more details (FOG version, USB ID of the NIC used as shown with lsusb
, …).
I’ll mark this solved/closed now. @Psycholiquid Thanks heaps for the great work on testing all the binaries and such!
@cyannella Sorry but this question is better asked in a forum about KVM or virtualization in general. It’s not something FOG is causing and most probably you get better answers from people with specific knowledge on KVM networking.
@seppim said in Advanced Login:
I guess I need to set the “Advanced menu command”? But why is this not out of the box working?
Yes, you need to add some custom advanced menu that you want to see after the login. There is no default.
Here is some example code you can start working on:
menu
item --gap -------------- iPXE advanced boot menu --------------
item DBAN Boot and Nuke
item SHELL iPXE Shell
item RETURN Return to previous menu
choose --default RETURN --timeout 10000 target && goto ${target}
:DBAN
kernel ${boot_url}/dban/dban.bzi nuke="dwipe" silent vga=785
boot
goto MENU
:SHELL
shell ||
goto MENU
:RETURN
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} ||
prompt
goto MENU
autoboot
Here is more stuff if you need: https://forums.fogproject.org/topic/7329/sub-menu-within-fog-advanced-menu
@Jacques-Olivier Try using mysqldbname=yourfogdbname
.
Do we need to add our external database parameters befoer lanuching the installation in /etc/my.cnf ?
No I don’t think you need to modify the local /etc/my.cnf - though the installer will ask you for the DB root password to be able to create the FOG database and unpriviledged user for you. So you need to make sure you are able to connect to the external database over network and login as DB root user.
I have to say that I have tested a lot when improving that part of the installer and make it more secure just before the 1.5.9 release but I never tested with a database on another host. Looking forward to hear from you if it works “out of the box”.
@seppim said in Advanced Login:
I want display a menu item only after login.
If that is what you want to do you need to take a look at iPXE General Configuration -> Advanced Menu settings. Here you can define a custom iPXE script that is being called after the login.
If you don’t have a text field for Advanced menu command then you need to disable your Adblock browser addon.
I set the “fog.advancedlogin” to “All hosts”
I think you need to switch that back to “Advanced Login Required”.
@ktif14 Sorry for the late reply. No, it’s not as easy as creating a new iPXE menu entry because a task needs to be created in the database. This can be done either by using the FOG web UI or the FOG API but not through the iPXE menu.
@noithatgooccho There are different ways of getting what you are calling a “local cache”. Though the solutions have different restrictions or requirements.
Install a normal FOG master node in that location (no connection to the other server), register all your local hosts in that new server (it’s own database), create image definitions and manually copy the image files over to that server. Every time the image on the pre-existing FOG server is changed you need to manually copy the image over again. But local hosts can also capture an image to that new FOG server in that location.
Install a FOG storage node in that location - which needs to be able to constantly contact your pre-existing FOG master node to query information from the central database. The image files will be replicated from the pre-existing master node to the new storage node once (every time the image changes) - no manual copying needed. The hosts in that location can pull (deploy) an image from that new storage node (local cache) in unicast mode. But be aware that hosts in that location can only upload/capture an image to the pre-existing master node, not to the local storage node.
So it depends on what you want to achieve.
@erasp21 Could be MAC-paththrough as well. Some BIOS/UEFI firmware has the capability to pass on the MAC address of your notebook to the USB-adapter. That might be the case when booting into Windows but not on PXE boot up in iPXE.
Please compare the MAC address you see:
@Goll420 Multicast can be tricky! It’s interesting you say that it used to be full speed - was that with the very same 12 hosts? Are all your hosts and the FOG server in the same subnet? New network equipment?
With multicast every hosts needs to be “in line” with the others. So one simple bootleneck anywhere will slow down the whole lot. So for example, one host is down to 100 MBit connection or having an issue with the disk.
I would try to tackle this issue using a method called “divide an conquer”. Split the group of 12 in two and let both of them do a multicast session one after the other. I would expect one group to go fast and the other one to go slow. If that is the case, split the slow group in half again and do a multicast for those 3 and 3 subgroups one after the other. See if you can nail it down that way.
If both groups (of 6) are going slow than I would start looking at the switch they are connected to.
@Poelie Not sure if you specific NAS will work but here is some information you can start working on: https://wiki.fogproject.org/wiki/index.php?title=NAS_Storage_Node
@seppim said in Capture Ubuntu 20.04 just free diskspace:
The Raid I need when a disk get failure (not so unusual)
If the disk dies you hopefully have a backup of the data as well as the FOG image to deploy that to a fresh disk in a few minutes.
Not saying that RAID is useless. Not at all. There are setups where RAID is great. But with FOG it’s not as simple if you want to use such things.
The setup as you have it now seems to be spread across three MD/RAID containers. I have no idea how to handle that in FOG. Simply setting host primary disk will probably not work.
I have not played with RAID setups yet and so this is just from the top of my head. Maybe there are other users with more insight into that topic. But I just want to give you hints trying to make this easier for you.