Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
aktiviert. 90% Netzwerkzeit läuft per WLAN.
Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das eigentliche
OS bootet. LAN steht an 3. Stelle nach HDD und USB.
Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
wie gewohnt schnell voran.
Nun zwei Fragen:
1. Kann es durch einen anderen, aktuelleren Switch besser werden? Der
jetzige ist wahrscheinlich fast 20 Jahre alt, aber funktioniert eben
prinzipiell noch.
2. Oder ist das so normal und funktionsbedingt und ich muss damit leben?

Wer hat dazu ggf. eigene Erfahrungen und kann dazu was berichten?

Danke und Grüße zum WE
Jürgen

Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:

> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
> aktiviert. 90% Netzwerkzeit läuft per WLAN.
> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
> wie gewohnt schnell voran.

Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.

> Nun zwei Fragen:
> 1. Kann es durch einen anderen, aktuelleren Switch besser werden? Der
> jetzige ist wahrscheinlich fast 20 Jahre alt, aber funktioniert eben
> prinzipiell noch.
> 2. Oder ist das so normal und funktionsbedingt und ich muss damit
> leben?

Nein, aber die Ursache ist bisher unklar.

--
Gruß
Marco

Spam und Werbung bitte an
1714142999ichwillgesperrtwerden@nirvana.admins.ws

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
>> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>> wie gewohnt schnell voran.
>
>Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.

Das würde ich exakt andersrum vermuten.

Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
der Platte booten.

Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
=> dauert

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Das würde ich exakt andersrum vermuten.
>
> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
> der Platte booten.

Ich kenne auch BIOS oder UEFI, bei denen ein LAN-Kabel ohne Signal
trotzdem Abwarten eines längeren Timeouts bewirkt.

Wenn bei eingeschaltetem Switch ein sinnvolles Nnetzwerk anliegt, dann
würde es das beschriebene Verhalten erklären.

/ralph

Am 26.04.24 um 18:55 schrieb Marc Haber:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:

>>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>>> wie gewohnt schnell voran.

Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
sollte es überhaupt nicht auftreten - wenn man es nie braucht.

>> Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.
>
> Das würde ich exakt andersrum vermuten.

O-Yoda-J: "Unterschätze nie die Dummheiten eines BIOS/UEFI junger
Padawan" :-) SCNR.

> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
> der Platte booten.

Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
einsteckt. Dann ist der Link da und... (s.u.)

> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
> => dauert

Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
(TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
dann kann der nächste Eintrag der Bootorder greifen.

BTW. Manche Boards haben ja ein eigenes NIC Rom/Setup (Alt-A o.ä.?) oft
ein Intel Bootagent. Mein Eindruck bei denen die mir begegneten war das
die recht unabhängig sind von BIOS/UEFI Einstellungen. Wenn man es dort
deaktiviert heißt das noch nicht das der Bootagent lahm gelegt ist und
es nicht weiterhin versucht. Und mindestens einen hatte ich der sich
garnicht komplett deaktivieren ließ.

Bye/
/Kay

--
nix

Am 26.04.24 um 16:49 schrieb Jürgen Jänicke:
> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
> aktiviert. 90% Netzwerkzeit läuft per WLAN.
> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das eigentliche
> OS bootet. LAN steht an 3. Stelle nach HDD und USB.
> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
> wie gewohnt schnell voran.

Hallo,

manche PCs schauen vor dem Booten im Netz nach Updates fürs BIOS.
Das kann man in den BIOS-Einstellungen kontrollieren/einstellen.

Bernd Mayer

Kay Martinen <usenet@martinen.de> wrote:
>Am 26.04.24 um 18:55 schrieb Marc Haber:
>> Das würde ich exakt andersrum vermuten.
>
>O-Yoda-J: "Unterschätze nie die Dummheiten eines BIOS/UEFI junger
>Padawan" :-) SCNR.

Genau.

>> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
>> der Platte booten.
>
>Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
>es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
>einsteckt. Dann ist der Link da und... (s.u.)

Das würde mich überraschen. Aber gut, so viel Erfahrung mit
verschiedener Hardware habe ich da nicht.

>> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
>> => dauert
>
>Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
>(TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
>entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
>dann kann der nächste Eintrag der Bootorder greifen.

Das ist ein so interressantes Thema dass ich das gerne etwas näher
beleuchten würde. Vermutlich kennst Du das schon alles, aber es gibt
ja auch noch andere Leser.

Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
mich im Weiteren auf IPv4.

Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
im lokalen Netz an. Ja, das können mehrere sein.

Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
können oder unterschiedliche Informationen beinhalten.

Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
senden, wenn für konkret diesen Client eine Installation hinterlegt
ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
dem "eigentlichen" DHCP-Server.¹

Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
Optionen die das Telefon erwartet.

Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
daherkommt, daher ist es so wichtig dass in den beiden oberen
Sonderbeispielen weder das Softwaredistributionssystem noch die
Telefonanlage überhaupt ein DHCPOFFER versenden. Das
Distributionssystem wird schweigen wenn für einen Client keine
Installation hinterlegt ist; die Telefonanlage kennt typischerweise
den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
im Interesse des Anlagenherstellers liegt.

Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
Bestätigung seitens des Servers ist die Lease nun komplett.

Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
schon ziemlich schnell voll).

Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
üblich, dass im Server Logik wie diese hier hinterlegt ist:

|if exists user-class and option user-class = "iPXE" {
|filename "http://bootserver.example/pxe/default.ipxe";
|} else {
|filename "undionly.kpxe";
|}

Im Klartext bedeutet das "schaue in die vom Client übermittelte
DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."

Grüße
Marc

¹ Diese Systeme haben entweder einen eigenen IP-Adress-Range
hinterlegt und reserviert oder holen sich "hintenrum" eine Adressse
vom "eigentlichen" DHCP-Server per DHCP.
² Das ist dann übrigens kein Broadcast-Paket mehr, sondern ein
Unicast, das im Zweifel, wenn der Server nicht im gleichen Netz steht
wie der Client, ganz normal geroutet wird ohne dass das DHCP-Relay
nochmal eingreifen muss.
³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
schneller als das hier traditionell eingesetzte tftp. Außerdem kann
iPXE ein Menü anbieten und auch anderweitig mit dem Benutzer
interagieren. In meinem Labornetz bekommt jeder PXE-Client so ein Menü
zugeworfen, wo der Benutzer auswählen kann, von seiner lokalen Platte
weiterzubooten (was nach 5 Sekunden Wartezeit automatisch geschieht)
oder ob er ein grml oder einen Debian-Installer zugeworfen bekommen
möchte
¼ manche VMs benutzen direkt iPXE als ersten Schritt des PXE-Boots,
andere Systeme (wie z.b. die meisten "Bleche") wollen den ersten
Schritt klassisch per tftp.
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 26.04.24 um 16:49 schrieb Jürgen Jänicke:
> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
> aktiviert. 90% Netzwerkzeit läuft per WLAN.
> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das eigentliche
> OS bootet. LAN steht an 3. Stelle nach HDD und USB.
> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
> wie gewohnt schnell voran.

Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
dann keine Verbindung.

Wenn er die Verbindung eigentlich gar nicht braucht aber trotzdem
wartet, ist es ein BIOS Bug.

> Nun zwei Fragen:
> 1. Kann es durch einen anderen, aktuelleren Switch besser werden?

Abwegig. Wie soll ein anderer /ausgeschalteter/ Switch etwas besser
machen. Du müsstest schon das Mainboard tauschen.

Marcel

Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>
>
> Am 26.04.24 um 18:55 schrieb Marc Haber:
>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>
>>>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>>>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>>>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>>>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>>>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>>>> wie gewohnt schnell voran.
>
> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>
Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
2. Bootgerät: Removable Device
3. Bootgerät: disabled
4. Bootgerät: disabled

Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
mit deaktiven aber angestecktem Switch.

Danke des Denkanstoßes, ist ja eigentlich auch besser so. Dachte bislang
eben nur das LAN an 3. Stelle sich nicht auswirken sollte wenn vorher
was nutzbares vorhanden und gefunden wird.

Jürgen

Am 27.04.2024 09:19 Uhr schrieb Marc Haber:

> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
> mich im Weiteren auf IPv4.

Das geht ja mal gar nicht.
Interessant wird, wie der die eigentlichen Daten nachlädt. Bei Ubuntu
war das glaub NFS und da soll es wohl mit IPv6 noch Probleme geben.
Müsste ich ehrlich gesagt mal testen. Und heute ist Samstag, morgen
Sonntag, da wäre eigentlich Zeit dazu.

> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
> im lokalen Netz an. Ja, das können mehrere sein.
>
> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
> können oder unterschiedliche Informationen beinhalten.
>
> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
> senden, wenn für konkret diesen Client eine Installation hinterlegt
> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
> dem "eigentlichen" DHCP-Server.¹

Ist das nicht Garant dafür, dass Allerlei passieren kann?
Eines der Systeme bevorzugt einfach den ersten DHCP oder so?

> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
> Optionen die das Telefon erwartet.
>
> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Wird es das immer tun oder gibt es da schwarze Schafe?

> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
> schon ziemlich schnell voll).

IPv4 halt. :-)

> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
> schneller als das hier traditionell eingesetzte tftp.

Warum ist tftp signifikant langsamer?

--
Gruß
Marco

Spam und Werbung bitte an
1714202346ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>
>>
>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>
>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>
> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
> 2. Bootgerät: Removable Device
> 3. Bootgerät: disabled
> 4. Bootgerät: disabled
>
> Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
> mit deaktiven aber angestecktem Switch.
>
Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
BIOS trotz obiger Einstellung.

Jürgen

Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:

> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15
> Sekunden im BIOS trotz obiger Einstellung.

Ist die LED am Netzwerkport dann aus?

--
Gruß
Marco

Spam und Werbung bitte an
1714212610ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>>
> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Hallo,

was für ein PC ist das denn?

Was zeigt das BIOS 15 Sekunden lang an?

Bernd Mayer

Bernd Mayer <beam.bam.boom@knuut.de> wrote:
> Was zeigt das BIOS 15 Sekunden lang an?

Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
15 Sekunden Warten ohne Feedback quasi gar nix.

/ralph

Am 27.04.2024 Sa. um 13:39 schrieb Ralph Aichinger:
> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>> Was zeigt das BIOS 15 Sekunden lang an?
>
> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
> 15 Sekunden Warten ohne Feedback quasi gar nix.
>
Bei mir sind es aber im Normalfall genau 2,4 Sekunden.

Jürgen

Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15
>> Sekunden im BIOS trotz obiger Einstellung.
>
> Ist die LED am Netzwerkport dann aus?
>
Ja. Ist aus wenn Switch auch aus ist.

Jürgen

Am 27.04.2024 Sa. um 12:23 schrieb Bernd Mayer:
> Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>>>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
>> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
>> BIOS trotz obiger Einstellung.
>
> Hallo,
>
> was für ein PC ist das denn?
>
Ist ein Acer Aspire C24-1650 (ein all-in-one pc -mit dem ich ansonsten
rundum zufrieden bin)

> Was zeigt das BIOS 15 Sekunden lang an?
>
Die übliche Meldung:
"Press <Del> to Enter BIOS Setup Menu, Press <F12> to Display Boot Menu"

Jürgen

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 27.04.2024 09:19 Uhr schrieb Marc Haber:
>> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
>> mich im Weiteren auf IPv4.
>
>Das geht ja mal gar nicht.
>Interessant wird, wie der die eigentlichen Daten nachlädt. Bei Ubuntu
>war das glaub NFS und da soll es wohl mit IPv6 noch Probleme geben.

Das kommt darauf an was da gebootet wird. Der Debian-Installer ist ja
im Wesentlichen ein initramfs, der halt vom PXE-Bootloader per ftp
geladen oder von iPXE per http; grml lädt sein initramfs genauso. Wenn
man wirklich ein Betriebssystem aus dem Netz bootet, mit dem dann
später auch gearbeitet werden soll, möchte man natürlich ein
read/write fähiges Netzwerkfilesystem haben, aber bis das System so
weit ist ist der PXE-Boot längst gelaufen.

Mit IPv6 gehe ich davon aus dass das ganz ähnlich aussieht, DHCPv6 ist
halt subtil anders. Nur, welche Hardware hat einen IPv6-fähigen
PXE-Client in der Firmware?

>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
>> senden, wenn für konkret diesen Client eine Installation hinterlegt
>> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
>> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
>> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
>> dem "eigentlichen" DHCP-Server.¹
>
>Ist das nicht Garant dafür, dass Allerlei passieren kann?
>Eines der Systeme bevorzugt einfach den ersten DHCP oder so?

Bei der Softwaredistribution will der Client ja booten. Im DHCPOFFER
vom ersten Server sind keine Bootoptionen drin, also wird der
bootwillige Client dieses für ihn unbrauchbare DHCPOFFER als fü rihn
unbrauchbar verwerfen.

>> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
>> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
>> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
>> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
>> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.
>
>Wird es das immer tun oder gibt es da schwarze Schafe?

Auch hier wird es für seine Funktion auf die zusätzlich übermittelte
Option angewiesen sein. Softwarefehler sind natürlich immer denkbar.

>> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
>> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
>> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
>> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
>> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
>> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
>> schon ziemlich schnell voll).
>
>IPv4 halt. :-)

Bei IPv6 kommt man sogar ganz ohne Leases aus.

>> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
>> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
>> schneller als das hier traditionell eingesetzte tftp.
>
>Warum ist tftp signifikant langsamer?

Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
es wird also immer erst auf den Eingang der Quittung gewartet bevor
das nächste Datenpaket losgeschickt wird.

Da möchte man einfach etwas benutzen was auf TCP basiert und einen
vollständig implementierten TCP-Stack zur Verfügung hat.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Jürgen Jänicke <post@j-jaenicke.de> wrote:
> Am 27.04.2024 Sa. um 13:39 schrieb Ralph Aichinger:
>> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>>> Was zeigt das BIOS 15 Sekunden lang an?
>>
>> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>> 15 Sekunden Warten ohne Feedback quasi gar nix.
>>
> Bei mir sind es aber im Normalfall genau 2,4 Sekunden.

Glaub ich dir sofort, ich hab aber auch schon Server gehabt, bei denen
ich mich ernsthaft gefragt habe "ist der jetzt kaputt", dann hab ich
noch mal 30 Sekunden gewartet, und dann hat sich irgendeine
RAID-Firmware gemeldet.

/ralph

Am 27.04.2024 13:54 Uhr schrieb Marc Haber:

> Mit IPv6 gehe ich davon aus dass das ganz ähnlich aussieht, DHCPv6 ist
> halt subtil anders. Nur, welche Hardware hat einen IPv6-fähigen
> PXE-Client in der Firmware?

Mein ZBook 15 G1 (2013) behauptet das zumindest.

> >> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> >> Komponente wieder "von vorne" mit DHCP anfängt, damit die
> >> Beteiligen dieses Bootstrap-Prozesses nicht miteinander reden
> >> müssen. Dumme Server vergeben an dieser Stelle eine ganz neue
> >> IP-Adresse, was zusammen mit langen Leasezeiten durchaus lästig
> >> sein kann (weil ein PXE-Boot potenziell mehrere Leases belegen
> >> kann, und so ein /24 ist schon ziemlich schnell voll).
> >
> >IPv4 halt. :-)
>
> Bei IPv6 kommt man sogar ganz ohne Leases aus.
>
> >> ³ iPXE hat den großen Vorteil, dass es http spricht und den
> >> Großteil des zu bootenden Betriebssystem so nachladen kann. Das
> >> ist erheblich schneller als das hier traditionell eingesetzte
> >> tftp.
> >
> >Warum ist tftp signifikant langsamer?
>
> Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
> es wird also immer erst auf den Eingang der Quittung gewartet bevor
> das nächste Datenpaket losgeschickt wird.

Ist das bei den geringen Latenzen im internen Netz wirklich spürbar?
Ich habe per TFTP bisher nur Kram auf Geräte übertragen, die halt lahm
sind - Cisco-Router z.B.

--
Gruß
Marco

Spam und Werbung bitte an
1714218893ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:

> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
> > Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
> >
> >> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
> >> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
> >> 15 Sekunden im BIOS trotz obiger Einstellung.
> >
> > Ist die LED am Netzwerkport dann aus?
> >
> Ja. Ist aus wenn Switch auch aus ist.

Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
ausgesteckt am Switch.

--
Gruß
Marco

Spam und Werbung bitte an
1714218392ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 Sa. um 14:17 schrieb Marco Moock:
> Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:
>
>> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
>>> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>>>
>>>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>>>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
>>>> 15 Sekunden im BIOS trotz obiger Einstellung.
>>>
>>> Ist die LED am Netzwerkport dann aus?
>>>
>> Ja. Ist aus wenn Switch auch aus ist.
>
> Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
> ausgesteckt am Switch.
>
Genau so ist es immer gewesen. Habe immer nur den Stecker am Switch gezogen.

Jürgen

Am 27.04.2024 Sa. um 14:17 schrieb Marco Moock:
> Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:
>
>> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
>>> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>>>
>>>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>>>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
>>>> 15 Sekunden im BIOS trotz obiger Einstellung.
>>>
>>> Ist die LED am Netzwerkport dann aus?
>>>
>> Ja. Ist aus wenn Switch auch aus ist.
>
> Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
> ausgesteckt am Switch.
>
>
Habe nun das Problem (erstmal) prakmatisch gelöst. Es geht hier ja nur
um 100Mbit/s und da trenne ich die Verbindung mit einem 4pol.
Kippschalter. Den kann ich halt etwas günstiger erreichbar
positionieren. . .

Jürgen

PS: Und ja, funktioniert trotz einigen Zentimetern nicht normgerechter
Leitungsführung.

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>> Was zeigt das BIOS 15 Sekunden lang an?
>
>Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>15 Sekunden Warten ohne Feedback quasi gar nix.

Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
durchaus nicht unwichtige Metrik, auch in der Presse.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Jürgen Jänicke <post@j-jaenicke.de> wrote:
>Am 27.04.2024 Sa. um 12:23 schrieb Bernd Mayer:
>> Was zeigt das BIOS 15 Sekunden lang an?
>>
>Die übliche Meldung:
>"Press <Del> to Enter BIOS Setup Menu, Press <F12> to Display Boot Menu"

Bei besseren Firmwares kann man die Wartezeit an dieser Stelle im
Firmware-Setup konfigurieren.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402