Hallo 
,
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
Da das Problem jetzt identifiziert zu sein scheint (zumindest meiner Meinung nach ) mache ich mal eine GitHub issue auf.
(versuche es vorher nochmal zu reproduzieren)
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
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.
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:
Wenn das geht, wäre zumindest das von mir beschriebene Problem nur noch 6.2-spezifisch.
Viele Grüße
Thomas
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).
Konnte es soeben unter LMN7 mit den neusten stable Paketen reproduzieren.
Hmm… du meinst quasi eine Art Zusammenfassung der GitHub Issues auf eine Art und Weise, die auch für nicht - Entwickler gut einsehbar ist?
Klar, das ist sinnvoll, solange das Problem untersucht wird. Sobald aber klar ist, was das Problem ist, sollte es meiner Meinung nach trotzdem in einer GitHub Issue festgehalten werden, weil so verlieren es die Entwickler nicht aus dem Blick.
Ich glaube das ist auch der Grund, dass bei deiner Issue #136 nix mehr passiert ist: Du hast sie nicht wieder aufgemacht, also ging Thomas vermutlich davon aus, dass das Problem behoben ist. (Will mich da nicht einmischen, sorry)
VG
Dorian
Probiere ich gleich aus
EDIT:
Läuft problemlos durch.
Genau - für die Teilprojekte ist Github ja perfekt (sowohl für eine Entwicklerdoku als auch die Issues). Aber ich glaube, es fehlt da auf Projektebene oft und vielen der Überblick.
Also eine Art Projekt-Github (gibt es ja eigentlich schon) oder ein Ticketsystem mit Versionierung (redmine, …) für das Projekt. Wo ich einen guten Überblick über den Stand bekomme und was ausgehend von den ganzen Diskussionen gepflegt wird.
Das wäre auf jeden Fall ein guter Anfang
Ich hab jetzt mal eine Issue auf gemacht, auch wenn das #136 Problem noch da ist, ist es meiner Meinung nach ein anderes Thema
Hast Du bei Dir auf dem Client in /usr/bin/linbo_cmd die dd-Zeile:
dd if=/dev/zero of=$disk bs=512 count=1 || RC="1"
Dann wäre das Problem ja behoben (und eben einfach nicht mehr zur 6.2 runtergewandert).
Jap, die habe ich.
Danke! Wäre dieser Teil geklärt
Hallo Thomas,
Dann wäre das Problem ja behoben (und eben einfach nicht mehr zur 6.2
runtergewandert).
das stimmt so nicht. Thomas hat die gleichen Versionen von linbo 2.3 für
die lmn7 und die lmn6.2 gemacht.
Bei der 6.2 ist es aber aus dem testing noch nicht raus, weil einfach
keine Leute das getestet haben (oder halt nicht zurückgemeldet haben).
Die 6.2 user würden sich ja auch nicht freuen, wenn die Pakete in der
6.2 ungetestet veröffentlicht werden mit dem HInweis: in der 7 läuft es.
Also: Testen, Rückmelden, und dann wandert das auch dort in stable.
Ich bin Thomas total Dankbar, dass er sich die Arbeit macht für die 6.2.
Normalerweise hab ich das halt getestet: aber ich hab jetzt halt seit
1,5 Jahren die 7 in der Schule und nicht die 6.2: also gibt es ein
„Testerloch“.
LG
Holger
Hi zusammen,
Ich hab die Stellen gefunden, an denen die start.conf verändert wird:
Hier wird es angestoßen
Und hier wird es dann durchgeführt:
Ich verstehe aber immer noch nicht, WARUM das gemacht wird 
VG
Dorian
Hallo Holger,
Dann werde ich das gerne mal testen (wobei ich lieber heute als morgen zur v7 wechseln würde.
Wobei ich vielleicht abwarte, bis das neue Issue, das Dorian erstellt hat, geschlossen wird. Da scheint es ja gewisse Überschneidungen bei den Problemen zu geben.
Viele Grüße
Thomas