Nach Netzwerkboot kein Boot von der Festplatte mehr

Hallo zusammen,
da die neuen Rechner nur noch UEFI können habe ich mir über den Sommer ein neues Image gemacht und auch die v7 auf dem Server installiert. Wenn ich einen Rechner ans Netzwerk hänge und die neuen Images kopiere erscheint im Anschluss beim Booten die unten gezeigte Fehlermeldung. Wenn ich nochmal LINBO übers Netzwerk starte und dann auf den „Play-Button“ klicke bootet Ubuntu korrekt. Führe ich im Terminal ein sudo grub-install /dev/nvme0n1 durch, bootet der Laptop er auch von der Festplatte weider korrekt.
Ihr habt bestimmt den entscheidenden Tipp :slight_smile:
Habe hier schon viel gestöbert und einige Hinweise gefunden und auch probiert. Aber ohne erfolg.

Liebe Grüße
Leo

Die Fehlermeldung:

LINBO netboot

Loading /linbo64 ...error: no server is specified.

Loading /linbofs64.lz ...error: you neet do load the kernel first
error: you need to load the kernel first.

Press any key to continue...

Meine /srv/linbo/start.conf.vcn sieht wie folgt aus:

Server = 10.0.0.1
Group = vcn
Cache = /dev/nvme0n1p3
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
GuiDisabled = no
UseMinimalLayout = no
Locale = de-de
BackgroundColor = 394f5e
#backgroundFontColor = white
DownloadType = rsync
BackgroundFontColor = white
ConsoleFontColorStdout = lightgreen
ConsoleFontColorStderr = orange
SystemType = efi64
SystemType = bios64
KernelOptions = splash quiet
        # pci=noats nomodeset dhcpretry=30
#acpi=noirq
#i8042.nopnp=1 pci=nocrs
ClientDetailsVisibleByDefault = yes

[Partition]
Dev = /dev/nvme0n1p1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p2
Label = ubuntu
Size = 40G
Id = 83
FSType = ext4
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p3
Label = cache
Size = 12G
Id = 83
FSType = ext4
Bootable = no

[Partition]
Label = data
Dev = /dev/nvme0n1p4
Size =
Id = 83
FSType = ext4
Bootable = no

[OS]
Name = Ubuntu
Version =
Description = Ubuntu 22.04
IconName = ubuntu.png
Image =
BaseImage = ubuntu-2204.qcow2
Boot = /dev/nvme0n1p2
Root = /dev/nvme0n1p2
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
Append = ro splash
StartEnabled = yes
SyncEnabled = no
NewEnabled = yes
Autostart = no
AutostartTimeout = 10
DefaultAction = new
RestoreOpsiState = no
ForceOpsiSetup =
Hidden = yes


[OS]
Name = Ubuntu-Home Partition
Version =
Description = Home-Partition
IconName = ubuntu.png
Image =
BaseImage = ubuntu-2204-home.qcow2
Boot = /dev/nvme0n1p4
Root = /dev/nvme0n1p4
Kernel =
Initrd =
Append =
StartEnabled = no
SyncEnabled = yes
NewEnabled = yes
Hidden = yes
Autostart = no
AutostartTimeout = 10
DefaultAction = new

und meine /srv/linbo/boot/grub/vcn.cfg so:

  GNU nano 2.9.3                                                                                  boot/grub/vcn.cfg                                                                                             

#
# grub.cfg for forced netboot
# thomas@linuxmuster.net
# 20201127
#

# 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 gfxpayload=800x600x16

# 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
#set font=/boot/grub/themes/linbo/unifont-regular-16.pf2

# load theme
#if [ -e "$theme" -a -e "$font" ]; then
# loadfont "$font"
 export theme
#fi

clear

# linbo netboot
menuentry 'LINBO' --class linbo {

 echo LINBO netboot
 echo

 set root="(tftp)"
 # perhaps faster
 #set root="(http)"

 echo -n "Loading $linbo_kernel ..."
 linux $linbo_kernel quiet splash netboot
 echo
 echo -n "Loading $linbo_initrd ..."
 initrd $linbo_initrd
 boot

}

Ein linuxmuster-import-devices habe ich nochmals zur Sicherheit durchgeführt.

Hallo Leo,

ich weiß nicht, ob ich das identische Problem habe, aber die Symptome klingen ähnlich:
Linuxmuster7.1 auf dem aktuellen Stand, Linbo 4.0.33-0

Linbo lässt sich per PXE ganz normal starten und alle Funktionen gehen tadellos.
Wenn Linbo lokal per Grub gestartet werden soll, kommt folgende Meldung:

LINBO for group Win10EFI-F-E01

Initiating pxe boot ...error: invalid file name 'dhcp'. linux16.mod 8.70KiB 100% 15.43KiB/s ]
error: you need to load the kernel first.

Press any key to continue.

Nach ein paar Sekunden startet dann statt Linbo das installierte Betriebssystem (hier Windows10).

Das Problem tritt nach dem Verteilen der Images auf. Vorher wurden die SSDs neu partitioniert/formatiert.

Habe noch keine Lösung gefunden.

Hier gabe es schonmal ein solches Problem:

Viele Grüße,
Tom

Hallo Tom,

LINBO for group Win10EFI-F-E01 Initiating pxe boot …error: invalid

… nur zum testen: steck mal einen Client in eine Gruppe deren Namen
keine Sonderzeichen enthält wie z.B. win10efife01
Dann importieren, dann start.conf von der alten Gruppe kopieren und dann
nochmal importieren.
Danach Cleint booten und Partitionieren, neustarten und Image zurückspielen.
Bleibt das Problem?

LG

Holger

Hallo Holger,

danke für Deine Nachricht. Ich hatte auch schon gedacht, dass es ein Sonderzeichen-Problem sein könnte.

Ich habe einen PC in die Gruppe Win10EFI gesteckt, importiert, dann am Server die start.conf der alten Gruppe kopiert und im Inhalt den Gruppennamen auch auf Win10EFI geändert. Anschließend nochmal importiert, den Client per PXE neu gestartet und partitioniert. Beim anschließenden Neustart hat der PC beim ersten mal den GRUB starten können und den Cache aktualisiert. Dann habe ich nochmal neu gestartet und der GRUB konnte an dieser Stelle schon wieder nicht neu starten.
Fehler wie vorher: „Initating pxe boot… error: invalid file name ‚dhcp‘“.
Da hier noch kein Windows „entpackt war“ bin ich jetzt aber anschließend ins Grub-Bootmenü gefallen und konnte mir dort die Einstellungen ansehen:

 echo LINBO $bootflag for group Win10EFI
 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 noefibootmgr $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

Aus irgendeinem Grund springt der Grub in den letzten Ast und versucht wohl (obwohl er lokal booten sollte) einen PXE-Boot zu starten über das Kommando „linux 16 $ipxe dhcp“
Das endet mit einem "error: invald file name ‚dhcp‘

Noch eine Beobachtung:
Wenn ich per PXE den Linbo starte und dann ein Linbo-Update am Client manuell durchführe per linbo-ssh:
rm /tmp/.update.done
linbo_wrapper update

Dann startet Linbo über Grub beim nächsten mal ordentlich. Beim übernächsten mal wieder nicht (invalid file name dhcp…)
Also müsste ich nach jedem Linbostart über Grub ein linbo_wrapper update erzwingen, damit alles läuft.

Ich bin ein bisschen ratlos.

Hier nochmal meine start.conf

[LINBO]
Server = 10.0.0.1
Group = Win10EFI
Cache = /dev/nvme0n1p4
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = yes
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = efi64
KernelOptions = noefibootmgr

[Partition]
Dev = /dev/nvme0n1p1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p2
Label = msr
Size = 128M
Id = 0c01
FSType =
Bootable = no

[Partition]
Dev = /dev/nvme0n1p3
Label = windows
Size = 150G
Id = 7
FSType = ntfs
Bootable = no

[Partition]
Dev = /dev/nvme0n1p4
Label = cache
Size = 150G
Id = 83
FSType = ext4
Bootable = no

[OS]
Name = Windows 10
Version = 21H2
Description = Windows 10 1903
IconName = win10.svg
Image =
BaseImage = win10.qcow2
Boot = /dev/nvme0n1p3
Root = /dev/nvme0n1p3
Kernel = auto
Initrd =
Append =
StartEnabled = yes
SyncEnabled = no
NewEnabled = yes
Autostart = no
AutostartTimeout = 5
DefaultAction = start
Hidden = yes

LG
Tom

Wenn der Grub-Fehler auftritt, fehlt auf der Cache-Partition der Linbo-Kernel und das Linbofs-File:
-rw-r–r-- 1 root root 4177248 Aug 18 18:40 linbo64
-rw-r–r-- 1 root root 33 Aug 18 18:40 linbo64.md5
-rw-rw-rw- 1 root root 24456351 Aug 26 11:53 linbofs64.lz
-rw-r–r-- 1 root root 33 Aug 26 11:53 linbofs64.lz.md5

Wenn ich, wie oben beschrieben, ein linbo_wrapper update erzwinge (dafür muss ich vorher das /tmo/.update.done löschen), dann sind kernel und fs wieder im Cache-Ordner. Nach einem Reboot und erfolgreichen Linbo-Boot über Grub fehlen die beiden Files wieder.

Das Linbo.log schaut nach einem erfolgreichen Grub-Start (bei dem anschließend Kernel und FS fehlen) wie folgt aus:

Installing for x86_64-efi platform.
grub-install: warning: cannot open directory `/usr/share/locale': No such file or directory.
Installation finished. No error reported.
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0001
Boot0000* grub
Boot0001* UEFI: PXE IPv4 Realtek PCIe GBE Family Controller
Boot0002* UEFI OS
[Info] Starting to parse start.conf
[Info] Finished parsing start.conf
[Info] Loading environment values
[Info] Executing synchronos: linbo_cmd ip
[Info] Executing synchronos: linbo_cmd netmask
[Info] Executing synchronos: linbo_cmd bitmask
[Info] Executing synchronos: linbo_cmd mac
[Info] Executing synchronos: linbo_cmd version
[Info] Executing synchronos: linbo_cmd hostname
[Info] Executing synchronos: linbo_cmd cpu
[Info] Executing synchronos: linbo_cmd memory
[Info] Executing synchronos: linbo_cmd size /dev/nvme0n1p4
mount: mounting /dev/nvme0n1p4 on /mnt failed: Device or resource busy
[Info] Executing synchronos: linbo_cmd size /dev/nvmenp
[Info] Executing synchronos: linbo_cmd listimages /dev/nvme0n1p4
[Info] Finished loading environment values
[Error] Could not read theme config: /icons/
[+++ Chapter +++] Updating cache
[Info] Linbo state changed to: 13
[Info] Executing asynchronos: linbo_cmd
[StdOut] initcache 1: ?10.0.0.1? 2: ?/dev/nvme0n1p4? 3: ?torrent? 4: ?win10.qcow2? 5: ??
[StdOut] receiving incremental file list
[StdOut] win10.qcow2.info
[StdOut] 0 0% 0.00kB/s 0:00:00 148 100% 144.53kB/s 0:00:00 (xfr#1, to-chk=0/1)
[StdOut] RSYNC Download 10.0.0.1 -> images/win10/win10.qcow2.desc...
[StdOut] receiving incremental file list
[StdOut] receiving incremental file list
[StdOut] receiving incremental file list
[StdOut] receiving incremental file list
[StdOut] receiving incremental file list
[StdOut] win10.reg
[StdOut] 0 0% 0.00kB/s 0:00:00 505 100% 493.16kB/s 0:00:00 (xfr#1, to-chk=0/1)
[StdOut] receiving incremental file list
[StdOut] win10.qcow2 has not changed, nothing to do.
[StdOut] Starting torrent service for win10.qcow2.
[StdOut] update 1: ?10.0.0.1?
[StdOut] 2: ?/dev/nvme0n1p4?
[StdOut] LINBO-Update wurde schon ausgefuehrt!
[StdOut] linbo_gui is up-to-date.
[Info] Process exited normally.
[Info] Linbo state changed to: 0
[Info] Linbo state changed to: 3
[+++ Chapter end +++] Process exited.

Ist die Ausgabe „[Info] Executing synchronos: linbo_cmd size /dev/nvme0n1p4
mount: mounting /dev/nvme0n1p4 on /mnt failed: Device or resource busy“ normal?

[Info] Executing synchronos: linbo_cmd size /dev/nvme0n1p4
mount: mounting /dev/nvme0n1p4 on /mnt failed: Device or resource busy
[Info] Executing synchronos: linbo_cmd size /dev/nvmenp

Wenn ich den gleichen Client ohne LAN starte, wird der Grub/Linbo beim Neustart nicht zerstört und Kernel+FS bleiben erhalten. Außerdem kommt die Meldung „mount: mounting /dev/nvme0n1p4 on /mnt failed: Device or resource busy“ zwischen

[Info] Executing synchronos: linbo_cmd size /dev/nvme0n1p4
[Info] Executing synchronos: linbo_cmd size /dev/nvmenp

LG
Tom

Lösung gefunden:
Ich hatte für die Hardware-Gruppe zum schnelleren Verteilen der Images die Option „Beim Start Cache aktualisieren“ aktiviert. Wenn diese aktiv ist, werden anscheinend der Linbo-Kernel und Linbo-FS beim Grub-Booten gelöscht.
Ich habe die Option jetzt ausgeschaltet und die PCs booten zuverlässig im Grub.

1 „Gefällt mir“

Super :slight_smile:

Für mich reicht die Lösung erstmal so.
Aber da das vermutlich ein Bug ist: An wen von den Entwicklern kann ich dazu einen Hinweis geben?
Ich bin selbst zu wenig mit dem (sehr übersichtlich und gut gepflegten) Source-Code vertraut um die Zusammenhänge zwischen „Beim Start Cache aktualisieren“ und dem Verschwinden der Kernel-Dateien aus dem Cache zu finden.

Hallo Tom,

ich mache ein Issue in GitHub.

LG

Holger

Hallo Tom,

ich habe das immer so verstanden, dass

nicht als Standard-Vorgabe zu verstehen ist. Es zwingt den Client, seine Initialisierung zu überschreiben.

Es macht auch wenig Sinn, bei jeden Start den Cache neu zuschreiben, da er sich im Regelfall gar nicht oder nur bei Aktualisierungen des Images ändert. Die letztgenannte Änderung erfährt der Client aber auch bei jedem synchronisierten Start.

Sollte ich da einem Missverständnis aufliegen, so möge mensch mich korrigieren.

Eventuell sollten wir das in der Dokumentation klarer rausstellen.

Beste Grüße

Thorstenb

Hallo Thorsten,

dann habe ich vielleicht diese Option falsch verstanden.
Ich wollte, dass alle Clients, die im Linbo stehen, per Torrent bereit stehen um neue Clients zu betanken, was auch super funktioniert. Fertige Clients seeden, neue Clients holen sich das Image sofort mit maximaler Geschwindigkeit.

Wenn der Raum fertig ist, schalte ich die Option ab und setzte dafür Autostart für Windows.
Mir war nicht klar, dass durch diese Option die Boot-Files (Linbo-Kernel, Linbo-FS) gelöscht werden, welche grub zum Starten des Linbo benötigt.

Hallo Tom,

das erreichst du auch mit sync:X

Da müssen wir die Doku wohl noch weiter ausbauen. Woher nimmt mensch nur die Zeit?

Beste Grüße

Thorsten

Hallo Thorsten,

in jedem Fall möchte ich mich für die sehr gute Doku beim Team bedanken.

Viele Grüße,
Tom

Hallo @TomS!

Danke für die Info. Ist nun gefixt: Neue Pakete für lmn 7.1 - #236 von thomas

VG, Thomas

2 „Gefällt mir“

Hallo Thomas,

… das war ein Lightningfix… tausend Dank :slight_smile:
LG

Holger

Ersma testen bitte. :smirk:

Hallo Tom,

Hast du nicht missverstanden. Da lag ich daneben, wie ein Austausch mit Thomas ergab.
Eigentlich ist nach seiner Entwicklung initcache für den Reparaturfall gedacht. Aber lässt sich auch einsetzen, um damit Clients als Seeder zu starten. Wieder etwas dazugelernt.

Beste Grüße

Thorsten

6 Beiträge wurden in ein neues Thema verschoben: Lmn 7.2 - Kein Netzwerkboot nach Migration

Ein Beitrag wurde in ein existierendes Thema verschoben: Lmn 7.2 - Kein Netzwerkboot nach Migration