Upgrade von Linuxmuster, dabei kam linbo 2.3.31 fuer 2.3.26
Normale SATA-Rechner haben einwandfrei funktioniert, Einspielen, Sync…, die M.2-SS-Rechner taten ja auch weiter, nur beim komplett neu einspielen konnte kein grub mehr in den MBR geschrieben werden, Fehlermeldung siehe oben. Ich hab die Fehlermeldung dann nochmal auf der Console direkt am Rechner generiert, mit dem Schreibfehler, das Problem war aber nicht die falsche Partition sondern die fehlenden locales bzw. Teile der Umgebung scheinen zu fehlen.
Downgrade auf linbo 2.3.26 und grub laesst sich wieder installieren, gleiche start.conf
Beim Testrechner hat es da wohl soviel zerschossen, dass ich per USB-Boot den ganzen MBR ueberschreiben musste, er hat nicht mehr vom Netz gebootet und ich hab keine Ahnung wieso, es kam immer das kaputte Linbo ohne Maus und Tastatur.
Wo schreibt er das eigentlich hin? In die Cachepartition? Im MBR duerfte zu wenig Platz sein, da sind ja nur die Partitionseintraege und Verweise drin und ein Hauch von Bootcode.
Upgrade von Linuxmuster, dabei kam linbo 2.3.31 fuer 2.3.26
Normale SATA-Rechner haben einwandfrei funktioniert, Einspielen,
Sync…, die M.2-SS-Rechner taten ja auch weiter, nur beim komplett
neu einspielen konnte kein grub mehr in den MBR geschrieben werden,
Fehlermeldung siehe oben. Ich hab die Fehlermeldung dann nochmal auf
der Console direkt am Rechner generiert, mit dem Schreibfehler, das
Problem war aber nicht die falsche Partition sondern die fehlenden
locales bzw. Teile der Umgebung scheinen zu fehlen.
Downgrade auf linbo 2.3.26 und grub laesst sich wieder installieren,
gleiche start.conf
OK, jetzt verstehe ich es.
Beim Testrechner hat es da wohl soviel zerschossen, dass ich per
USB-Boot den ganzen MBR ueberschreiben musste, er hat nicht mehr vom
Netz gebootet und ich hab keine Ahnung wieso, es kam immer das kaputte
Linbo ohne Maus und Tastatur.
Wo schreibt er das eigentlich hin? In die Cachepartition? Im MBR duerfte
zu wenig Platz sein, da sind ja nur die Partitionseintraege und Verweise
drin und ein Hauch von Bootcode.
ja: linbo residiert in der Cachepartition.
Dass 2.3.31 generell Probleme mit NVME SSDs hätte kann ich nicht
bestätigen: ich habe hier einen Rechner mit NVMe den ich mit 2.3.31
bespielt habe: Win10 und Ubuntu 14.04: alles ohne Probleme (aus linbo
Sicht).
Vielleicht ist was beim Update auf 2.3.31 schief gegangen? (logdateien)
Oder es wurde der import nach dem Update vergessen…
Hallo,
ich habe versucht, das bei mir nochmal nachzuvollziehen. Derzeit also im BIOS legacy first eingetragen, in der start.conf korrekte Partitionen angegeben.
Client bootet, dann mit Linbo der Platte partitioniert und formatiert, danach den cache mit dem cloop befüllt.
Der Cache wir korrekt mit dem Cloop befüllt. Aber es bleibt die Fehlermeldung, dass
Auszüge aus der Log-Datei:
hub 3-0:1.0: 1 port detected
nvme0n1: p1 p2 p3
ata1: SATA link down (SStatus 0 SControl 300)
Installing for i386-pc platform.
grub-install: warning: cannot open directory `/usr/share/locale’: No such file or directory.
Installation finished. No error reported.
Moeglicher Fehler erkannt: linbo_cmd laeuft bereits.
1510 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd ready
1526 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd ip
mount: special device /dev/nvmenp does not exist
Bei letzter Fehlermeldung ist schon klar, dass das Gerät anders bezeichnet wird. In der start.conf ist es korrekt angegeben, so wie mir z.B. clonezilla das Gerät auch angibt.
Gehe ich mit linbo-ssh auf den Client so sehe ich die Cache-Partition:
/dev/nvme0n1p3 169625616 4769840 156216240 3% /cache
Wechsel in das Verzeichnis /cache dann finden sich dort das Cloop die start.conf. Im Verzeichnis /cache/boot/grub finden sich ebenfalls die Datei grub.cfg.
Welche Möglichkeiten gibt es, manuell den grub auf dem Client neu zu setzen, um das Problem weiter einzugrenzen?.
VG
Chris
Hast Du mal an diese Möglichkeit gedacht?
linuxmuster-linbo unterstützt Dateisystemlabel vollständig ab Version 2.3.31.
Sind Dateisystemlabel definiert, werden diese beim Formatieren einer Partition mit Linbo automatisch gesetzt. Danach verwendet Linbo beim Mounten eines Dateisystems den Label unabhängig davon unter welchem Device-Pfad die Partition aktuell zu finden ist. So wird eine Partition immer gefunden, auch wenn sie zum Beispiel wegen eines eingesteckten USB-Sticks einen anderen Device-Pfad hat (z. Bsp. /dev/sdb1 statt /dev/sda1).
Hallo Thorsten,
ja, die Labels habe ich gesetzt. Wenn ich mit linbo-ssh das prüfe, werden diese auch korrekt angezeigt - wie unter github beschrieben.
Es bleibt die Fehlermeldung, dass beim Schreiben des devicemap Grub nicht in den MBR unter /dev/nvme0n1 installiert werden konnte. /dev/disk/by-path No such file or device
VG
Chris
Ich hab mal die Server-VM geklont und beim Klon wieder ein upgrade durchgefuehrt, danach war ich wieder auf linbo 2.3.31, die VM mit 2.3.26 pausiert und die neue die Arbeit uebernehmen lassen, die Probleme waren wieder da.
Mir scheint zumindest bei uns da ein direkter Zusammenhang.
Klon doch einfach mal das Moped und mach ein downgrade auf dem Klon. Ich werf mittlerweile die “qcows” zwischen zwei 19"-Maschinen hin und her.
Hallo!
Ich greife den Thread nochmal auf, da ich am gleichen Problem mit neuen Lenovo-Laptops hänge. Auch bei mir kann der Grub nicht in den MBR geschrieben werden. In der Linbo-Console kann man auch den Grund nachvollziehen: /dev/disk/by-path ist nicht vorhanden ist. Linbo ist die aktuelle 2.3.37
Bei PC mit “normalen” SSD ist /dev/disk/by-path jedoch vorhanden
Gibt’s dafür ne Erklärung / Lösung?
Vielen Dank!
Michael
das liegt imho daran, dass die NVMEs nicht unter /dev/sdX, sondern unter /dev/nv??? weiß grad nicht eingebunden werden.
Entweder, Du musst mit Labels arbeiten oder die start.conf ändern.
Das die Pfade bei MVNE-Platten /dev/nvme0n1pX lauten, habe ich beachtet. Die start.conf habe ich entsprechend angepasst. Dadurch konnte ich den Laptop partitionieren und Windows installieren. Das Problem tritt nur beim schreiben vom Grub in den MBR auf.
Das die Pfade bei MVNE-Platten /dev/nvme0n1pX lauten, habe ich beachtet.
Die start.conf habe ich entsprechend angepasst. Dadurch konnte ich den
Laptop partitionieren und Windows installieren. Das Problem tritt nur
beim schreiben vom Grub in den MBR auf.
das sind Clients mit einer NVMe SSD, die aber per BIOS gestartet werden,
nicht per UEFI?
hab sie unten noch mal hinkopiert, damit sie alle direkt sehen können.
Ist das ein Kpierfehler, dass unter dem Betriebsystem die nvme0n1p3 noch
ein zweites mal definiert wirde?
LG
Holger
[LINBO] # globale Konfiguration
Cache = /dev/nvme0n1p4 # lokale Cache Partition
Server = 10.16.1.1 # IP des Linbo-Servers, der das Linbo-Repository vorhaelt
Group = lenovo_v330 # Name der Rechnergruppe fuer die diese Konfigurationsdatei gilt
# Achtung: Server und Group werden beim Workstationsimport automatisch gesetzt!
SystemType = efi64 # moeglich ist bios>bios64|efi32|efi64 (Standard: bios fuer bios 32bit)
RootTimeout = 600 # automatischer Rootlogout nach 600 Sek.
AutoPartition = no # automatische Partitionsreparatur beim LINBO-Start
AutoFormat = no # kein automatisches Formatieren aller Partitionen beim LINBO-Start
AutoInitCache = no # kein automatisches Befuellen des Caches beim LINBO-Start
DownloadType = rsync # Image-Download per torrent|multicast|rsync,default ist rsync
BackgroundFontColor = white # Bildschirmschriftfarbe (default:white)
ConsoleFontColorStdout = white # Konsolenschriftfarbe (default: white)
ConsoleFontColorStderr = red # Konsolenschriftfarbe fuer Fehler-/Warnmeldungen (default: red)
KernelOptions = quiet splash # Beispiele:
#KernelOptions = acpi=noirq irqpoll # LINBO Kerneloptionen (z. B. acpi=off), m. Leerz. getrennt
#KernelOptions = server=10.16.1.5 # Abweichende Linbo-Server-IP alsKerneloption gesetzt
# falls gesetzt wird diese IP beim Workstationsimport verwendet
[Partition]
Dev = /dev/nvme0n1p1
Size = 200M
Id = ef
FSType = vfat
Bootable = yes
Label = efi
[Partition]
Dev = /dev/nvme0n1p2
Size = 128M
Id = c01
FSType =
Bootable = no
Label = msr
[Partition]
Dev = /dev/nvme0n1p3
Size = 118G
Id = 7
FSType = ntfs
Bootable = no
Label = windows
[Partition]
Dev = /dev/nvme0n1p4
Size = 110G
Id = 83
FSType = ext4
Bootable = no
Label = cache
[Partition]
Dev = /dev/nvme0n1p5
Size =
Id = 7
FSType = ntfs
Bootable = no
Label = daten
[OS] # Beginn einer Betriebssystemdefinition
Name = Windows 10 # Name des Betriebssystems
Version = # Version (unbenutzt, leer lassen)
Description = Windows 10 # Beschreibung
IconName = win10.png # Icon fuer den Startbutton, muss unter /var/linbo/icons abgelegt sein
Image = # differentielles Image (Erweiterung .rsync, Verwendung nicht empfohlen)
BaseImage = win10-lenovo.cloop # Dateiname des Basisimages (Erweiterung .cloop)
Boot = /dev/nvme0n1p3 # Bootpartition (unbenutzt, immer gleich Rootpartition)
Root = /dev/nvme0n1p3 # Rootpartition, in die das BS installiert ist
Kernel = grub.exe # Windows: auto (LINBO & Grub erkennen die Startparameter automatisch)
Initrd = # Windows: leer
Append = # Windows: leer
StartEnabled = yes # "Start"-Button anzeigen
SyncEnabled = yes # "Sync+Start"-Button anzeigen
NewEnabled = yes # "Neu+Start"-Button anzeigen
Hidden = yes # verstecke OS-Reiter (unbenutzte Option, auf "yes" lassen)
Autostart = no # automatischer Start des Betriebssystems (yes|no)
AutostartTimeout = # Timeout in Sekunden fuer Benutzerabbruch bei Autostart
DefaultAction = start # Standardaktion bei Autostart: start|sync|new
[Partition]
Dev = /dev/nvme0n1p3
Size = 118G
Id = 7
FSType = ntfs
Bootable = no
Hallo Holger!
Hab’s geändert. Macht aber keinen Unterschied. Außerdem hab ich andere start.conf, in denen die 0 auch fehlt und da funktioniert alles.
Ich häng mal noch einen Sceenshot an, damit man sieht, wo der Fehler auftritt.
Hab’s geändert. Macht aber keinen Unterschied. Außerdem hab ich andere
start.conf, in denen die 0 auch fehlt und da funktioniert alles.
Ich häng mal noch einen Sceenshot an, damit man sieht, wo der Fehler
auftritt.
