Notebook HP Envy X360 - LAN via USB-C-Adapter Anker

Hallo Gerhard - gut, wenn es geht!

Wir haben inzwischen 9 verschiedene Adapter, die wir bei jedem Endgerät durchprobieren, bis wir eine Kombination herausgefunden haben, die dann hoffentlich funktioniert.

Unsere Erfahrung: kein Adapter geht bei allen Geräten & kein Gerät funktioniert mit allen Adaptern.

Manche funktionieren immer erst beim 2. Bootversuch. Wir waren sogar mal kurz davor, zu glauben, dass das „Hochhalten des Kabels beim Boot“ hilft :wink: Schlangenöl wäre der nächste Schritt gewesen.

Gerade bei heterogener Hardware lohnt sich also ein kleiner Park an Adaptern…

Viele Grüße
Thomas

Hallo,

verstehe ich das richtig, daß einige USB-LAN-Adapter über PXE starten können?

Ich dachte, PXE funktioniert nur, wenn das BIOS den Chip auf der Hauptplatine unterstützt bzw. die Netzwerkkarte einen Bootrom mitbringt. Wenn das nicht gegeben war, startete man ein gPXE von Diskette…

Wie ist das heute, wenn Geräte nur noch WLAN eingebaut haben?

Grüße
Carsten

Hallo Carsten

ich hatte leider bei der letzten Auswahl von Geräten nicht genau geschaut und übersehen, dass das HP Envy X360 keine LAN-Schnittstelle mehr hat.

Denn schon mit LAN hat man mit Uefi etc. schon genügend Stolperfallen in die man reintreten kann.

Doch nun haben wir 21 solche HPs. Die haben nur noch 1 USB, dafür aber drei USB-C-Anschlüsse. Einer davon soll nun als LAN genützt werden. Deshalb die Idee mit den USB-C-Adapter.

Es scheint aber wirklich so zu sein, dass man hier einfach ausprobieren muss.
der USB-C-Adapter von Anker geht nicht, der USB-C-Adapter von Benefei schon.
Denke das liegt dann dran, welchen Chip im Adapter verbaut ist.

Wie Holger meint hängt es dann auch noch davon ab welches Linbo man einsetzt.
Bei uns leider noch 2.4, das kann dann wohl auch noch nicht mit allen Adapter umgehen.

Ich vermute, dass im Anker ein neuer Chip verbaut ist und in dem günstigen halt noch ein älterer Chip der aber dafür von Linbo „verstanden“ wird.

Eigentlich müsste man immer vorab ein Testgerät anfordern und dann erst kaufen. Doch meistens sind die Geräte so schnell wieder weg vom Markt, dass wir hier einfach immer wieder neu „basteln“ müssen.

Hallo Gerhard,

ja, es müssen die Treiber für die jeweils verbauten Chips vorhanden sein.
Was sagt denn lsusb bei Deinen Adaptern?

Ich habe welche mit Realtek:
lsusb -d 0bda:
Bus 001 Device 006: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN
Bus 001 Device 007: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Jedoch verstehe ich noch nicht, wie Du die Geräte einbinden möchtest, wenn PXE wegen fehlender eingebauten Netzwerkkarte nicht geht. Dann bleibt die Installation erschwert.

Bleiben die Geräte folgend mit dem USB-Netzwerkanschluß in Betrieb? Der USB-C-Anschluß ist mit dem Kabel sicher schnell hinüber, da er doch sehr klein ist und wenig Kraft viel Schaden anrichten kann.

Primär geht es um die Installation des Images und die Verteilung.

Im laufenden Betrieb der Lehrkräfte (diese NBs sind nur für die Lehrkräfte vorgesehen) wird in der Regel dann die WLAN-Schnittstelle genützt. Und wenn Linbo mal auf dem Rechner ist braucht es auch keinen LAN-Anschluss mehr.

Wir setzten die Geräte in der Regel in der Sommerpause auf einen aktuellen Window-Stand und setzen sie nur selten unter dem Jahr zurück.

Da ich glaube einen Workaround für die verschiedenen USB-Adapter Probleme zu kennen, schalte ich mich mal ein.

Das Problem mit dem PXE-Booten, liegt an den fehlenden Treibern im bereits installierten Linbo bzw. des EFIs des Geräts selbst (und das variert je nach Hersteller).
Workaround: Von einem USB-Stick booten, der iPXE mit den benötigten Treibern drauf hat. Hierfür sind folgende Schritte (unter Linux) notwendig:

  1. iPXE für EFI mit nötigen Treibern bauen.
git clone https://github.com/ipxe/ipxe
cd ipxe/src
make bin-x86_64-efi/ecm.efi NO_WERROR=1
  1. Image für USB-Stick erstellen. Da gibt es mehrere Möglichkeiten. Folgendes hat bei mir funktioniert:
truncate -s 3MiB  usb.img 
mkfs.vfat usb.img 
mmd -i usb.img "::/efi" 
mmd -i usb.img "::/efi/boot"
mcopy -i usb.img ecm.efi "::/efi/boot/bootx64.efi"
  1. USB Stick schreiben. Achtung löscht alle Daten. Pfad /dev/sda entsprechend unbedingt anpassen!
sudo dd if=usb.img of=/dev/sda
  1. Rechner so konfigurieren, dass er vom USB Stick bootet. Nach dem Boot mit CTRL-B drücken um die iPXE Kommandozeile zu erhalten. Dort dann autoboot eingeben. Wenn das Gerät dann mit Ethernet angebunden ist und Netzzugang hat, wird das aktuelle Linbo via PXE gebootet.
    Anmerkung: Falls nur eine USB Buchse vorhanden, kann man nach CTRL-B und vor autobootden USB-Stick entfernen und dann erst den Ethernet-Dongle anschließen.

Nach einem Sync wird das neue Linbo auf das Gerät geschrieben und die Prozedur oben ist nicht mehr nötig.

Auf diese Weise, habe ich auf Lenovo Geräten und sogar auf Microsoft Surface Go 2 Geräten (im Netz findet man oft Aussagen, das ginge nur mit den Original Microsoft Adaptern) Linbo aus dem Netz geladen.

Hoffe ihr könnt das gebrauchen,
LG,
Simon

In dem Fall, könnte aber auch einfach ein Linbo USB Stick verwendet werde. Die Linbo.iso kann in der Schulkonsole heruntergeladen werden.

@Till
klar das geht auch :slight_smile: Linbo hat ja auch iPXE an Board.
Hat Linbo auch immer die aktuellsten Treiber mit dabei?

AFAIK macht der Linbo Stick kein iPXE sondern startet das linbo linux direkt vom Stick. Die Treiber welche in diesem Linux zur Verfügung stehen sind immer jene welche auf der installierten Linbo Version des Servers bereitstehen.

Die Treiber im Linbo Linux werden ohnehin benötigt da sonst Festplatte / Netzwerkverkehr nicht möglich ist.

Den Fall gibt es ja wesentlich häufiger, rechner Startet per PXE, lädt hierüber das linbo system und landet im schwarzen Press 1 to shutdown, 2 to reboot Fenster da die Linbo Gui nicht nachgeladen werden kann(wird normal via rsync nachgeladen, kommt nicht per pxe mit)

Hallo Till,

und da wegen des Timings der Zugriff auf USB-Adapter fehlschlägt, die Idee mit der Wartezeit. Heute konnte ich das testen und es löst bei uns tatsächlich das Problem für viele USB2LAN-Adapter, dass die Rechner trotz funktionierendem PXE-Boot in Linbo offline sind.

Dank Thomas’ update-linbofs-Hooks kann man das jetzt einfach einbauen. Als PreHook-Skript:

#!/bin/sh
# Einfügen einer Wartezeit von 2 Sekunden vor der Netzwerkeinrichtung ;-)
sed -i '/^network\(\).*/a  \ \ echo "Warte auf Netzwerk..." && sleep 2' init.sh
exit 0

Dann wird die Wartezeit ins entsprechende Skript gepatcht. Zumindest, bis sich die Zeile davor ändert :slightly_smiling_face: (habe ich auch ans Doku-Team geschickt).

Viele Grüße
Thomas

Ich bin mir nicht ganz sicher, ob ich das Grundproblem verstanden habe - aber wäre das nicht ebenso mit dem dhcpretry Parameter zu lösen gewesen?

Hallo Till

Nein, das hat Holger schon vorgeschlagen. Das Problem tritt aber vorher auf.

Soweit ich das init.sh-Script verstehe, wird über alle Netzgeräte iteriert und jeweils versucht, eine Adresse zu bekommen. Dieser Befehl kommt aber für einige USB-Adapter zu früh. Man sieht das auch an der Leuchte - während sie blinken, wenn Linbo (erfolgreich) eine IP anfordert, leuchten sie beim scheiternden Versuch dauerhaft, bevor Linbo ohne IP fortsetzt. Und dhcpretry hilft da nicht, weil es noch gar keine Kommunikation über das Interface zu geben scheint. Ich gehe daher davon aus, dass die zu dem Zeitpunkt noch nicht gar fertig eingebunden sind in Linbo.

Es ist auch kein Treiber oder Adapter-Problem: diese Geräte booten PXE, bekommen da auch eine IP - das Problem ist das (erneute) Einbinden in Linbo. Wenn PXE nicht geht, booten wir vom Stick - aber auch dann besteht das oben beschrieben Problem.

Unser bisheriger Workaround war, im Debug-Modus händisch init.sh ein zweites Mal zu starten. Dann ist der USB-Kram fertig und bei diesem Durchlauf gibt es dann auch eine IP. Aber das hat andere unschöne Nebenwirkungen (macht man das z.B. in der Linbo-Konsole, werden danach alle Eingaben verdreifacht → Konsole unbenutzbar, die Angaben in der Linbo-GUI stimmen natürlich nicht…).

Ideal wäre es, wenn Linbo irgendwie vor dem dhcp-Befehl prüfen könnte, ob sich noch Adapter im Einrichtungsprozess befinden, aber das ist vermutlich schwerlich abzufangen. Ein anderer Vorschlag von mir war eine Wartezeit als Kernel-Parameter (analog zu dhcpretry) einzuführen.

Aber so funktioniert es bei uns jetzt erst einmal.

Viele Grüße
Thomas

Verstehe. Eventuell sollten wir dafür eine generelle Verzögerung einbauen.

Das Beziehen der IP Adresse kann übrigens auch via udhcpc getriggert werde :slight_smile:

So lange Linbo so einen unfertigen Zustand nicht erkennt (ich wüsste da nicht, wie man das ganz generell herausfindet), fände ich ein Kernel Parameter a la „netwait=2“ (wie aaO vorgeschlagen) hilfreich - dann würde es auch nicht verzögert, wenn es gar kein Problem gibt.

Aber da gibt es bestimmt noch andere/bessere Ideen. Ich fürchte nur, das Problem wird eher größer als kleiner, da ja immer weniger Endgeräte noch eingebaute LAN-Anschlüsse haben.

Es muss einfach nur eine Möglichkeit her, die Images über Wifi zu aktualisieren. Im Optimalfall während das Gerät in Windows / Linux steht, also unabhängig von Linbo :slight_smile:

Ja, da habe ich gedanklich auch mal dran gebastelt. Die Partition in Windows/Linux einbinden und per torrent aktualisieren.

Oder ein Verzeichnis/eine Partition, in das man hinein synchronisiert, aus dem sich Linbo dann die überprüften Daten holt.

Oder Linbo in einem speziellen Modus in einer VM starten, ohne GUI.

Viele schöne Ideen :wink:

Hallo. Das haben wir doch schon mal hier diskutiert:

Viele Grüße
Michael

Es muss einfach nur eine Möglichkeit her, die Images über Wifi zu aktualisieren. Im Optimalfall während das Gerät in Windows / Linux steht, also unabhängig von Linbo :slight_smile:

Unter Linux wäre es sicher nicht schwer, das Image im Cache zu aktualisieren.

Man könnte im im Hintergrund auch eine 2. Partition mit einem neuen Image herrichten, welche beim nächten Neustart genommen wird. In Biosen, Switchen oder bei Puavo geht das auch.

Genau! Vergleiche Beitrag #16