@grey Well that didn’t work out well. Can you take a screen shot where you see the error with a mobile phone and post it here?
I would still like to see you disable pxe booting on all LOM network adapters and have you attempt to pxe boot off an older nic installed in a riser slot. The only goal here is to get to a FOS linux command prompt. From there we should be able to review the boot time logs.
@mbarker I understand your logic and decision to look elsewhere. If you decide to circle back to the FOG Project we will be here to help.
Just for my knowledge what hardware are you running the FOG server on. It has no bearing on your results other than I’m interested in the hardware setup.
@grey Well I guess we miss something here. Lets start over.
@grey are you looking in the FOS Linux on the target computer? These logs will not be on the fog server.
@mbarker Even before Tom posted, my intuition is telling me your FOG install is botched/been tweaked a little too much. I can’t explain why I feel this, but I can’t escape the thought you shouldn’t be having this level of difficulty getting this to work.
My recommendation would be to rename /var/www/html/fog to fog.old and /tftpboot to /tftpboot.old and then go back to the files you downloaded for FOG in the /bin directory and rerun the fog installer. That will put everything back to a known configuration. Once the installer is done then create the two links as I mentioned in my tutorial. Then reboot your fog server. Dnsmasq will still be setup so that part (that works) should be OK.
@george1421 I do have to say that getting the networking working is only your first roadblock. You still have to deal with the disk (raid) controller.
@grey OK I just… dang he’s fast.
As Tom posted you need to crank up the logging level first then do the process I outlined. That will increase the linux kernel verbosity so hopefully it will give us a better idea what firmware it wants.
@grey said in bnx2x fails to load firmware on Dell R430:
@george1421 said in bnx2x fails to load firmware on Dell R430:
@grey yep thats it. I didn’t have lspci on my vm. I just found the package that had it and I can confirm its -nn.
@Developers when you get a chance can you look into the FOS kernel and see if these specific nics are supported?
i tried to figure that out, but while i’m comfortable in linux, i don’t know how to get into the fog kernel while its running, i tred ssh and it did’nt connect. is there a write up on how to do that? I’d be happy to try.
There isn’t a specific write up but I can tell you how to go about it.
Manually register one of these servers. Then schedule a image capture and be sure to check the debug option. Then pxe boot the target computer it should after a few messages drop you to a command prompt. Now with that firmware message you may never get to a FOS Engine command prompt. But lets assume you do. You can either navigate around using the server console, or simply give root a password, then you can connect via putty or ssh.
On the FOS linux you will want to navigate to /var/log and look at boot or dmsg files to see if you can find out any more details about the firmware.
@Tom-Elliott Tom just to be sure I understand. This info is not impacted by the FOG logging level, the OP needs to look at dmsg inside FOS for clues on what firmware is missing?
Is there any kernel parameter we can pass to increase the verbosity of the FOS linux debug messages?
@grey yep thats it. I didn’t have lspci on my vm. I just found the package that had it and I can confirm its -nn.
@Developers when you get a chance can you look into the FOS kernel and see if these specific nics are supported?
@grey That output looks like its from linux. The developers will really need the id codes. I think the command is lspci -M or one other command switch. I think in linux it will be something like 8086:1453 (made up number) the first group is the manufacturer and the second one is the nic model.
This is probably the broadcom driver pack needed for the network adapter.
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=PXJ15&fileId=3542331442&osCode=RH60&productCode=poweredge-r430&languageCode=en&categoryId=NI
(not providing a solution here only collecting data right now)
From the Dell spec sheets (and from the error message) I can see the LOM NIC adapters are broadcom. From the spec sheet they appear to be “Broadcom BCM5720”.
Yeah my bet is because that server is SOOOO new that the FOS Engine kernel is miss identifying the network adapter and tries to patch it. Ideally it would be to get one of those nics to work but that may take some time for the linux developers (not FOG developers) to create the drivers. The quickest way to get this up and running is to install an older GbE nic in a riser slot. And then pxe boot off of that.
Do you have windows running already on one of these R430s? If so could you get the vendor ID and hardware ID of these nics? The FOG developers will need this information.
And lastly I have to be “that guy” FOG is intended to image workstations not servers. Moving into the server area opens up a new can of worms with raid controllers and crazy redundant hardware, all requiring specific linux hardware drivers. That’s not a space the developers are interested in, at this moment in time. Understand I’m not saying no, just meh.
@x23piracy Are you currently using ldap authentication today? I think I found a good example code that I can upgrade the bits in the plugin. I just want to make sure the upgraded bits don’t break what you are using.
@mbarker Ok the next step is to ensure that we have the proper boot kernels.
https://fogproject.org/inits/init.xz
https://fogproject.org/inits/init_32.xz
https://fogproject.org/kernels/bzImage
https://fogproject.org/kernels/bzImage32
These links will download the latest (current) kernel and inits. They go in /var/www/html/fog/service/ipxe
Also when ipxe loads there is a version number and a hex number in parentheses, what is that hex number.
Just for clarity what device are you trying to pxe boot into fog? Is it configured for uefi or bios (legacy) mode?
I feel you have the dnsmasq part setup right now so we can rule that out as long as you have your links correct as I have defined them in the tutorial.
@mbarker Yeah, I would review my config file when you have a chance, but this line jumped out at me right way.
dhcp-boot=undionly.kpxe,,<fog_server_IP>
The fog server IP address should appear twice in your config file, you missed this one.
I wrote a tutorial a while ago about my experience with dnsmasq. I did not follow the one from the official fog wiki page but arrived at a working solution. In my case I did this with my home kit using my home firewall as the dhcp server and the fog server running dnsmasq. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7
The efi section of my dnsmasq config file will only work if you are running the lastest dnsmasq.
Since then the dnsmasq group (not FOG) made upgrades to dnsmasq so that dnsmasq will deliver the proper boot file (undionly/ipxe.efi) depending on the computer asking for dhcp proxy info. This version of dnsmasq hasn’t made it into the linux distribution chains just yet. But right now you need to walk before you run.
@mbarker dude, I said not to use pxelinux.0
Is this what you created the sym links to?
I have some paperwork (sorry real job) to take care of but I’ll be back soon to dig a bit deeper.
@mbarker said in Modifying Boot Menu:
I tried with both the 32 bit and the 64 bit version of bzImage/init.zx and the same error still comes up.
This concerns and confuses me a bit. You should not have to mess with these files. I’m going to recommend that you go back to the 1.3.0 files that you downloaded and rerun the bin/installfog.sh install script again to resync everything.
Also please post your config file from dnsmasq, again the only time I’ve see this get messed up is when the kernel doesn’t match the vhd file or pxelinux.0 or an old version of iPXE is being used.
And your symbolic links are to the current ipxe files of undionly.kpxe and ipxe.efi? The dnsmasq program always tags a .0 (dot zero) on the end.