P.S: Heißt dhcpretry=30 wirklich, dass die ganze Zeit verwendet wird,
oder nur dass maximal 30 Sek. Zeit für DHCP eingeräumt wird, aber sobald
die IP bezogen sofort weiter gemacht wird?
meinem Gefühl nach: der wartet das ab: die ganzen angegebene Zeit.
Nein das ist falsch, sobald der Client eine IP hat, startet er durch. Wichtig ist das ganze für Notebooks welche ohne Netzwerkkabel starten sollen. Diese warten 30 Sekunden ab bis es offline weiter geht.
Wichtig ist das ganze für Notebooks welche ohne Netzwerkkabel starten sollen. Diese warten 30 Sekunden ab bis es offline weiter geht.
So ist das in der Tat. Aber warum eigentlich? Ohne Kabel (und das wissen die Computer ja heutzutage) ist es doch kompletter Blödsinn, überhaupt DHCP zu versuchen. Weiß jemand, warum das so ist?
der Parameter an sich ist schon sinnvoll. Wenn ein Kabel steckt, dann kann es immer noch lange dauern.
Was ich meine: Wenn kein Kabel steckt, dann wird DHCP garantiert nicht klappen. Das sollte der DHCP-Client merken und sofort aufgeben. Zumindest wäre das ein sinnvolles Standardverhalten.
Nun habe ich aber ein wenig recherchiert: Offenbar ist das Konzept, dass andere Komponenten dafür zuständig sind zu erkennen, ob überhaupt eine physikalische Verbindung besteht Die starten dann den dhclient oder eben nicht.
Unter Linbo könnte man z. B. unter /sys/class/net die vorhandenen Interfaces suchen und dann z. B. mit cat /sys/class/net/eth0/carrier feststellen, ob ein Kabel steckt. Wäre vielleicht mal ein FR.
Meine Erfahrung mit Linbo ist ja schon ein paar Jahre alt … Damals haben die Kolleg:innen sich auch bei den Rechnern am LAN am zweimaligen Start von Linbo gestört. Die Lösung war GRUB so einzustellen, dass gleich das OS gestartet wurde. Eine Synchronisation konnte so nur der Benutzer erzwingen, wenn er Probleme hat. Die hätte den Kolleg:innen -mit konventionellen HDDs- erst recht zu lange gedauert. Wenn ich ein neues Image verteilen wollte, hab ich temporär wieder eingestellt, dass Linbo gestartet wird. Dieses Vorgehen war besonders für die Notebooks im WLAN hilfreich.
Heute mache ich erst mit OPSI bei denen auch so, dass Updates nicht automatisch zugewiesen werden. OPSI funktioniert zwar via WLAN, aber in Praxis fehlt dann -verstandlicherweise- die Bereitschaft die Installation beim Herunterfahren abzuwarten. So kommt dieser Vorteil von OPSI bei Notebooks leider nicht zum Tragen. Ich bau die Notebooks für Updates also außerhalb der Unterrichtszeit raumweise auf und lass sie updaten. Wenigstens muss ich sie dazu nur an Strom anschließen und einschalten.
Ich habe die T430 bis jetzt immer noch nicht ans Laufen bekommen. Ich könnte nochmal Hilfe benötigen, was ich nun am besten noch probieren kann.
Ich habe daher alles zusammengefasst.
Fehler:
Die LINBO-GUI startet nicht und es gibt weiterhin die letzten Meldungen vor der Reboot-Aufforderung sind (nur im abgefilmten Video erkennbar):
Succesfully mounted Cache partition Fatal: Cannot read network infos. Continuing offline. Failed to install linbo-gui from cache
und danach [Press [1] to reboot oder [2] to shutdown bei Offline Boot
so wie auch in dem anderen Thema, was zur Zeit läuft:
Fakten zum T430-Client:
Ca. 4 verschiedene T430 getestet, die in der LMN6 problemlos laufen, außerdem: „…habe ich von einem Client das T430 gepingt während es startete. Der Ping kommt direkt nach dem Erhalten der ersten IP 2x durch (das Gerät ist schon in workstations aufgenommen) und sonst nie.“
=> defekte Netzwerkkarte ist wohl auszuschließen
Festplatten vorher mit gparted komplett gelöscht um LMN6-Reste auszuschließen
=> kein Problem mit LMN6-Resten
Hier die Ausgabe von lspci auf einem T430:
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
=> „Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)“
und
„Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)“
finde ich da. Hat jemand eine Ahnung, ob der Controller der LAN-Buchse in LINBO unterstützt wird?
Mittlerweile habe ich wirklich den Netzwerktreiber in Verdacht, der bei LINBO fehlen könnte.
Wie könnte man das am besten herausfinden?
Fakten zum Anschluss der T430:
Alle anderen Clients mit unterschiedlicher Hardware (HP dc7700, HP Elte 8300, FuSI Celsius W360, Lenovo T60 etc.) funktionieren in der selben Hardwareklasse, am selben Netzwerkkabel angeschlossen wie die T430 problemlos.
Habe auch mal eine neue Hardwaregruppe für die T430 angelegt und (nach Geräteimport) weiter probiert, aber mit selben Erfolg
=> keine defekte start.conf
Aber zur Vollständikkeit hier mal die start.conf:
[LINBO]
Server = 10.1.0.1
Group = mgb_mint-una_bios_sata
Cache = /dev/sda2
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = rsync
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
BackgroundColor = 394f5e
BackgroundFontColor = white
ConsoleFontColorStdout = lightgreen
ConsoleFontColorStderr = orange
SystemType = bios64
KernelOptions = dhcpretry=30 server=10.1.0.1
clientDetailsVisibleByDefault = yes
[Partition]
Dev = /dev/sda1
Label = ubuntu
Size = 30G
Id = 83
FSType = ext4
Bootable = yes
[Partition]
Dev = /dev/sda2
Label = cache
Size =
Id = 83
FSType = ext4
Bootable = yes
[OS]
Name = Linux Mint Una XFCE
Version =
Description = Ubuntu 18.04
IconName = mint.svg
Image =
BaseImage = mgb_mint-una_bios_sata.cloop
Boot = /dev/sda1
Root = /dev/sda1
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
Append = ro splash
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = no
AutostartTimeout = 5
DefaultAction = start
RestoreOpsiState = no
ForceOpsiSetup =
Hidden = yes
und hier noch die cfgDatei unter /srv/linbo/boot/grub
# global part of group specific grub.cfg template for linbo net boot
# thomas@linuxmuster.net
# 20210202
#
# if you don't want this file being overwritten by import_workstations remove the following line:
# ### managed by linuxmuster.net ###
# edit to your needs
set default=0
set timeout=0
set fallback=1
set gfxmode=auto
set gfxpayload=keep
insmod all_video
insmod png
insmod gfxterm
insmod gfxmenu
insmod minicmd
insmod progress
terminal_output gfxterm
background_color 42,68,87
# 32bit pae, non pae or 64bit kernel
if cpuid -l; then
set linbo_kernel=/linbo64
set linbo_initrd=/linbofs64.lz
elif cpuid -p; then
set linbo_kernel=/linbo
set linbo_initrd=/linbofs.lz
else
set linbo_kernel=/linbo-np
set linbo_initrd=/linbofs-np.lz
fi
# theme settings (modify for custom theme)
set theme=/boot/grub/themes/linbo/theme.txt
export theme
clear
# find linbo cache partition
set cachelabel="cache"
if [ -n "$cachelabel" ]; then
search --label "$cachelabel" --set cacheroot
fi
if [ -z "$cacheroot" ]; then
search --file /start.conf --set cacheroot
fi
if [ -z "$cacheroot" ]; then
search --file "$linbo_initrd" --set cacheroot
fi
if [ -n "$cacheroot" ]; then
set root="$cacheroot"
else
set root="(hd0,2)"
fi
# linbo part, boot local or net (default #0)
menuentry 'LINBO' --class linbo {
echo LINBO $bootflag for group mgb_mint-una_bios_sata
echo
if [ -e "$linbo_kernel" -a -e "$linbo_initrd" ]; then
set bootflag=localboot
elif [ -n "$pxe_default_server" ]; then
set root="(tftp)"
set bootflag=netboot
fi
if [ -n "$bootflag" ]; then
echo -n "Loading $linbo_kernel ..."
linux $linbo_kernel dhcpretry=30 server=10.1.0.1 $bootflag
echo
echo -n "Loading $linbo_initrd ..."
initrd $linbo_initrd
boot
else
if [ "$grub_platform" = "pc" ]; then
set ipxe="/ipxe.lkrn"
fi
if [ -e "$ipxe" ]; then
echo -n "Initiating pxe boot ..."
linux16 $ipxe dhcp
boot
fi
fi
}
# group specific grub.cfg template for linbo net boot, should work with linux and windows operating systems
# thomas@linuxmuster.net
# 20201126
#
# start "Linux Mint Una XFCE" directly
menuentry 'Linux Mint Una XFCE (Start)' --class linuxmint_start {
set oslabel="ubuntu"
if [ -n "$oslabel" ]; then
search --label "$oslabel" --set osroot
fi
if [ -n "$osroot" ]; then
set root="$osroot"
else
set root="(hd0,1)"
fi
set win_efiloader="/EFI/Microsoft/Boot/bootmgfw.efi"
terminal_output console
if [ -e /boot/vmlinuz -a -e /boot/initrd.img ]; then
linux /boot/vmlinuz ro splash root=/dev/sda1
initrd /boot/initrd.img
elif [ -e /vmlinuz -a -e /initrd.img ]; then
linux /vmlinuz ro splash root=/dev/sda1
initrd /initrd.img
elif [ -e /boot/vmlinuz -a -e /boot/initrd ]; then
linux /boot/vmlinuz ro splash root=/dev/sda1
initrd /boot/initrd
elif [ -e /vmlinuz -a -e /initrd ]; then
linux /vmlinuz ro splash root=/dev/sda1
initrd /initrd
elif [ -e /boot/vmlinuz -a -e /boot/initrd.img ]; then
linux /boot/vmlinuz ro splash root=/dev/sda1
initrd /boot/initrd.img
elif [ -e /boot/vmlinuz ]; then
linux /boot/vmlinuz ro splash root=/dev/sda1
elif [ -s /boot/grub/grub.cfg ] ; then
configfile /boot/grub/grub.cfg
elif [ "$grub_platform" = "pc" ]; then
if [ -s /bootmgr ] ; then
ntldr /bootmgr
elif [ -s /ntldr ] ; then
ntldr /ntldr
elif [ -s /grldr ] ; then
ntldr /grldr
else
chainloader +1
fi
elif [ -e "$win_efiloader" ]; then
chainloader $win_efiloader
boot
fi
terminal_output gfxterm
}
# boot LINBO and start "Linux Mint Una XFCE"
menuentry 'Linux Mint Una XFCE (Linbo-Start)' --class linuxmint_start {
if [ -e "$linbo_kernel" -a -e "$linbo_initrd" ]; then
set bootflag=localboot
elif [ -n "$pxe_default_server" ]; then
set root="(tftp)"
set bootflag=netboot
fi
if [ -n "$bootflag" ]; then
echo LINBO $bootflag for group mgb_mint-una_bios_sata
echo
echo -n "Loading $linbo_kernel ..."
linux $linbo_kernel dhcpretry=30 server=10.1.0.1 linbocmd=start:1 $bootflag
echo
echo -n "Loading $linbo_initrd ..."
initrd $linbo_initrd
boot
fi
}
# boot LINBO, sync and start "Linux Mint Una XFCE"
menuentry 'Linux Mint Una XFCE (Sync+Start)' --class linuxmint_syncstart {
if [ -e "$linbo_kernel" -a -e "$linbo_initrd" ]; then
set bootflag=localboot
elif [ -n "$pxe_default_server" ]; then
set root="(tftp)"
set bootflag=netboot
fi
if [ -n "$bootflag" ]; then
echo LINBO $bootflag for group mgb_mint-una_bios_sata
echo
echo -n "Loading $linbo_kernel ..."
linux $linbo_kernel dhcpretry=30 server=10.1.0.1 linbocmd=sync:1,start:1 $bootflag
echo
echo -n "Loading $linbo_initrd ..."
initrd $linbo_initrd
boot
fi
}
# boot LINBO, format os partition, sync and start "Linux Mint Una XFCE"
menuentry 'Linux Mint Una XFCE (Neu+Start)' --class linuxmint_newstart {
if [ -e "$linbo_kernel" -a -e "$linbo_initrd" ]; then
set bootflag=localboot
elif [ -n "$pxe_default_server" ]; then
set root="(tftp)"
set bootflag=netboot
fi
if [ -n "$bootflag" ]; then
echo LINBO $bootflag for group mgb_mint-una_bios_sata
echo
echo -n "Loading $linbo_kernel ..."
linux $linbo_kernel dhcpretry=30 server=10.1.0.1 linbocmd=format:1,sync:1,start:1 $bootflag
echo
echo -n "Loading $linbo_initrd ..."
initrd $linbo_initrd
boot
fi
}
Fakten zu Kernelparametern:
Alle mir einfallenden Parameter getestet von dhcpretry bis nolapic, In der LMN6 liefen die T430 unter LINBO 2.2.16-0
Fakten zur Umgebung:
root@server:~# dpkg -l | grep linuxmuster
ii linuxmuster-base7 9.1.2-0 all linuxmuster.net configuration scripts
ii linuxmuster-linbo-common7 9.4.8-0 all linuxmuster-linbo common files: kernel, initrd and pxe boot configuration
ii linuxmuster-linbo-gui7 9.0.2 all Linuxmuster Linbo GUI
ii linuxmuster-linbo7 9.4.8-0 all linuxmuster-linbo scripts
ii linuxmuster-prepare 0.7.4-0ubuntu0 all linuxmuster.net pre setup configuration scripts
ii linuxmuster-webui7 1.0.169rc6 all next generation web-based management tool for linuxmuster.net v7.x
Mit bestem Dank für die Hilfe.
Da wir in Kürze die LMN7 produktiv einsetzen wollen und ich auf die T430 nicht verzichten kann, eilt es mittlerweile.
Ganz zu Anfang getestet - an 2 versch. Switchen, einer davon der Switch, der auch direkt an der Internetleitung zum ausgelagerten Server hängt.
Das ist der lokale Cache-Server für Images. Rausgelassen habe ich es aber trotzdem auch schon.
Lösungsansatz BIOS-Downgrade:
Ja - habe ich auch gesehen, aber am Bios habe ich ja nix gemacht, in der LMN6.1 laufen die NICs ja und PXE klappt ja wohl auch, nur eben die GUI nicht. Werde es trotzdem mal testen…
Lösungsansatz andere Netzwerkkarte
Wäre es evtl. hilfreich mal eine USB-Netzwerkkarte ins T430 zu stecken und damit mal LINBO zu testen - nur um zu sehen, ob es wirklich an der Netzwerkkarte liegt?
Wenn ja, hat jemand einen Tipp, welche USB-Netzwerkkarte mit LINBO in der LMN7.1 funktioniert.
Weiterer Ansatz Offload-Probleme und Sophos ?
Es gibt auch noch Berichte über Probleme mit „Offload“ der Netzwerkkarte 82579LM, die ich allerdings nicht verstehe:
Letzter Satz ist wichtig: „You’ve encountered a hardware bug, please
work with TSO disabled.“
… und das geht möglicherweise nicht per kernelparameter: da mußt du mal
eine intensive ecosiasuche nach machen.
Du kannst aber trotzdem mal
pcie_aspm=off
versuchen … vielleicht klappt das ja inzwischen (der Post ist von 2014).
Dass es mit dem alten linbo ging und mit dem neuen nicht liegt wohl am
neueren e1000 Treiber der die Hardware besser ausnutzt und deswegen den
HardwareBUG findet
Was du versuchen kannst: Windows auf der Kiste installieren und neusten
intel Treiber von deren Webseite installieren (auch ein Win10 update
könnte unter „Treiber“ einen Treiber mitbringen, der die Firmware der
Karte erneuert).
Ich kann dir nciht sagen, dass das geht, aber ich hatte schon ähnliche
Fehler bei Netzwerkkarten.
Damals hatte ein installiertes Windows den Stromsparmodus der NW Karte
aktiviert: schon lief linux nicht mehr drauf …
Damals mußte ich Windows aufspielen und in den Treibersettings den
Stromsparmodus ausschalten, dann ging es wieder unter linux … ist aber
lange her.
Alle Tests sollten mit dem aktuellsten linbo 4 stattfinden.
Eine suche nach „linbokernel (mit uname -a am Client ermitteln)
NETZWERKKARTENNAME“ könnte auch was hervorbringen
Danke für die tolle Hintergrundrecherche!
Und Danke auch für die Schilderung Deiner Erfahrungen - das hilft mir sehr ein Bild der Situation zu bekommen.
Klappt leider nicht. Habe nach Recherchen zu pcie_aspm=off auch gleich mal alle in dem Zusammenhang genannten Parameter ausprobiert:
pcie_aspm=off
acpi=off
noapic
und aus Verzweiflung auch noch - obwohl es sich auf die Grafikkarte bezieht
nomodeset
Das Bios ist von 2012. Da versuche ich doch mal ein Bios-Upgrade. Bei Lenovo gibt’s ein Upgrade von 2019. In der „README for BIOS Update Utility“ gibt’s zumindest mal einen Hinweis auf Probleme beim PXE-Boot mit dem Intel Boot Agent.
<2.63>
UEFI: 2.63 / ECP: 1.12
- (Fix) Fixed an issue where the system might fail to remote boot.
Note: From Intel Boot Agent 1.5.50, it doesn't support PXE option 61.
Und auf der Intel-Seite dazu sind viele Netzwerkkarten gelistet - meine 82579LM ist auch dabei.
rc linuxmuster-linbo-common7 2.4.3-4
all linuxmuster-linbo common files: kernel,
initrd and pxe boot configuration
ii linuxmuster-linbo-gui7 7.0.5
all Linuxmuster Linbo GUI
ii linuxmuster-linbo7 4.0.27-0
all linuxmuster-linbo7
was hast du den da?
eine lmn7 oder eine lmn7.1 ?
Meine Ausgabe von:
dpkg -l | grep linuxmuster
ii linuxmuster-base7 7.1.10-0
all linuxmuster.net configuration scripts
rc linuxmuster-linbo-common7 2.4.3-4
all linuxmuster-linbo common files: kernel,
initrd and pxe boot configuration
ii linuxmuster-linbo-gui7 7.0.5
all Linuxmuster Linbo GUI
ii linuxmuster-linbo7 4.0.27-0
all linuxmuster-linbo7
ii linuxmuster-prepare 7.1.5-1
all linuxmuster.net pre setup configuration
scripts
ii linuxmuster-webui7 7.1.24
all Next generation web-based management
tool for linuxmuster.net v7.x
ich habe LMN7.1 von und bei netzint - noch nicht produktiv im Einsatz. An dieser Stelle ein großes DANKESCHÖN für die kompetente und freundliche Betreuung an netzint!!!
Ich habe gerade gelesen, dass es die LMN7.1 nur mit LINBO 4 gibt - daher wird es wohl der netzint-fork sein.
Die Angaben beim Serverlogin sind übrigens die selben wie oben angegebenen (mit
dpkg -l | grep linuxmuster)
LINBO verwendet bei mir übrigens Kernel 5.4.75 (laut linbo-ssh auf einen Client und dann uname -a).
Und damit komme ich zu zurück zum T430-Linbo-Problem.
Ich habe nun alles durch, was ich machen kann - leider ohne Erfolg. Hier mein Bericht mit einigen „Impressionen“ und der Bitte um Manöverkritik…
Und das Treibermodul ist e1000e in Version 3.2.6-k in Firmwareversion 0.13-3 (ethtool)
Bei einem anderen Client HP8300-Elite, der problemlos mit LINBO läuft, ist auch die Netzwerkkarte Intel 82579LM verbaut, einziger Unterschied, der mir aufgefallen ist, ist die Treiberfirmware, ausgelesen per linbo-ssh auf den Client.
Das Treibermodul ist e1000e in Version 3.2.6-k in Firmwareversion 0.13-4 (ethtool)
Gibt es vielleicht doch noch eine andere Firmware für die Netzwerkkarte, die ich nicht finde?
Und zum Schluss - Hoffnung auf Kernelupdate mit aktuellem Treiber e1000e:
Man findet jede Menge Berichte über Netzwerkprobleme mit Intel 82579LM oder dem Treibermodul e1000e und Linux-Kernel. Einige weißen darauf hin, dass neuere Kernel die Probleme beheben konnten. Einige Berichte beziehen sich auch auf die e1000e-Treiberversion 3,8,4 statt 3.2.6., sowohl hier in der Liste
als auch außerhalb:
Ein großes DANKESCHÖN an Thomas, das LINBO-Kernel-Upate macht mir Hoffnung!
Ich spreche netzint mal darauf an, ob das auch in den netzint-linbo-fork eingeht…
ich habe LMN7.1 von und bei netzint - noch nicht produktiv im Einsatz.
… das erklärt die extrem seltsamen Versionsangaben.
Tut mir Leid: ich hab überhaupt keine Ahnung, welches linbo du da hast.
Mein „best shot“ anhand der Versionsnummer 9.4.8 wäre, dass das ein
linbo 4.0.8 ist … aber das wäre sehr alt: da ist extrem viel passiert
seit dieser Version (wir sind bei 4.0.28)
Ich habe gerade gelesen, dass es die LMN7.1 nur mit LINBO 4 gibt - daher
wird es wohl der netzint-fork sein.
du meinst du hast noch linbo 2.4?
„Bein LINBO-Startvorgang kommt immer „Version 237““
das bezieht sich nicht auf die linbo Version.
Das ist die Version von irgend was anderem: das hab ich bei mir auch
schon gesehen.
Ich habe eine LMN7.1-prerelease von netzint, die Linbo Version entspricht im Endeffekt der Community Version 2.4.3-4, ist also der letzten Version für Linuxmuster 7.0.
Die Lenovo T430 Laptops waren (fast) die einzigen Clients, bei denen es massive Probleme bei der Erstaufnahme mit LINBO gab. Andere Hardwaregruppen waren - bis auf eine, für die ich kein Zeit mehr gefunden habe - problemlos. Jetzt sind aber alle T430 aufgenommen!
Die Ursachen der Probleme waren wohl vielfältig.
Letztlich ließen sie sich aber beheben OHNE LINBO-Update und OHNE Treiberintegration.
Daher hier meine Tipps für Admins mit ähnlichen Problemen:
Verbindungsprobleme:
Direkt am Switch den Problem-Client anschließen - und gleichzeitig auf anderen Client die Serververfügbarkeit prüfen, z.B. durch pingen oder ssh-Zugriff. Auch mal das Patchkabel und den Port wechseln.
Reste von LMN6-Linbo auf der Platte machen manchmal LMN7-LINBO Probleme, die Platte zu formatieren. Ich konnte mehrere „I/O-Error“-Meldungen lesen, bevor der LINBO-Formatierungsvorgang abbrach. Nach dem kompletten löschen der Festplatte - z.B. durch Schreiben einer neuen leeren Partitionstabelle mit einer GPARTED-live-CD - ging’s dann.
Bios-Einstellungen:
Gerade bei den Schullaptops musste ich feststellen, dass die gerne mal die Bios-Einstellungen verlieren - wahrscheinlich weil sowohl Stützbatterie als auch Akku leer laufen. Dann verstellt sich die Bootreihenfolge und dann wird - so denn vorhanden - das LMN6-LINBO von Platte gestartet - und dann geht’s nicht weiter…