Labelproblem in linbo

Clientpflege linbo
#1

Hallo Thomas (Schröder),

ich mach mal einen neuen Tread auf zu deinem Post hier:

https://ask.linuxmuster.net/t/neues-linbo-gui/6586/65

das Labelproblem ist auch bei mir aus dem Fokus geraten, weil ich es selbst seit 1,5 Jahren nicht mehr hatte.
In meinem Kopf kam das aber nur vor, wenn man „umpartitioniert“ und auf der Platte schon Label vorhanden sind, die in der neuen start.conf wieder vorkommen.
Dann wirft linbo die Devicenamen durcheinander beim Partitionieren.
Deinem Post entnehme ich, dass das nicht nur in der Situation vor kommt.
Kannst du hier das Problem nochmal schildern?
Ich hatte es nämlich nie „einfach so“ beobachtet.

LG

Holger

LINBO: Win10 von KVM nach KVM: Fehler 0xc000000e
#2

Hallo Holger,

es stimmt schon - es kommt immer dann vor, wenn Labels schon an anderer Stelle existieren. Das passiert, wenn man z.B. die Partitionsreihenfolge oder -größe ändert oder eben einen Namen an anderer Stelle verwenden will, Namen tauscht, usw.

In einem System, welches nicht verändert wird, dürfte das nicht vorkommen - aber da ist ja sogar das Partitionieren unnötig.

Das Hauptproblem, das ich sah (und weswegen ich diesen „Bug“ innerlich als „schwer“ markiert habe), war, dass man damit den Rechner in einen unbenutzbaren Zustand schießen kann. Und das verbunden mit der Tatsache, dass es mit einer Zeile zu beheben ist.

Konkret: ich habe 150 Rechner und habe mir z.B. ein neues Image geholt/gemacht. Dafür passen ich die Partitionsgröße an oder füge eine Partition ein. Führe ich dann ein linbo-remote […] partition durch, ist die Partitionierung kaputt und jenachdem, wie die Partitionierung aufgebaut ist, ist auch kein bootfähiges Linbo mehr am Rechner.
Boote ich per PXE, lande ich immer noch in Linbo (und kann, wenn ich den Fehler samt Workaround kenne, durch das Umbenennen der Labels das Problem lösen).
Boote ich die Rechner lokal (seit der Reboot-Pflicht und neurem Linbo ja durchaus sinnvoll und schneller), war es das und ich bin mit Linbo-Stick zu 150 Rechnern unterwegs. Das ist dann halt richtig scheiße.

Das Problem kann man einfach aus der Welt schaffen - genau wie damals mit dem „Dirty Bit“. Man muss einfach

  • entweder vor jedem Partitionieren einmal die Partitionierungsdaten überschreiben (mit dd…)
  • oder (dahin zielte damals mein Pull Request) man fügt einen linbo-Befehl („wipe“ war mein Vorschlag) hinzu, der die Paritionierung überschreibt - dann weiß man, dass man damit auf Nummer sicher gehen kann und gleichzeitig wird nicht auch dann überschrieben, wenn es eigentlich nicht nötig wäre.

Ich habe Thomas damals so verstanden, dass er die erste Variante bevorzugt. Was danach gekommen ist, weiß ich nicht. Ich meine, dass das im Source Code auf github eingebaut ist. Aber für die 6.2 ist es trotz mehrerer neuer Versionen nicht enthalten (gerade nochmal nachgeschaut).

Viele Grüße
Thomas

#3

Hi zusammen,

Ich habe das Problem auch auf der LMN7 mit neuestem Linbo. Es passiert (wie schon gesagt) eigentlich jedes mal, wenn man Platten „umformatiert“. Ich löse es im Moment wie der Netzwerkbetreuer an meiner alten Schule und lösche über die Konsole mit parted einmal alle Partitionen (sehr nervig).
Ich würde mich auch über eine Lösung freuen :slight_smile:

EDIT:
Habe grad gesehen, dass Thomas die dd Lösung damals eingebaut hat (Siehe https://github.com/linuxmuster/linuxmuster-linbo/commit/7c8b2555799580e7681bf553c34e787cd773518c )
Allerdings scheint das nicht zu helfen :man_shrugging:

Viele Grüße
Dorian

#4

Hallo!
Ich habe noch eine lmn6.2 aber das testing linbo 68. Bei mir reicht Partitionen löschen nicht, ich erstelle immer eine Partiton über die ganze Platte, schreibe die auf die Platte, muss dann rebooten, weil die neuen Plattendaten nicht eingelesen sind (ohne geht es auch wirklich nicht).
Dann klappt das Um-Partitionieren fehlerlos.
LG
Max

#5

Hallo Thomas und Dorian,

  • entweder vor jedem Partitionieren einmal die Partitionierungsdaten
    überschreiben (mit dd…)
  • oder (dahin zielte damals mein Pull Request) man fügt einen
    linbo-Befehl („wipe“ war mein Vorschlag) hinzu, der die
    Paritionierung überschreibt - dann weiß man, dass man damit auf
    Nummer sicher gehen kann und gleichzeitig wird nicht auch dann
    überschrieben, wenn es eigentlich nicht nötig wäre.

… ich sehe beides nicht als Lösung an.

Ich habe das damals, als es in den Sommerferien 2019 bei mir auftauchte,
untersucht und habe folgendes bemerkt.
linbo bootet und wenn es label findet, die in der start.conf stehen,
dann überstimmen die vorgefundenen Label die in der start.conf die auf
dem Cleint liegt. Das bedeutet: du kannst da vorher löschen, was du
willst: wenn du linbo nicht vor dem Partitionieren neu startest, dann
wir quark partitioniert.
Das kannst du einfach testen: boote mal einen Rechner mit linob, bei dem
die Partition
/dev/sda3 das Label „cache“ hat mit einer start.conf in der /dev/sda4
das Label cache hat und sda3 was anderes (sagen wir swap). Und dann geh
mit linbo-remote auf die Möhre und schau in die start.conf, die auf dem
Rechner liegt: da steht dann bei swap /dev/sda3 UND bei cache auch.

… vielleicht rede ich aber auch von einem anderen Problem …

LG

Holger

#6

Hallo Holger,

Du hast mich gerade erleuchtet :sweat_smile:
Deeeeeshalb haben sich bei mir mal „einfach so“ die partitionspfade geändert und ich hab gegrüblet … :rofl:
Aber das ist (glaube ich) ein anderes Problem … Sollte aber meiner Meinung nach unbedingt gelöst werden.

Mein Problem (und auch das von @thoschi wenn ich ihn nicht falsch verstehe) ist folgendes:
Wenn auf einer Platte irgendwelche Partitionen existieren (zum Beispiel von einer Windows Installation aus Zeiten bevor Linuxmuster eingeführt wurde, das ist bei mir der häufigste Fall), dann geht das Partitionieren fast immer in die Hose. Meist gibt es dann die Fehlermeldung „Partitioning failed, Partition not ready“ (oder so ähnlich). In dem Fall hilft bei mir wie gesagt nur noch alle Partitionen löschen und Neustarten.

VG
Dorian

#7

Hi Dorian,
dein Problem und das von Holger tritt bei mir immer simultan auf (eine vermurkste start.conf, in der Teile der neuen start.conf vom Server und teile des aktuellen Zustandes drinnenstehen).
Folge: partition failed. Vielleicht die gleiche Ursache?
LG
Max

#8

Hallo Holger,

Das ist - glaube ich - ein anderes Problem.

Das von mir beschriebene lässt sich recht einfach nachvollziehen (auch auf anderen Systemen): man versucht einfach mal „händisch“ eine Partition zu erstellen, deren Label schon existiert. Dann bricht parted mit einer Fehlermeldung ab.
Daher die Idee, alles „bestehende“ vor Beginn der Partitionierung zu löschen. Das will man ja ohnehin (und das war auch ein Workaround für das beschriebene Problem).

Viele Grüße
Thomas

PS: Das meinte ich irgendwann letztens damit, dass man mal irgendwie eine statischere Seite mit Problemen/Lösungen gebrauchen könnte - es flutscht viel durch, wird mit anderem vermischt, etc… Für Kommunikation ist ask super - für Issues/Lösungen/etc. dann doch eher nicht…

#9

Dafür sind die GitHub Issues da :wink:

#10

Hallo Max,

Das von mir beschriebene Problem tritt auch bei einer einwandfreien start.conf auf - das ist ja gerade das Ärgerliche. Nimm eine funktionierende Hardwareklasse und tausche die Labels von zwei Partitionen oder ändere einfach die Partitionsgröße z.B. der ersten Partition. Danach ist die Hardwareklasse kaputt und das Partitionieren schlägt fehl.

Workaround 1: Löschen der Partitionsdaten mit dd
Workaround 2: Umbenennen ALLER Labels zu etwas anderem

Danach geht es wieder.

Viele Grüße
Thomas

#11

Hallo!
Hast Du bei so einer schiefgegangnene Partitionierung mal nach der start.conf auf der cache-Partition geschaut? Die war bei mir dann eben nicht mehr die originale.
LG
Max

#12

Hi @maxEG

Hab ich tatsächlich noch nicht gemacht, muss ich mal nachholen, kann aber gut sein, dass das der Fall ist, das würde auch erklären, weshalb ich nach dem Löschen der Partitionen erst neu starten muss.

VG
Dorian

#13

Hallo Thomas,

Das von mir beschriebene Problem tritt auch bei einer einwandfreien
start.conf auf

… wo ist die start.conf einwandfrei?
Auf dem server oder auf dem Client?

LG

Holger

#14

Hallo Holger,

also kurz gesagt: wenn ich auf dem Server eine Einwandfreie start.conf habe und danach per linbo-remote Rechner starte und partitioniere, dann muss das gehen. Mir wäre da erst einmal egal, ob auf dem Client noch alter Müll liegt oder nicht, das ist doch die Idee des Partitionierens.

Wie es bei der 7 ist, weiß ich nicht. Die 6.2 hat die neue start.conf vom Server (sonst gäbe es ja gar kein Problem, weil er dann nicht „umpartitionieren“ würde). Und da schlägt die Partitionierung dann fehl, weil die Labels „anders“ schon existieren.

Viele Grüße
Thomas

#15

Hallo :slight_smile: ,

Ich glaube, wir reden tatsächlich alle über dasselbe Problem, das sich nur unterschiedlich, bzw. über Umwege äußert:
Wie Holger schon beschrieben hat, scheint Linbo die lokale start.conf zu manipulieren und, dass das partitionieren dann schiefgeht ist ja klar.

Ich sehe das genauso wie @thoschi Linbo darf die start.conf nicht verändern, der Zweck der Sache ist ja, dass der Client überbügelt wird, oder gibt es einen Grund dafür, den ich übersehe?

VG
Dorian

#16

Da das Problem jetzt identifiziert zu sein scheint (zumindest meiner Meinung nach :slight_smile: ) mache ich mal eine GitHub issue auf.
(versuche es vorher nochmal zu reproduzieren)

#17

@dorian

Es gab ja schon ein issue (#136), welches Thomas geschlossen hat. Vielleicht macht es mehr Sinn, das wieder zu eröffnen, wenn seine Lösung das Problem nicht aus der Welt geschafft hat.

Viele Grüße
Thomas

#18

@thoschi

Halte ich nicht für sinnvoll, damals wurde das Problem anders beschrieben und mit deinem Lösungsvorschlag behoben.

EDIT:
Es hat zwar die eigentliche Ursache nicht behoben, aber das scheint mir auch eine andere zu sein als die, die in der Issue beschrieben ist.

#19

Hmm,

also das beschriebene Problem wurde nicht behoben. Das meinte ich ja. Die Labelproblematik ist noch genau so, wie damals beschrieben.
Es wäre aber interessant zu wissen, ob das in der lmn7 nicht mehr auftritt:

  1. funktionierende Partitionierung nehmen
  2. Erste Partitionsgröße ändern, Labels unverändert lassen
  3. linbo partitionieren lassen

Wenn das geht, wäre zumindest das von mir beschriebene Problem nur noch 6.2-spezifisch.

Viele Grüße
Thomas

#20

An sich würde ich das auch so sehen, aber…

linuxmuster besteht ja aus vielen Teilen, die miteinander zusammenhängen und an ganz unterschiedlichen Stellen liegen. Einige haben (gepflegte) Issue-Seiten und eine mehr oder weniger vollständige Dokumentation, andere nicht.

Wenn ich „nur“ an Linbo bastele, würde mir github reichen (da gibt es dann andere Baustellen…).
Aber ganz praktisch laufen die Probleme ja nicht auf Entwicklerebene auf.

Ich glaube, es wäre enorm hilfreich, wenn man irgendwo verbindlicher sehen würde, was gerade an Funktionalität einfach fehlt (und vielleicht auch nicht mehr vorgesehen ist), woran gearbeitet wird (vielleicht auch von wem) oder welche Workarounds/Lösungen es gibt. Eine Seite die dann auch Ausgangspunkt für Funktionalitätsprobleme ist, die nachweisliche mehrere Leute betreffen und die das Problem aus dem „ask-Sumpf“ an einen sichtbareren Ort hebt. Von dort kann natürlich auf Issues verwiesen werden.

Im jetzigen Zustand haben wir einfach Unmengen an grob sortierten ask-Threads, wo über viele Wochen oder Monate an einem Problem herumgedoktort wird und man weiß zu keinem Zeitpunkt, wie eigentlich der Stand ist (Beispiele: v7-Linux-Client, v7-Mischbetrieb Windows-Linux, …). Und dann ist es ja noch so, dass das oft noch völlig entkoppelt von den Entwicklern läuft (um diese nicht zu belasten).