aQuantia AQtion PXE Compatability?
-
Hey guys,
Thanks for the help - I updated/recompiled iPXE as well as updated the Kernel to 5.15.19
Unfortunately I’m still getting the same issue- after that I tried compiling this branch of iPXE since it looked like it had the marvell/aquantia drivers: https://github.com/ipxe/ipxe/tree/7cfd66c389067fe0d0af65bbbe00954e6835e154/src/drivers/net/marvell
After doing that, I get what looks like some sort of hardware id or something after the initializing devices text, but then the workstation just reboots and I get the same issue as before.
Totally possible these are bad drivers though - I look forward to hearing what you think
-
@madnm said in aQuantia AQtion PXE Compatability?:
Unfortunately I’m still getting the same issue- after that I tried compiling this branch of iPXE since it looked like it had the marvell/aquantia drivers: https://github.com/ipxe/ipxe/tree/7cfd66c389067fe0d0af65bbbe00954e6835e154/src/drivers/net/marvell
Oh well, I didn’t notice this has not been merged into the official iPXE master branch. See the pull request is still open and there is a bit of poking on this topic but not much.
Please try building the vendor specific only driver binary via
make bin/marvell.pxe
and see if that binary behaves differently. You can also try buildingmarvell.kpxe
andmarvell.kkpxe
. In some cases buggy BIOS implementations can only code with one of those.As well post the PCI IDs of your particular network card found via
lspci -nn | grep -i net
or Windows device manager. Compare the PCI IDs with those found in the code. -
Ok so I ended giving up and manually imaged the computers with clonezilla, but I did try your suggestions and will post in case anyone else comes across this and has the time to take another stab at it-
For the life of me I could not compile the Marvell drivers - on a tangent while troubleshooting I found the most recent reply on that pull request pretty funny
So I blame the Marvell devs and will try to avoid them at all costs in the future, hahaPCI IDs:
AQC108 - [1d6a:d108]
Intel I210 [8086:1533] -
@madnm We do have an alternative to pxe booting into ipxe. We can usb boot into the FOS Engine bypassing iPXE. It would be interesting to see if FOS Linux could talk to that network adapter.
-
@madnm said in aQuantia AQtion PXE Compatability?:
AQC108 - [1d6a:d108]
OK, so at least this PCI ID is in the Code as “AQC08 Marvell AQtion 5Gbit Network Adapter”. So that’s a good start.
While I understand you have moved forward to get this system imaged it would still be great to keep looking into this to help make this work at some stage for you and/or the community.
Have you tried using the ipxe.pxe binary (
make bin/ipxe.pxe
) when building the mentioned commit that includes the marvell driver? -
@madnm Just an observation here.
The screen shot you provided in your OP indicates you are trying to pxe boot a bios computer. You should be using undionly.kpxe for the boot file. In this case the only network driver included is the undi driver, which is (should be) universal. If you were sending ipxe.kpxe then I could understand why you have a driver issue.
On the uefi side, you should be using the snp.efi boot loader, this is akin to the undionly.kpxe driver is to bios mode. The snp driver is the only driver loaded in the snp,efi file. Again this is a generic driver that uses the network adapters built in snp interface. So as I see it it shouldn’t be necessary to include the drivers into iPXE unless you want to use the ipxe.efi boot loader.
-
@george1421 said in aQuantia AQtion PXE Compatability?:
You should be using undionly.kpxe for the boot file. In this case the only network driver included is the undi driver, which is (should be) universal. If you were sending ipxe.kpxe then I could understand why you have a driver issue.
While you are right with this in general I might add that some hardware doesn’t play nice with the universal UNDI (legacy BIOS) or SNP (UEFI) interfaces. I guess this is the case with this AQN-108 as well.
@madnm See more details on the different iPXE binaries here: https://ipxe.org/appnote/buildtargets
-
@madnm I had a go with this myself and was able to build a marvel only iPXE binary using the following command:
make bin/aqc1xx.pxe
Sorry for pointing you the wrong direction at first. I am not an iPXE developer and hardly know their source code and build fundamentals. Making it up as I go.
So here is what I did:
git clone https://github.com/ipxe/ipxe marvell_test cd marvell_test git fetch origin pull/370/head:test-marvell-branch git checkout test-marvell-branch cd src/ wget -O ipxescript https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/ipxescript cd config/ wget -O console.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/console.h sed -i 's/dynamic/us/g' console.h wget -O general.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/general.h wget -O settings.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/settings.h cd .. make bin/aqc1xx.pxe EMBED=ipxescript
Now copy
bin/aqc1xx.pxe
to your TFTP directory and point your DHCP to that filename. Be aware that other machines will probably fail to PXE boot on that binary.And if that doesn’t PXE boot your machine you can go ahead and enabling debugging output:
make bin/aqc1xx.pxe EMBED=ipxescript DEBUG=aqc1xx,atl_hw
-
@sebastian-roth Sorry for the super late reply - had to reimage one of the hosts again and came back to this - the binary built using your instructions here worked! Thanks a ton
-
@madnm You are welcome.