PXE/kernel drivers: newbie weet niet waar hij moet beginnen

[TheWickedD]

Hoi! Ik heb een voor mij nogal complex probleem, en, belangrijk, geen Linux expert in de buurt. Ik zou graag advies ontvangen over wat een goede route is om onderstaande aan de praat te krijgen:

Ik heb een opstelling waar ik een stel machines via PXE naar een imaging environment wil booten. Deze machines hebben blijkbaar exotische netwerkkaarten (Cavium QL41112HLRJ) die ik graag zou willen gebruiken om het imagen vlot te laten verlopen. Voor imagen gebruik ik CloneDeploy. Nu hebben standaard Linux kernels (zowel gedownload van kernel.org als de kernels meegeleverd met CloneDeploy) blijkbaar niet de juiste drivers aan boort (of als ik het internet goed begrijp, niet de juiste firmware?). Ik heb tot kernel 5.0.5 geprobeerd, 4.20 is standaard meegeleverd met CloneDeploy, maar er zijn instructies om je eigen in elkaar te schroeven. Eenmaal in de kernel geboot krijg ik deze output, waar je alleen de onboard intel NICs in ifconfig ziet.

Als ik in Ubuntu 18.04.2 (kernel 4.18) geboot ben en daar de drivers van de fabrikant heb geinstalleerd, dan werkt het wel.

Dus, het probleem: hoe krijg ik deze NICs aan de praat in de omgeving waar ik naar PXE-boot?

Opties die ik kan bedenken:

1. Zelf kernel compileren. Ik heb geen idee hoe de drivers zomaar in een kernel te compileren (het is een DKMS package als ik het goed begrijp, en blijkbaar moet ook ergens de juiste firmware beschikbaar zijn tijdens boot)
2. Werkende kernel transplanteren. Ik dacht, ik heb een werkende Ubuntu setup, dus ik pak gewoon de kernel en bijbehorende initrd daarvan en PXE boot daarnaar. Leuk idee , maar werkt niet.

Ik hoop dat iemand dit een leuk probleem vindt en mij een zetje de goede richting op kan geven.

[ Voor 1% gewijzigd door TheWickedD op 27-05-2019 16:45 . Reden: typo, tekst verbeterd ]

[Hero of Time]

Het zou zo eenvoudig moeten zijn als weten in welk package van CloneDeploy extra firmware te vinden is. Je zou de bestanden die Ubuntu levert mee kunnen geven bij je PXE omgeving. Zorg dat de bestanden in /lib/firmware te vinden zijn.

Ik weet echter niet of firmware zo vrijelijk tussen kernels is uit te wisselen, dus je zal met wat trial en error aan de slag moeten gaan. Let hierbij op de afhankelijkheden mbt bestanden die het zoekt en verwacht. Ik kan het bestand wat in je screenschot wordt genoemd niet in mijn repo (op Debian) vinden bijvoorbeeld.

[Thralas]

Hero of Time schreef op maandag 27 mei 2019 @ 19:03:
Het zou zo eenvoudig moeten zijn als weten in welk package van CloneDeploy extra firmware te vinden is. Je zou de bestanden die Ubuntu levert mee kunnen geven bij je PXE omgeving. Zorg dat de bestanden in /lib/firmware te vinden zijn.

Ja, dat blijkt inderdaad uit de output: er wordt een driver geladen, maar er ontbreekt wat firmware. Drivers of kernels compileren is dus waarschijnlijk overbodig.

Ik weet echter niet of firmware zo vrijelijk tussen kernels is uit te wisselen, dus je zal met wat trial en error aan de slag moeten gaan. Let hierbij op de afhankelijkheden mbt bestanden die het zoekt en verwacht. Ik kan het bestand wat in je screenschot wordt genoemd niet in mijn repo (op Debian) vinden bijvoorbeeld.

Firmware is in principe versioned, je kunt 'm dus gewoon bij de bron afhalen: https://git.kernel.org/pu...alues_zipped-8.37.7.0.bin

Kwestie van de image aanpassen (/lib/firmware/qed/qed_init_values_zipped-8.37.7.0.bin) en het zou gewoon moeten werken.

[CH4OS]

Misschien zijn van de NIC's ook andere drivers die werken, bijvoorbeeld omdat de chip op andere NIC's ook gebruikt worden?

[Hero of Time]

CH4OS schreef op woensdag 29 mei 2019 @ 12:44:
Misschien zijn van de NIC's ook andere drivers die werken, bijvoorbeeld omdat de chip op andere NIC's ook gebruikt worden?

Als er bij de ene module/driver firmware vereist is, zal dat bij een andere ook zo zijn. Het zal niet op magische wijze met een andere module zonder firmware gaan werken. Of men heeft heel nasty de firmware in de module gebakken (als dat überhaupt kan, geen idee).

[TheWickedD]

Bedankt voor de input! Ik heb het initrd.xz bestand waarvan geboot wordt geunpacked, er zat een ext2 filesystem in als bestand, dus dat heb ik gemount. De folder /lib bestond natuurlijk, /lib/firmware bestond niet. dus ik heb /lib/firmware/qed gemaakt en het juiste bestand erin gekopieerd. Helaas krijg ik nog steeds dezelfde foutmelding. Hier een nieuwe foto ervan, want met een iets andere grep krijg ik twee regels meer informatie.

Ik vond dit: "Also, if you built r8169 into kernel (not as a module) the firmware will not load because at the time kernel loads the root filesystem is not mounted yet", misschien dat dit ook mijn probleem is? Zou ik proberen de kernel opnieuw te compileren en voor de relevante stukkie uit te kernel "m" ipv "y" te zetten (is het zo simpel)? Ik neem aan dat ik dan ergens een los module bestand (of meerdere) krijg. Waar vind ik die en waar in de initrd image dump ik ze?

[Hero of Time]

Als je wilt weten hoe dat gaat met firmware in de initrd, spiek dan eens hoe men dat Red Hat/CentOS doet. Die kan je namelijk zonder problemen via PXE (en via USB) installeren op servers en gelijk netwerkverbinding hebben terwijl een distro als Debian met de melding komt dat het firmware nodig heeft.

Anderzijds kan je ook gewoon kijken hoe ze dat bij Ubuntu doen met firmware, en ook bij Debian kan je kijken omdat ze naast de standaard images en netinstall een aparte installer aanbieden waar firmware is bijgeleverd.

In je OP heb je 't ook nog over CloneDeploy. Wat wil je precies starten via PXE voor welk doel?

[Thralas]

TheWickedD schreef op vrijdag 31 mei 2019 @ 15:25:
Helaas krijg ik nog steeds dezelfde foutmelding. Hier een nieuwe foto ervan, want met een iets andere grep krijg ik twee regels meer informatie.

Wat hier ontbreekt is de rest van de kernel log. En je zou in de shell natuurlijk moeten controleren of de firmware file inderdaad op z'n plek staat.

Is dat het geval? Dan de kernel log nog eens aandachtig doornemen om te zien of de driver niet eerder wordt geladen dan de initrd gemount is. Ik vermoed dat dat het geval is, want:

quote: https://www.kernel.org/do...ware/direct-fs-lookup.rst

Drivers which are built-in to the kernel should have the firmware integrated
also as part of the initramfs used to boot the kernel given that otherwise
a race is possible with loading the driver and the real rootfs not yet being
available. Stuffing the firmware into initramfs resolves this race issue,
however note that using initrd does not suffice to address the same race.

Zou ik proberen de kernel opnieuw te compileren en voor de relevante stukkie uit te kernel "m" ipv "y" te zetten (is het zo simpel)?

Nee. Als je hebt vastgesteld dat de race inderdaad je probleem is, dan zou ik de kernel rebuilden en als enige wijziging de firmware inbouwen.

Let er daarbij wel op dat de firmware name ook de 'qed' directory moet bevatten.

code:

CONFIG_EXTRA_FIRMWARE="qed/qed_init_values_zipped-8.37.7.0.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/pad/naar/bovenstaande/"

[Kees]

Je moet de qede module hebben. In ubuntu zit die in linux-modules-extra voor 5.0. Geen driver van de fabrikant voor nodig.

[TheWickedD]

Bedankt allen weer!
@Kees, de qede drivers zitten inderdaad in de kernel tarball, het probleem is dat er blijkbaar een firmware nodig is die er niet bij zit en niet te laden is.

Maar, dat is nu opgelost met jullie hulp! Na boot zie ik de firmware inderdaad in /lib/firmware/qed, dus initrd zit goed. Maar dat werk dus niet, als die quote over initrd al aangaf. Ik heb dus ff kernel 5.1.6 gedownload en zoals @Thralas heeft gesuggereerd CONFIG_EXTRA_FIRMWARE gebruikt tijdens de build. Dat werkt!

Ik gebruik CloneDeploy (wel, hoop het te gebruiken) om snel een kamer vol machines van een image te kunnen voorzien, die worden regelmatig veranderd. Ik ben nu een stap dichterbij, maar helaas is mijn doel nog niet bereikt. Ik bereik maar ongeveer 95 MB/s tijdens de deploy. Dit is al een flinke verbetering omdat de transfer nu over het hoofdnetwerk ipv het management netwerk gaat (wat maar 1 Gbit/s voor alle systemen bij elkaar heeft), maar ik heb voor mijn plannen eigenlijk minstens de dubbele snelheid nodig. Een bestand vanaf de server trekken vanuit ubuntu gaat op bijna 500 MB/s, meer dan genoeg, dus er zou rek in moeten zitten (op Windows loopt het op bijna 2 GB/s omdat het NICs met twee poorten zijn, maar dat is weer niet nodig, en dan moet ik nog RDMA en SMB direct op linux uitvogelen ook, hoop ik over te slaan).

Ik zal nu eerst kijken of de langzame transfers door de CloneDeploy tooling komt (wat voor snelheid behaal ik als ik direct vanaf de command line zo'n bestand kopiëer?), of dat het komt omdat de driver die met de linux kernel meekomt flink verouderd is. Als het niet door de tooling komt, dan denk ik dat het een goed idee is om uit te zoeken hoe ik de nieuwe driver in mijn kernel of initrd krijg. Dan zal ik inderdaad uitzoeken hoe Ubuntu dat doet. De driver module wordt door dkms geregeld, misschien dat ik na een "make modules && make modules_install" dkms op de gegenereerde initrd los kan laten ofzo. Zien we dan wel.

bedankt tot zoverre, ik verwacht dat ik binnenkort weer terugkom in deze thread met vervolgvragen.

[Hero of Time]

DKMS is alleen zinvol voor systemen die reeds draaien en kernel updates krijgen. Het bouwt namelijk dynamisch en automatisch de kernel modules voor de nieuwe kernel zodat het bij het opstarten ook beschikbaar is. Denk aan je video driver of een module voor je hypervisor. Het is niet om modules in je initrd te zetten.

[TheWickedD]

Ah ok, ik kan de up to date driver dan vast als "normale" module bouwen. Leuk om eens te proberen, was al wat over kernel modules aan het lezen.

[TheWickedD]

Aha. Als ik de share direct mount op de console na PXE boot kan ik met rsync op bijna 600 MB/s kopieren. Dus qua drivers zit het goed. Dan nu de clonedeploy tooling nalopen
Edit:
Het blijkt dat het compressiealgoritme dat gebruikt werd voor het diskimage de boosdoener was. gzip is langzaam. Ik kon ook lz4 kiezen, wat veel sneller werkt. Het image wordt nu op de schijf geplempt met net over de 300 MB/s, wat betekend dat het binnen 3 minuten gepiept is. Prima! Hiermee is mijn probleem geheel opgelost. Bedankt voor de geweldige hulp!

[ Voor 54% gewijzigd door TheWickedD op 01-06-2019 23:41 . Reden: opgelost! ]