Linbo-reboot: nach Reboot fehlerhafte start.conf (SSD nvme0n1) und UEFI-Rebootproblem

Clientpflege linbo
1

Hallo zusammen, hallo Alois,
(@Alois: wir hatten zu meinem Problem gestern schon mal kurz gesprochen)
Ich versuche gerade einen Lenovo-Laptop mit Linbo an den Start zu bringen.
Ich habe zahlreiche Versuche hinter mit UEFI und Bios-64 Modus hinter mir mit jeweils unterschiedlichen Fehlersituationen.
Ziel ist es auf dem Laptop mehrere Betriebssystem parallel liegen zu haben (daher sind es mehr als 4 Partitionen) aktuell vor allem Ubuntu Xenial, LeoClient, später auch möglicherweise Windows10)

Durchgeführt habe ich meine Tests mit verschiedenen linbo-Versionen (aktuell mit Version 2.3.48-0, aber auch schon den verschiedenen Posts folgend mit den Versionen 2.3.40-0, 2.3.26-0, 2.3.28-0)

Vorneweg: Bevor ein import_workstations erfolgreich durchlief:
Es war eine Anpassung des /usr/share/linuxmuster/scripts/wimport.sh erforderlich, da es mit den Einträgen nvme0n1p1, … zu einem parsing-Problem beim import_workstations kam, dass bei identischer start.conf mit entsprechenden sda-Einträgen nicht auftrat - ich hatte das per Auto-Ersetzung („sda“ gegen „nvme0n1p“ ausprobiert, also wirklich sicher mit identischer Datei)
Die Skriptanpassung kam aus einem Foreneintrag heraus
Die Anpassung in der wimport.sh lautete:

grubdisk(){
local partition=„$1“
local partnr=„$(echo „$partition“ | sed -e ‚s|/dev/[hsv]d[abcdefgh]||‘ -e ‚s|/dev/xvd[abcdefgh]||‘ -e ‚s|/dev/mmcblk[0-9]p||‘ -e ‚s|/dev/nvme0n1p[0-9]||‘)“
#local partnr=„$(echo „$partition“ | sed -e ‚s|/dev/[hsv]d[abcdefgh]||‘ -e ‚s|/dev/xvd[abcdefgh]||‘ -e ‚s|/dev/mmcblk[0-9]p||‘)“
case „$partition“ in
/dev/nvme0n1*) local disknr=„$(echo „$partition“ | sed ‚s|/dev/nvme0n([0-9])p[1-9]|\1|‘)“ ;;
/dev/mmcblk*) local disknr=„$(echo „$partition“ | sed ‚s|/dev/mmcblk([0-9])p[1-9]|\1|‘)“ ;;

Problembeschreibung im Legacy-Modus:
Partitionierung, Formatierung, und Sync klappen mittlerweile problemlos (nachdem ich die Label alle auskommentiert habe).

Die Partitionen /dev/nvme0n1p1, /dev/nvme0n1p2, … sind vorhanden und lassen sich mounten.

Sobald ich ein System starten will (z.B. mit linbo_wrapper start:1) kommt es zu seltsamen Effekten:
Der Reboot wird angestossen, danach Fehlermeldungen der Art: error: missing signatur,
das System kommt dann nach mehreren linbo-Durchläufen wieder zum Linbo-Screen:
Wenn man sich dann die start.conf auf dem Lenovo-Client (linbo-ssh) anschaut, stellt man fest, dass die Partitionen völlig sinnfrei durchnummeriert sind: mehrfache dieselbe Partition /dev/nvme0n1p5, als Cache-Partition wird eine falsche Partition gemountet (scheint mir zufällig zu laufen: aktuell gerade Partition 6), als OS-Boot/Root-Device wird auf eine falsche Partition verwiesen.

Anmerkung zur aktuellen start.conf:
Ich habe verschiedenste Partitionierungsreihenfolgen hinter mir, im Moment habe ich eine vorgeschaltete NTFS-Partition drin, die ich im Test gar nicht für ein Betriebssytem nutze, das dient im Moment nur dazu, um den Reboot-Mechanismus zu überprüfen, ich will gezielt auf Partition 2 booten)

Probleme beim Einsatz mit Labels: (siehe auskommentierte Labels der start.conf)
Zuvor hatte ich versucht Labels zu nutzen, das ging schon beim Partitionieren schief: z.B rutschte die mit swap gelabelte Partitionen (eigentlich in der start-conf auf /dev/nvme0n1p3 gesetzt) rutschte auf /dev/nvme0n1p1 , andere Partitionen wurden gar nicht geschrieben (beim Versuch die extendend Partition Id =5 zu schreiben kam es zu Fehlern nach dem Motto kein Platz, die in der erweiterten Partition gelegenen Partitionen wurden erst gar nicht geschrieben)
Erst nachdem ich leere Labels gesetzt hatte wurde korrekt partitioniert, formatiert und auch gesynct.

Beschreibung meiner Probleme im UEFI-Modus:

Partionierung, Formatierung lief problemlos durch,
alle Partitionen liegen korrekt und sind mountbar.
Auch hier funktioniert der Rebootvorgang nicht, Der Laptop bleibt stehen mit einer Meldung der Art, dass das ausgewählte Device nicht bootable ist.

Bei einem Start mit linbo_wrapper start:1 läuft zunächst alles ohne Fehlermeldung erst beim grub-install scheint etwas schief zu gehen:
Auzug aus dem Log-FIle:

grub-install: warning: cannot open directory `/usr/share/locale’: No such file or directory.
Installation finished. No error reported.
mount: /mnt: special device /dev/nvmenp does not exist.
…
Dann werden die BIOS/UEFI --Geräte-Reihenfolge aufgelistet
BootCurrent: 001A
Timeout: 2 seconds
BootOrder: 0018,0019,001A,001B,001C,001E,001F
Boot0010 Setup
Boot0011 Boot Menu
…
Zuletzt dann
invalid numeric value p1

Für mich sah das zunächst nach einem Parsingproblem der linbo_cmd-Skripte aus,
insbesondere fällt auf, dass in der Fehlermeldung „/dev/nvmenp does not exist.“ gerade die Zahlen fehlen.
Bei der Fehlermeldung „invalid numeric value p1“ sieht das nach dem Ende der Device-Angabe "/dev/nvme0n1p1 aus.
Ich habe aber mittlerweile 2 Tage investiert, und bin der Ursache nicht nähergekommen
Möglicherweise ist es auch ein grub-Problem.
Danach habe ich mit dem Thema UEFI aufgegeben und mich dem BIOS-Boot zugewandt, mit den nun anders gearteten Problemen.

Im Moment weiss ich (als neuer Nutzer des Forums) noch nicht so richtig , wie ich am besten die conf-Dateien (die auf dem Server liegende (start.conf.xeniallaptop580) und die nach dem Reboot auf dem Client liegende zerschossene start.conf)
hochladen kann.

Ehrlich gesagt bin ich mittlerweile ratlos und wäre sehr dankbar, wenn mich bei diesen Problemen jemand unterstützen könnte.

Vielen Dank im Voraus!!

Viele Grüße
Klaus

2

@Holger,

kann es sich um das gleiche Problem handeln wie unter “Warnung vor Lenovo” beschrieben?

@Klaus,

wir können gern per PN einen Termin ausmachen an dem wir online die start.conf berichtigen.

Gruß

Alois

3

Hallo Klaus,

Vorneweg: Bevor ein import_workstations erfolgreich durchlief:
Es war eine Anpassung des /usr/share/linuxmuster/scripts/wimport.sh
erforderlich, da es mit den Einträgen nvme0n1p1, … zu einem
parsing-Problem beim import_workstations kam, dass bei identischer
start.conf mit entsprechenden sda-Einträgen nicht auftrat - ich hatte
das per Auto-Ersetzung (“sda” gegen “nvme0n1p” ausprobiert, also
wirklich sicher mit identischer Datei)
Die Skriptanpassung kam aus einem Foreneintrag heraus
Die Anpassung in der wimport.sh lautete:

grubdisk(){
local partition="$1"
local partnr="$(echo “$partition” | sed -e
‘s|/dev/[hsv]d[abcdefgh]||’ -e ‘s|/dev/xvd[abcdefgh]||’ -e
‘s|/dev/mmcblk[0-9]p||’ -e ‘s|/dev/nvme0n1p[0-9]||’)"
#local partnr="$(echo “$partition” | sed -e
‘s|/dev/[hsv]d[abcdefgh]||’ -e ‘s|/dev/xvd[abcdefgh]||’ -e
‘s|/dev/mmcblk[0-9]p||’)"
case “$partition” in
/dev/nvme0n1*) local disknr="$(echo “$partition” | sed
‘s|/dev/nvme0n([0-9])p[1-9]|\1|’)" ;;
/dev/mmcblk*) local disknr="$(echo “$partition” | sed
‘s|/dev/mmcblk([0-9])p[1-9]|\1|’)" ;;

das ist schon mal sehr seltsam, da linbo seit Jahren nvme unterstützt.
Ichhab im Semianr nvme Geräte seit über einem Jahr im Einsatz.
Die letzten zwei Wochen habe ich Lenovo miix2 hier auf dem Tisch gehabt
und hatte auch da keien Probleme mit dem Eintrag nvme0n1pX in der start.conf

Problembeschreibung im Legacy-Modus:
Partitionierung, Formatierung, und Sync klappen mittlerweile problemlos
(nachdem ich die Label alle auskommentiert habe).

auch komisch: ich kenne bisher nur Probleme die sich mit Labeln lösen
ließen und nciht, dass label Probleme auslösen.

Die Partitionen /dev/nvme0n1p1, /dev/nvme0n1p2, … sind vorhanden und
lassen sich mounten.

Sobald ich ein System starten will (z.B. mit linbo_wrapper start:1)
kommt es zu seltsamen Effekten:
Der Reboot wird angestossen, danach Fehlermeldungen der Art: error:
missing signatur,
das System kommt dann nach mehreren linbo-Durchläufen wieder zum
Linbo-Screen:
Wenn man sich dann die start.conf auf dem Lenovo-Client (linbo-ssh)
anschaut, stellt man fest, dass die Partitionen völlig sinnfrei
durchnummeriert sind: mehrfache dieselbe Partition /dev/nvme0n1p5, als
Cache-Partition wird eine falsche Partition gemountet (scheint mir
zufällig zu laufen: aktuell gerade Partition 6), als OS-Boot/Root-Device
wird auf eine falsche Partition verwiesen.

das mit sinnlos nummerierten Partitionen hab ich allerdings auch schon
erlebt: da muss ich gleich mal suchen, wie das behoben wurde.
Aus der Hüfte geschossen würde ich sagen:
sorg dafür, dass die Cachepartition nicht die letzte auf der Platte ist
und vor allem, dass sie keine Variable Größe hat (also keine leere
Größenangabe).
Aber ich such auch noch mal.

Falls du es nochmal mit dem legacy Modus probieren willst, dann setz an
das Ende der Platte eine „Datenpartition“ die nicht der Cache ist und
schalte die Labels wieder ein.

Beschreibung meiner Probleme im UEFI-Modus:

Partionierung, Formatierung lief problemlos durch,
alle Partitionen liegen korrekt und sind mountbar.
Auch hier funktioniert der Rebootvorgang nicht, Der Laptop bleibt stehen
mit einer Meldung der Art, dass das ausgewählte Device nicht bootable ist.

Bei einem Start mit linbo_wrapper start:1 läuft zunächst alles ohne
Fehlermeldung erst beim grub-install scheint etwas schief zu gehen:
Auzug aus dem Log-FIle:

grub-install: warning: cannot open directory `/usr/share/locale’: No
such file or directory.
Installation finished. No error reported.
mount: /mnt: special device /dev/nvmenp does not exist.

genau das hatte ich bei den miix auch.
Das Problem habe ich durch eine saubere start.conf behoben.
Ich kann dir nicht genau sagen, welcher Eintrag ind er start.conf
fehlerhaft war, weil ich mir die Arbeit danach zu suchen nicht gemacht
hatte.
Ich hab einfach die Vorlagenstart.conf aus
/var/linbo/examples/start.conf.win10-efi runterkopiert und dann ganz
streng nur die Partitonsgrößen und den Imagenamen angefaßt: sonst nichts.
Danach import_workstations gemacht und den Client gesynct (und dadurch
eine linbo neuinstallation auf dem Cleint erzungen).
Danach war die Meldung weg und alles war in Butter.

Achte aber darauf, dass die Datei /var/linbo/boot/grub/.cfg
noch die Zeile

# ### managed by linuxmuster.net

enthält: sonst wird die Datei beim import nicht neu erstellt.

LG

Holger

4

Hallo Alois,
danke für Deine Rückmeldung, ich bin tagsüber halt meist ziemlich lange in der Schule, bei mir ist abends eigentlich immer perfekt, oder Wochende, ich weiss natürlich nicht ob das bei dir passt.

Ziel war eigentlich die UEFI-Variante, aber im Moment habe ich größere Hoffnung bei der bios-Variante weiter zu kommen, da ich befürchte, dass bei der UEFI-Variante ein grub-Problem vorliegen könnte.

Daher zunächst mal die start.conf, mit der ich im Bios-Modus teste:
ichvermute, dass die korrekt ist, da ja das partitionieren und das formatieren mittlerweile eigentlich korrekt läuft.
Es scheint dann beim Abarbeiten der linbo_cmd-Skripte im letzten Schritt irgendetwas schief zu gehen:
Während der Partionierungs und Synchronisationsphase habe ich auf dem Client mir nach jedem Einzelschritt die start.conf ausgeben lassen, in dieser Phase war die start.conf auf dem Client jeweils auch so wie auf dem Server hinterlegt, ich habe stets kleine Änderungen vorgenommen (z.B AutostartTimeout modifiziert) um sicher zu gehen, dass die jeweils aktuelle Datei auf dem Client ankommt.

Mein Testverfahren war meist wie folgt:
linbo-remote -i laptoptest -p partition,format,initcache:rsync,sync:1
oder per linbo_wrapper die Schritte einzeln abzuarbeiten
Dies hat (nach der Label-Entfernung) dann auch funktioniert. Also kommt es mir im Moment so vor, als wäre die start.conf eigentlich o.k.
Was ich überhaupt nicht verstehe: Wieso ist start.conf nach dem “linbo_wrapper start:1” völlig aus dem Tritt? Hier kann ich die einzelnen Schritte des Prozess nicht mehr so richtig mitverfolgen, da ich in dieser Phase vom Client getrennt werde: Es erfolgt ein Reboot der fehlschlägt, dann muss ich erneut mit dem PXE-Boot starten, und es sind wieder mehrere linbo-Durchläufe (in denen ich nicht mitlesen kann was passiert.) und danach liegt eben die zerschossene start.conf auf dem Client: Ich finde die zerschossene start.conf unter /start.conf aber auch, (wenn ich die richtige cache-Partition per Hand mounte) unter /cache/start.conf. (Ich weiss nicht welche zuerst da ist, bzw. den “Master” darstellt?)

Hier nun die start.conf.xeniallaptop580
(Die erste Partition ist im Moment nur vorhanden um die eigentliche Boot-Partition auf Platz 2 liegen zu haben, später soll dort tatsächlich ein Windows hin)
Die Partitionsgrößen habe ich in kiB angegeben (Teiler 2048 wegen ssd), damit ich die Zylindergrößen berücksichtige, das klappt aber im Moment leider noch nicht, mit fdisk wird mir angezeigt, dass die Partitionen erst ab Sector 2 starten (was mich eigentlich wundert??) - die Sektorgrenzen werden laut fdisk also erst ab Beginn der erweiterten Partition korrekt eingehalten )

[LINBO] # globale Konfiguration
Cache = /dev/nvme0n1p5 # lokale Cache Partition
Server = 10.16.1.1 # IP des Linbo-Servers, der das Linbo-Repository vorhaelt
Group = xeniallaptop580
#Achtung: Server und Group werden beim Workstationsimport automatisch gesetzt!
SystemType = bios64 # 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 = # Beispiele:
#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 als Kerneloption gesetzt
# falls gesetzt wird diese IP beim Workstationsimport verwendet
[Partition]
Dev = /dev/nvme0n1p1
Size = 4096
Id = 7
FSType = ntfs
Bootable = no
Label =

[Partition] # Partition fuer Ubuntu
Dev = /dev/nvme0n1p2 # Device-Name der Partition (nvme0n1p2 = zweite Partition auf erster Platte)
Size = 14336000 # Partitionsgroesse 30G
Id = 83 # Partitionstyp 83
FSType = ext4 # Dateisystem ext4
Bootable = no # kein Bootable-Flag
#Label = ubuntu # Partitionslabel ubuntu
Label = # Partitionslabel ubuntu

[Partition] # Swap-Partition
Dev = /dev/nvme0n1p3 # Device-Name der Partition (nvme0n1p3 = dritte Partition auf erster Platte)
#Size = 4G # Partitionsgroesse 4G
Size = 4194304 # Partitionsgroesse 4G (in kiB vielfache von 2048 wegen SSD)
Id = 82 # Partitionstyp 82 (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, 5 = extended, …)
FSType = swap # Dateisystem swap
Bootable = no # kein Bootable-Flag
#Label = swap # Partitionslabel swap
Label = # Partitionslabel swap

[Partition] # Erweiterte Partition
Dev = /dev/nvme0n1p4 # Device-Name der Partition (sda4 = vierte Partition auf erster Platte)
#Label = extended # Partitionslabel
Label = # Partitionslabel
Size = # Partitionsgroesse in kB (leer bei erweiterter Partition)
Id = 5 # Partitionstyp (5 = erweiterte Partition)
FSType = # Dateisystem auf der Partition (leer bei erweiterter Partition)
Bootable = no # Bootable-Flag

[Partition] # Cachepartition
Dev = /dev/nvme0n1p5 # Device-Name der Partition (nvme0n1p4 = vierte Partition auf erster Platte)
#Size = 30G # Partitionsgroesse 30G
Size = 31457280 # Partitionsgroesse 30G (in kiB vielfache von 2048 wegen SSD)
Id = 83 # Partitionstyp 83
FSType = ext4 # Dateisystem ext4
Bootable = no # kein Bootable-Flag
#Label = cache # Partitionslabel cache
Label = # Partitionslabel cache

[Partition] # Daten-Partition
Dev = /dev/nvme0n1p6 # Device-Name der Partition (nvme0n1p5 = fuenfte Partition auf erster Platte)
Size = 20971520 # Partitionsgroesse nicht angegeben = Rest der Platte
#Size = 209715200 # Partitionsgroesse nicht angegeben = Rest der Platte
Id = 83 # Partitionstyp 7
FSType = ext4 # Dateisystem ntfs
Bootable = no # kein Bootable-Flag
#Label = daten # Partitionslabel daten
Label = # Partitionslabel daten

[OS]
Name = Ubuntu # Name des Betriebssystems
Version = # Version (unbenutzt, leer lassen)
Description = Ubuntu 16.04 Xenial # Beschreibung
IconName = ubuntu.png # Icon fuer den Startbutton, muss unter /var/linbo/icons abgelegt sein
Image = # differentielles Image (Erweiterung .rsync, Verwendung nicht empfohlen)
BaseImage = xeniallaptop580.cloop # Dateiname des Basisimages (Erweiterung .cloop)
Boot = /dev/nvme0n1p2 # Bootpartition (unbenutzt, immer gleich Rootpartition)
Root = /dev/nvme0n1p2 # Rootpartition, in die das BS installiert ist
Kernel = vmlinuz # Relativer Pfad zum Kernel
Initrd = initrd.img # Relativer Pfad zur Initrd
Append = ro splash # Kernel-Append-Parameter, ggf. anpassen
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 = yes # automatischer Start des Betriebssystems (yes|no)
AutostartTimeout = 20 # Timeout in Sekunden fuer Benutzerabbruch bei Autostart
DefaultAction = start # Standardaktion bei Autostart: start|sync|new

Und hier die im letzten Schritt zerschossene start.conf auf dem Laptop:

[LINBO] # globale Konfiguration
Cache = /dev/nvme0n1p5 # lokale Cache Partition
Server = 10.16.1.1 # IP des Linbo-Servers, der das Linbo-Repository vorhaelt
Group = xeniallaptop580
#Achtung: Server und Group werden beim Workstationsimport automatisch gesetzt!
SystemType = bios64 # 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 = # Beispiele:
#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 als Kerneloption gesetzt
# falls gesetzt wird diese IP beim Workstationsimport verwendet
[Partition]
Dev = /dev/nvme0n1p1
Size = 4096
Id = 7
FSType = ntfs
Bootable = no
Label =

[Partition] # Partition fuer Ubuntu
Dev = /dev/nvme0n1p5 # Device-Name der Partition (nvme0n1p2 = zweite Partition auf erster Platte)
Size = 14336000 # Partitionsgroesse ca. 15G
Id = 83 # Partitionstyp 83
FSType = ext4 # Dateisystem ext4
Bootable = no # kein Bootable-Flag
#Label = ubuntu # Partitionslabel ubuntu
Label = # Partitionslabel ubuntu

[Partition] # Swap-Partition
Dev = /dev/nvme0n1p5 # Device-Name der Partition (nvme0n1p3 = dritte Partition auf erster Platte)
#Size = 4G # Partitionsgroesse 4G
Size = 4194304 # Partitionsgroesse 4G (in kiB vielfache von 2048 wegen SSD)
Id = 82 # Partitionstyp 82 (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, 5 = extended, …)
FSType = swap # Dateisystem swap
Bootable = no # kein Bootable-Flag
#Label = swap # Partitionslabel swap
Label = # Partitionslabel swap

[Partition] # Erweiterte Partition
Dev = /dev/nvme0n1p5 # Device-Name der Partition (sda4 = vierte Partition auf erster Platte)
#Label = extended # Partitionslabel
Label = # Partitionslabel
Size = # Partitionsgroesse in kB (leer bei erweiterter Partition)
Id = 5 # Partitionstyp (5 = erweiterte Partition)
FSType = # Dateisystem auf der Partition (leer bei erweiterter Partition)
Bootable = no # Bootable-Flag

[Partition] # Cachepartition
Dev = /dev/nvme0n1p5 # Device-Name der Partition (nvme0n1p4 = vierte Partition auf erster Platte)
#Size = 30G # Partitionsgroesse 30G
Size = 31457280 # Partitionsgroesse 30G (in kiB vielfache von 2048 wegen SSD)
Id = 83 # Partitionstyp 83
FSType = ext4 # Dateisystem ext4
Bootable = no # kein Bootable-Flag
#Label = cache # Partitionslabel cache
Label = # Partitionslabel cache

[Partition] # Daten-Partition
Dev = /dev/nvme0n1p5 # Device-Name der Partition (nvme0n1p5 = fuenfte Partition auf erster Platte)
Size = 20971520 # Partitionsgroesse nicht angegeben = Rest der Platte
#Size = 209715200 # Partitionsgroesse nicht angegeben = Rest der Platte
Id = 83 # Partitionstyp 7
FSType = ext4 # Dateisystem ntfs
Bootable = no # kein Bootable-Flag
#Label = daten # Partitionslabel daten
Label = # Partitionslabel daten

[OS]
Name = Ubuntu # Name des Betriebssystems
Version = # Version (unbenutzt, leer lassen)
Description = Ubuntu 16.04 Xenial # Beschreibung
IconName = ubuntu.png # Icon fuer den Startbutton, muss unter /var/linbo/icons abgelegt sein
Image = # differentielles Image (Erweiterung .rsync, Verwendung nicht empfohlen)
BaseImage = xeniallaptop580.cloop # Dateiname des Basisimages (Erweiterung .cloop)
Boot = /dev/nvme0n1p5 # Bootpartition (unbenutzt, immer gleich Rootpartition)
Root = /dev/nvme0n1p5 # Rootpartition, in die das BS installiert ist
Kernel = vmlinuz # Relativer Pfad zum Kernel
Initrd = initrd.img # Relativer Pfad zur Initrd
Append = ro splash # Kernel-Append-Parameter, ggf. anpassen
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 = yes # automatischer Start des Betriebssystems (yes|no)
AutostartTimeout = 20 # Timeout in Sekunden fuer Benutzerabbruch bei Autostart
DefaultAction = start # Standardaktion bei Autostart: start|sync|new

Eine Idee, die ich mal phasenweise (allerdings bei meinen UEFI-Tests) verfolgt hatte, die grub.cfg könnte das Problem sein.
Im Moment lasse ich sie auf “# ### managed by linuxmuster.net ###”
Es fällt allerdings auf, dass bei einer typischen /dev/sda-Konfiguration in der Grub-Datei
Einträge der Art set root="(hd0,1)" … vorhanden sind, bei der autogenerierten Grub-Datei für meinen nvme0n1-Fall generierten stehen aber Einträge
der Art set root="(hd1,)" .
Möglicherweise liegt das Problem bei der automatischen Generierung der Grub-Datei!? Würde mir bei meiner UEFI-Problematik einleuchten, den Zusammenhang mit der zerschossenen start.conf kann ich aber nicht so richtig erkennen.

Viele Grüße und schon mal vielen Dank für das Mitdenken bei meinem Problem
Klaus

5

Hallo Holger,
vielen Dank für deine Rückmeldung, ich habe deinen Post erst nach dem Absenden meines 2.ten Beitrags gesehen.
Ich setze UEFI-Thema noch mal neu auf entlang der von dir vorgeschlagenen examples-Datei und melde mich dann.
Ich habe in Erinnerung eine der EFI-Examples als Basis genommen zu haben, aber vielleicht hatte ich eine andere Beispiel-Datei genommen.

Das Thema mit der wimport.sh habe ich aus einem anderen Forenbeitrag
#LINBO klont nicht auf neuerer Hardware siehe Beitrag von hoeferwolf Dort scheint das schon mal aufgetreten zu sein.

Für diesen Aspekt möglicherweise relevant: die Testumgebung basiert auf einer Linuxmusterlösung die schon zwei Migrationsschritte hinter sich hat. Die Neuinstallation der linbo-packages hatte diese Datei nicht dabei, ich glaube sie kommt aus linuxmuster-base, also ist sie bei mir wahrscheinlich älterne Datums
Unsere Live-Umgebung hat diese Zeilen schon drin ich hole mir die mal rüber und vergleiche
(am Wochende kann ich die Liveinstallation aus der xen-Umgebung exportieren um eine aktuellere Testumgebung (die ohne Migrationsschritte hochgezogen ist) aufzubauen.

Viele Grüße
Klaus

6

Hallo Klaus,

Für diesen Aspekt möglicherweise relevant: die Testumgebung basiert auf
einer Linuxmusterlösung die schon zwei Migrationsschritte hinter sich
hat. Die Neuinstallation der linbo-packages hatte diese Datei nicht
dabei, ich glaube sie kommt aus linuxmuster-base, also ist sie bei mir
wahrscheinlich älterne Datums
Unsere Live-Umgebung hat diese Zeilen schon drin ich hole mir die mal
rüber und vergleiche
(am Wochende kann ich die Liveinstallation aus der xen-Umgebung
exportieren um eine aktuellere Testumgebung (die ohne Migrationsschritte
hochgezogen ist) aufzubauen.

nach dem lesen deines ersten Beitrags dachte ich schon: da ist doch was
krum an der Installation.
Dass es an der Migration liegt, glaube ich nicht unbedingt: immerhin
sind meine zwei produktiven Installationen in Schule udn Semianr
migrationen seit 2003: also noch von der „vor paedML Ära“. Ich hab immer
migriert.

Ist ja auch wurscht wo das Problem her kommt.
Ich würde mal auf dem System folgendes machen:

apt update
apt purge linuxmuster-linbo linuxmuster-linbo-common

und danach
apt install linuxmuster-linbo linuxmuster-linbo-common

Am Ende dann auf jeden Fall ein
import_workstations
machen.

LG

Holger

7

Hallo Holger,
die Pakete inuxmuster-linbo linuxmuster-linbo-common hatte ich in der letzten Zeit oft gepurged und neu installiert.
Aber dein Hinweis, dass das Import-Verhalten (die von mir beschriebene Problematik mit der erforderlichen Anpassung der wimport.sh) seltsam ist, hat mich gerade ein Stück weiter gebracht!!
Ich habe mir die wimport.sh aus der Liveumgebung geholt, und nach einem import_workstations sofort eine besser grub.conf vorliegen gehabt (also eine die jetzt den vernünftigen “root=”(hd0,2)" -Einträge besitzt.

Zuerst ging es wieder schief (zerschossene start.conf auf dem Client, aber nachdem ich die Label wieder gesetzt hatte ist der Reboot gut gelaufen!!
Danke!!
Ich versuche das ganze jetzt mit UEFI (da will ich eigentlich bei meinen Tests hin) und melde mich dann wieder

Ein Problem habe ich derzeit auf jeden Fall noch:
Mein Xenial-Image ist ein “/dev/sda-Image” ich muss dem Image also noch eine neue /etc/fstab unterschieben.
Ich hatte zunächst versucht das Paket llinuxmuster-client-servertools zu nutzen um mir die Verzeichnisstrukturen und eine geeignete postsync-Datei zu installieren:
In der Live-Umgebung lag das Paket schon vor (dort tritt aber das selbe Problem auf)

mein Versuch entlang der Doku mit
linuxmuster-client -a list-available
die verfügbaren Images anzeigen zu lassen, führt auf
find: “/var/cache/linuxmuster-client-servertools/”: Datei oder Verzeichnis nicht gefunden
es werden dann auch eine leere Liste der Images angezeigt.
Ein Neuanlegen des Verzeichnis und Neuausführung löscht das Verzeichnis dann wieder
Ich habe dann in der Liveumgebung den Befehl ebenfalls ausgeführt (dort waren die Verzeichnisse schon da")
Bei obigem Aufruf kam es zur gleichen Fehlermeldung und die ehemals vorhandenen Verzeichnisse waren danach gelöscht.

Ich habe dann aus den Forenbeiträgen heraus mir manuell die Verzeichnisstruktur
/var/linbo/linuxmuster-client/xeniallaptop580/etc/
erzeugt und eine fstab reingelegt:
/dev/nvme0n1p2 / ext4 errors=remount-ro 0 0
/dev/nvme0n1p3 none swap sw 0 0
reingelegt.
Als postsync-Skript habe ich die aus der Liveumgebung, die bislang bei anderen images eigentlich funktioniert hatten.
Das hatte aber gerade eben nicht funktioniert. (Ich hatte noch keine Zeit, das näher zu untersuchen.)

Ich mache mich jetzt erst mal mit neuem Mut ans UEFI-Thema und melde mich dann wieder.

In jedem Fall nochmal vielen Dank - meine Laune ist gerade erheblich in den positiven Bereich gestiegen!!

Viele Grüße
Klaus

8

Hallo Klaus,

ich denke, wenn Du Holgers Ratschläge umsetzt, dann kommst Du weiter.

Ich - für meinen Teil - gehe UEFI so lange aus dem Weg wie es irgendwie geht.

Gruß

Alois

9

Hallo Johannes,

Ein Problem habe ich derzeit auf jeden Fall noch:
Mein Xenial-Image ist ein “/dev/sda-Image” ich muss dem Image also noch
eine neue /etc/fstab unterschieben.
Ich hatte zunächst versucht das Paket llinuxmuster-client-servertools zu
nutzen um mir die Verzeichnisstrukturen und eine geeignete
postsync-Datei zu installieren:
In der Live-Umgebung lag das Paket schon vor (dort tritt aber das selbe
Problem auf)

mein Versuch entlang der Doku mit
linuxmuster-client -a list-available
die verfügbaren Images anzeigen zu lassen, führt auf
/find: “/var/cache/linuxmuster-client-servertools/”: Datei oder
Verzeichnis nicht gefunden/
es werden dann auch eine leere Liste der Images angezeigt.

ja: die Repos sind umgezogen, und da die URL wohl im
linuxmuster-client-servertools script fest drin ist, muss erst das Paket
angepaßt werden, damit es wieder funktioniert.
Das ist sehr schade, da ein Herunterladen eines Images dir die
Verzeichisstrucktur /var/linbo/linuxmuster-client/ komplett mit
korrekten Rechten erstellen würde.

Ich habe dann aus den Forenbeiträgen heraus mir manuell die
Verzeichnisstruktur
/var/linbo/linuxmuster-client/xeniallaptop580/etc/

der Pfad stimmt noch nciht: es fehlt noch „common“.
/var/linbo//

Also:
/var/linbo//common/etc/
wäre das Verzeichnis, dass für alle in der Gruppe gilt.
Willst du nur den PC r100pc01 „treffen“, dann mach es hier hin:
/var/linbo//r100pc01/etc/

Und die Rechte müssen stimmen.
Das wird vor allem interessant, wenn du, wie ich, den ssh-key mit rüber
schiebst, weil der ssh Deamon nur rw- — — (also Rechte 600) Dateien
nimmt.
Die kann aber linbo nicht bewegen.
Also hat die Datei öffenere Rechte: die werden dann im postsync gesetzt.

bei mir Rechte im Verzeichnis:
ls -al /var/linbo/linuxmuster-client/
insgesamt 68
drwxr-xr-x 4 root root 4096 Jan 19 2018 .
drwxr-xr-x 13 root root 36864 Mai 23 00:36 …
drwxr-xr-x 8 root root 4096 Okt 26 2018 trusty
drwxr-xr-x 3 root root 4096 Mai 10 2016 xenial

ls -al /var/linbo/linuxmuster-client/trusty/
insgesamt 32
drwxr-xr-x 8 root root 4096 Okt 26 2018 .
drwxr-xr-x 4 root root 4096 Jan 19 2018 …
drwxr-xr-x 5 root root 4096 Mär 20 2017 common
drwxr-xr-x 3 root root 4096 Apr 5 2016 s001vc01-buttonbar
drwxr-xr-x 3 root root 4096 Okt 23 2018 s003
drwxr-xr-x 3 root root 4096 Jan 6 2015 s003hp100
drwxr-xr-x 3 root root 4096 Okt 23 2018 s004
drwxr-xr-x 3 root root 4096 Jan 6 2015 s004hp100

ls -al /var/linbo/linuxmuster-client/trusty/common/etc/
insgesamt 24
drwxr-xr-x 4 root root 4096 Apr 2 22:15 .
drwxr-xr-x 5 root root 4096 Mär 20 2017 …
drwxr-xr-x 2 root root 4096 Mär 20 2017 cron.daily
drwxr-xr-x 2 root root 4096 Mär 20 2017 default
-rw-r–r-- 1 root root 504 Apr 2 22:15 fstab
-rw-r–r-- 1 root root 459 Jan 6 2015 hosts

erzeugt und eine fstab reingelegt:
/dev/nvme0n1p2 / ext4 errors=remount-ro 0 0
/dev/nvme0n1p3 none swap sw 0 0
reingelegt.
Als postsync-Skript habe ich die aus der Liveumgebung, die bislang bei
anderen images eigentlich funktioniert hatten.
Das hatte aber gerade eben nicht funktioniert. (Ich hatte noch keine
Zeit, das näher zu untersuchen.)

ich amche das genau so: mit einer fstab Datei: weil meine neuen Rechner
nvme SSDs haben, die alten aber SATA SSDs: also haben beide Gruppen
eigene fstab Dateien (dann muss ich nciht drauf achten, auf welchem
Client ich das Image erstelle).

Viele Grüße

Holger

10

Hallo Holger,
ich hatte das Verzeichnis common vergessen und musste in der postsync-Datei noch auf

PATCHCLASS=$HOSTGROUP

umstellen, danach lief der Postsync wie gewünscht und die erwünschte /etc/fstab ist nun da.
Vielen Dank für deinen Hinweis, das hat weitergeholfen!

Ich habe mittlerweile weitere Tests mit den bios64-Partitionierungen durchgeführt, das klappte zunächst erstmal ganz gut, d.h. der Laptop konnte komplett ins Xenial starten.
Danach allerdings hatte ich, nachdem ich wegen einer leoclient2-XP-Partition noch weitere Partitionen eingefügt hatte (insgesamt /dev/nvme0n1p1 bis /dev/nvme0n1p7 (die letzte ist eine Datenpartion)
erneut ein Durcheinander in der Partitonsreihenfolge:
cache und swap haben ihre Rolle getauscht, oder auch zuletzt dann die 6.te Partion (mit Label winxp) und die 7.Partition (mit Label = daten)
Die Grubdatei hatte in dieser Testphase immer die vernünftigen Einträge “root=”(hd0,2)"

Ich bin dann erst mal auf efi64 umgestiegen:
Meine start.conf basiert auf der examples/start.conf.win10-ubuntu-efi
ich habe lediglich Größen angepasst (v.a. wegen der Ubuntu-Partition-Größe für das schon vorhandene xenial-Image, und für eine etwas größer WIndows10-Partition)

Dabei habe ich zunächst folgendes festgestellt:
Hier kommt es trotz neuester wimport.sh (ich habe meine verglichen mit der vom Git-Hub (Stand 20171107) zu Einträgen der Art “root=”(hd1,X)" in der grub-Datei.

Der Laptop stoppt dann beim Reboot, mit einem Hinweis auf falsche Bootdisk.

Ich habe dann mal bischen in der wimport.sh rumgelesen:
Wenn ich die Zeile

# adjust disknr in case of efi/gpt
echo "$systemtype" | grep -qi efi && disknr=$(( $disknr +1 ))

auskommentiere, schreibt er die meiner Einschätzung nach richtigen Einträge “root=”(hd0,X)"

Allerdings komme ich im Moment mit der EFI-Konfiguration trotzdem nicht mehr weiter, da wieder die
Partitionen durcheinander geraten (mehrfache /dev/nvme0n1p2 -Einträge (p2 ist eigentlich die msr-Partion, p4 die Ubuntu-Partion, aber schon beim Partitionieren geht es schief:
Ein Auszug aus der /tmp/partitions (auf dem Client)

/dev/nvme0n1p1 efi 200m ef vfat yes
/dev/nvme0n1p2 msr 128m 0c01 - no
/dev/nvme0n1p3 win10 60g 7 ntfs no
/dev/nvme0n1p2 ubuntu 14336000 83 ext4 no
/dev/nvme0n1p5 swap 4g 82 swap no
/dev/nvme0n1p6 cache 80g 83 ext4 no
/dev/nvme0n1p7 daten - 7 ntfs no

Die gleichen Vertauschungen sind in der lokalen start.conf des Clients zu finden.
(Das Durcheinander war auch schon vor der oben beschriebenen wimport.sh-Anpassung da)

Ich habe, weil ich etwas unsicher wegen der Probleme in der wimport.sh bin
mal meinen Package-Stand ausgelesen

ii  linuxmuster-base                  6.2.4-0ubuntu0                        linuxmuster.net configuration scripts
ii  linuxmuster-client-servertools    0.7                                   linuxmuster serverside scripts for managing a community based ubuntu-cloop
ii  linuxmuster-linbo                 2.3.48-0                              linuxmuster-linbo scripts
ii  linuxmuster-linbo-common          2.3.48-0

Bei der linuxmuster-base bin ich mir wegen der Probleme in der wimport.sh nicht sicher, ob das aktuell ist, einen generelles apt-get upgrade hatte ich vor kurzem durchlaufen.

Am Rande nachgefragt: Wegen der cloop-Images aus den linuxmuster-client-servertools:
In der /etc/linuxmuster/client-servertools.conf steht

CONF_CLOOP_SERVER="http://cloop.linuxmuster.net/"

den Server scheint es nicht mehr zu geben, wo findet man denn die letzten xenial-Images?
[Kann man die linuxmuster-client-servertools noch irgendwie retten durch Angabe eines anderen Servers?]

Falls Ihr eine Idee habt, woran das mit den sonderbaren Vertauschungen liegen kann, würde mir das sehr helfen!!

Viele Grüße
Klaus

11

Hallo Klaus!

Eine Sache ist mir beim Betrachten der start.conf noch aufgefallen. Hattest Du bei allen Partitionen ein Label gesetzt? Falls nicht könnte das Merkwürdige verhalten vielleicht daher kommen, da sonst die Label für mich ein Allheilmittel ist.

Sorge auch mal zur Sicherheit dafür das pro Partion nur eine Label-Zeile vorhanden ist. Mensch weiß ja nie.

Liebe Gruß

Thorsten

12

Hallo Klaus,

In der /etc/linuxmuster/client-servertools.conf steht

CONF_CLOOP_SERVER=„http://cloop.linuxmuster.net/“ |

den Server scheint es nicht mehr zu geben, wo findet man denn die
letzten xenial-Images?

normalerweise wäre das jetzt einfach
https://archive.linuxmuster.net
Aber ich glaube, die cloops waren nicht so einfach dort hin zu übertragen.
Da müßte mal Frank was zu sagen.

LG

Holger

13

Hallo zusammen,
bei mir sind jetzt gerade nach einer langen Irrfahrt beide Varianten efi64 und bios64 (legacy) lauffähig.
Ob Zufall oder nicht (ich habe das abschliessend nicht mehr gegengetestet):
@alois : Dein Hinweis auf die Kommentare (alte auskommentierte Label-Einträge rauszuschmeissen) hat mich dann auf die richtige Spur gebracht. Das rauschmeissen hatte zunächst nicht geholfen, ich habe dann noch weitere Kommentare rausgeschmissen und mich dann an die Gross-Kleinschreibung der Label-Eintrage gemacht.

Die Probleme mit dem Durcheinander in der Reihenfolge der Partitionen hat sich nun wie folgt gelöst:

Bei UEFI (efi64):
Ich habe in der start.conf die Label-Eintrage alle gross geschrieben
also Label = WIN10 statt Label = win10, usw.
danach hat es geklappt, dass die Partitionen in der richtigen Reihenfolge angelegt wurden (mittlerweile 8 Partitionen)
Einmal gab es noch ein Problem mit Label = WIN10 und Label=WINXP
Ich habe das auf Label = WIN10 und Label = XP abgeandert und dann lief es wieder.
(Laut Logfile hat linbo hat aber die labels beim anlegen der Partitionen (ich vermute mit parted) dann klein geschrieben, beim Grub kommen sie in Grosschreibung an)

Bei der bios64-Situation war es gerade umgekehrt:
Dort musste ich klein schreiben, um das Durcheinander in der Reihenfolge zu vermeiden.
(oder die Label-Einträge ganz weglassen, auch das hatte bei einem Durchlauf geholfen).
Ich bin mir nicht absolut sicher, ob meine Analyse absolut wasserdicht ist, da ich jetzt am Schluss noch einmal abschliessend den Gegentest machen müsste, wenn ich morgen noch Zeit habe, ändere ich nochmal hin und zurueck um zu checken, ob es 100%-tig daran liegt.

Auf jeden Fall ist es dort irgendwas krumm, es ist schon ziemlich sonderbar, dass auf dem Client eine zerschossene start.conf ankommt, dabei bin ich mir sicher, dass bei meinen Tests die jeweilig bearbeitete start.conf auf dem Server auch tatsächlich als Quelle diente (-> es waren jeweils kleine überprüfbare Änderungen eingebaut, z.B. AutostartTimeout)

Aber bei mir scheint das Reihenfolge-Problem jetzt erstmal (hoffentlich dauerhaft) behoben.

Beim UEFI-Modus blieb der Thinkpad zunächst nach dem Reboot immer noch hängen:
Thinkpad-Bios-Meldung:

Boot Manager recovered from an error
Boot Manager has restored Boot Priority from default configuration

Die Fehlermeldungen bei der Reboot-Phase ausgelöst durch linbo_wrapper start:2 im linbo.log waren immer noch vorhanden:

mount: /mnt: special device /dev/nvmenp does not exist.
...
invalid numeric value p1

Die Anpassungen in der Datei wimport.sh

# adjust disknr in case of efi/gpt
echo "$systemtype" | grep -qi efi && disknr=$(( $disknr +1 ))

haben zwar eine vernünftige grub.conf produziert mit den gewünschten Einträgen “root=”( hd0 ,X)"
aber das scheint das Problem nicht zu lösen.

Ich habe dann im Thinkpad-Bios eine geeignete Einstellung gefunden (Workaround):
Die Einstellung Boot Order Lock -> Enabled hat dafür gesorgt, dass sich das UEFI-Bios nicht um die Rebootvorgabe kümmert, d.h. beim Reboot danach ist der Laptop wie gewünscht via Linbo ins Xenial gebootet,
(Meine Interpretation: als Default ist im Bios Netzwerkboot eingestellt, daher startet das Bios über den pxe-boot zunächst linbo und linbo startet dann die Platte mit der letzten grub-Konfiguration, die wegen des Reboot-Mechanismus dann die richtige Partition anvisiert)

Vermutlich ist zuvor irgendwas in der EFI-Partition nicht geeignet geschrieben worden (beim legacy-mode trat das Reboot-Problem nicht auf.)

In jedem Fall habe ich die Partitioniererei und Rebooterei jetzt irgendwie durchstanden und ich habe jetzt erstmal einen lauffähigen Linux-Client (Xenial) sowie die Partition für Windows auf dem Test-Laptop!!

Noch mal vielen Dank für Eure Unterstützung dabei. :slight_smile:

Jetzt ist das Aufspielen von Win10 dran :frowning:

Viele Grüße
Klaus

PS: Auf dem Server archiv.linuxmuster.net liegen die cloop-Dateien nicht.
Es wäre super wenn Ihr mir da noch eine Server-Quelle hättet, bei der man das aktuelle xenial.cloop herunterladen könnte, bzw. auf den man die linuxmuster-client-servertools ausrichten könnte.

14

Hallo Klaus,

das war Thorsten! Ehre wem Ehre gebührt :wink:

Mir kam aber noch eine Idee bei all den Problemen die Du beschreibst.

Mit welchem Editor bearbeitest Du die start.conf Dateien? Bei Verwendung eines Windows-Editors könnte ich mit vorstellen, dass Du solche Probleme bekommst, da Windows und Linux mit unterschiedlichen Zeilenende-Zeichen arbeiten.

Gruß

Alois

15

Hallo Klaus,

vielen Dank für Deine ausführlichen Beschreibungen! Ich hab’ das (Installation von Win 10 auf Lenovo-Laptop mit UEFI-BIOS und M.2 NVMe-SSD) am Di auch vor und hoffe, ich bin nun für evtl. auftretende Probleme gewappnet.
Musstest Du in der start.conf anstatt /dev/sda auf /dev/nvme0n1p1 umstellen? [Edit: ok, hab Deine start.conf gesehen. Also ja]

Viele Grüße,
Jochen

16

Hallo zusammen,
@alois Beim Schreiben der start.conf habe ich immer mit dem vi bzw. vim geschrieben. Tatsächlich hatte ich auch mal die Befürchtung, da ich nicht sicher war, ob bei einem Transfer aus der Live-Umgebung (mit Filezilla und sftp) irgendwas in Richtung dos-format sein könnte (eigentlich passiert das mit filezilla nicht) und dann vorsichtshalber mit dos2unix konvertiert, aber das war es nicht (und vim würde das glaube ich eh anzeigen).
@MachtDochNix An Dich noch einmal danke für deinen Hinweis, mit den Label-Eintraegen vorsichtig umzugehen.
@jochen Wir haben Thinkpad L580 -Geräte, bzw. mein Test ist dafür da, solche anzuschaffen, ich habe also im Moment 1 Test-Gerät, ich konnte/kann also beim Test noch nicht überprüfen, wie es beim aufspielen auf ein 2-tes Gerät läuft und ob da noch Überraschungen (vor allem bei Win10) auf mich warten.
Und ich habe überall Einträge mit /dev/nvme0n1pX drin statt sdaX, also z.B. bei der efi64-Variante mit der Grossschreibung:

[Partition]              # Partition fuer EFI
Dev = /dev/nvme0n1p1     # Device-Name der Partition (erste Partition auf erster Platte)
Label = EFI              # Partitionslabel (efi system partition)
Size = 200M              # Partitionsgroesse 200M, ist keine Einheit (M, G oder T) angegeben, wird kiB angenommen
Id = ef                  # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, ef = efi)
FSType = vfat            # Dateisystem auf der Partition (FAT32)
Bootable = yes           # Bootable-Flag gesetzt

[Partition]              # Partition fuer MSR
Dev = /dev/nvme0n1p2     # Device-Name der Partition (zweite Partition auf erster Platte)
Label = MSR              # Partitionslabel msr (microsoft reserved partition)
Size = 128M              # Partitionsgroesse 128M
Id = 0c01                # Partitionstyp 0c01
FSType =                 # kein Dateisystem
Bootable = no            # kein Bootable-Flag

[Partition]              # Partition fuer Windows
Dev = /dev/nvme0n1p3     # Device-Name der Partition (dritte Partition auf erster Platte)
Label = WIN10            # Partitionslabel win10
Size = 60G               # Partitionsgroesse 60G
Id = 7                   # Partitionstyp
FSType = ntfs            # Dateisystem ntfs
Bootable = no            # kein Bootable-Flag

[Partition]              # Partition fuer Ubuntu
Dev = /dev/nvme0n1p4     # Device-Name der Partition (vierte Partition auf erster Platte)
Label = UBUNTU           # Partitionslabel ubuntu
Size = 20G          # Partitionsgroesse 30G 
Id = 83                  # Partitionstyp 83
FSType = ext4            # Dateisystem ext4
Bootable = no            # kein Bootable-Flag
usw.

Nur bei der Cache-Partition habe ich ein klein geschriebenes Label = cache genommen.
Im Moment kann ich aber noch nicht einschätzen, ob bei Win10 mit meiner start.conf Probleme auftreten könnten)

Wenn ich das Windows10 drauf habe, oder auch wenn Du sie früher brauchst, schicke ich Dir gerne nochmal die ganze start.conf. (legacy oder uefi-Variante)

Viele Grüße
Klaus

17

Hallo Klaus,

Same here. Bei uns sollen’s E490 werden.

Du bist jetzt in der start.conf aber doch auf Partitionsgrößen à la 60G anstatt Vielfache von 2048 umgestiegen!?

Und die wimport.sh hast Du nach wie vor so umgeändert, dass sie Einträge à la hd0,X anstatt hd1,X produziert?

Ich hab bei mir im UEFI-BIOS übrigens noch einen Schalter gefunden:
Security - Secure Boot: enabled
Ich denke, ich werde den vorsichtshalber auf disabled stellen, um das Problem von Holger zu umgehen, dass Linbo nicht gebooted werden konnte.
Gibt’s den bei Dir auch?

Vielen Dank und viele Grüße,
Jochen

18

Hallo Jochen,
ich habe, nachdem ich wegen der sonderbaren Situation, dass die Partitionen erst auf Zylinder 2 begonnen hatten, und ich von fdisk -l falsches alignment (trotz der 2048-Vielfachen und kiB-Angaben) attestiert bekam, eben mal mit den G-Angaben getestest / rumgepielt.
Ich habe dann auf dem Client im Linbo-Modus sowohl mit fdisk -l nachgeschaut, außerdem gibt es unter linbo auch parted und im interaktiven Modus von parted dann die Option align-check opt “partititionsnr” (für partitionsnr dann 1, 2, 3, … nehmen)
Da sah dann (mit meine 20G , 60G usw. -Angaben) alles gut aus (ich weiss aber nicht, ob meine Untersuchung hier ausreicht)
Möglicherweise wird das alignment von linbo bei den G-Angaben (ich weiss leider nicht ob das GiByte sind oder nicht) schon alles richtig gemacht.

Bei den Bioseinstellungen habe ich für UEFI
NETworkBoot PCI LAN
UEFI/Legacy Boot UEFI First
CSM support Yes
Boot Order Lock Disabled
SecurityBoot Disabled

Und im Legacy Modus
NETworkBoot PCI LAN
UEFI/Legacy Legacy Only
CSM support Yes
SecurityBoot Disabled

Wie gesagt ich weiss noch nicht, wie sich das ganze bei Win10 verhalten wird.

Viele Grüße
Klaus

19

Hallo Jochen,

Ich hab bei mir im UEFI-BIOS übrigens noch einen Schalter gefunden:
Security - Secure Boot: enabled

Secure boot muß ausgeschaltet sein, da das UEFI sonst nur bootloader
bootet, die mit einem vom UEFI als gültig angesehenen Zertifikat
signiert sind (also eigentlich nur Redhat, MS und ubuntu) also in keinem
Fall unser grub den linbo verwendet.

Ich denke, ich werde den vorsichtshalber auf disabled stellen, um das
Problem von Holger zu umgehen, dass Linbo nicht gebooted werden konnte.

das Bootproblem der Lenovo MIIX hatte nichts mit Secure Boot zu tun.
Secure Boot war ausgeschaltet.

LG

Holger

20

Hallo,

ich habe, nachdem ich wegen der sonderbaren Situation, dass die
Partitionen erst auf Zylinder 2 begonnen hatten, und ich von fdisk -l
falsches alignment (trotz der 2048-Vielfachen und kiB-Angaben)
attestiert bekam, eben mal mit den G-Angaben getestest / rumgepielt.
Ich habe dann auf dem Client im Linbo-Modus sowohl mit fdisk -l
nachgeschaut, außerdem gibt es unter linbo auch parted und im
interaktiven Modus von parted dann die Option align-check opt
“partititionsnr” (für partitionsnr dann 1, 2, 3, … nehmen)
Da sah dann (mit meine 20G , 60G usw. -Angaben) alles gut aus (ich weiss
aber nicht, ob meine Untersuchung hier ausreicht)
Möglicherweise wird das alignment von linbo bei den G-Angaben (ich weiss
leider nicht ob das GiByte sind oder nicht) schon alles richtig gemacht.

ja: linbo (in dem Fall das gdisk, das linbo verwendet) macht mit den G
Angaben alles richtig.
Ich verwende auch seit über einem Jahr nurnoch G Angaben.

LG

Holger