Siduction Forum

BUGS => Archiv Bugs => 2012.1 => Topic started by: michaa7 on 2012/05/23, 12:23:24

Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/05/23, 12:23:24
I downloded the i386 xfce and i386 lxde. update-grub creates strange not working entries for both, there is an additional ";1" which prevents both isos from booting:

Quote
menuentry "siduction-12.1-desperado-lxde-i386-201205212227 (vmlinuz0.686;1)" {
        insmod iso9660
        insmod part_msdos
        insmod ext2
        set root='(hd1,msdos9)'
        search --no-floppy --fs-uuid --set=root 1cadc53c-13b1-4b5a-81eb-a01fc22ce007
        loopback loop /sidon/siduction-12.1-desperado-lxde-i386-201205212227.iso
        linux (loop)/boot/vmlinuz0.686;1 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 fromiso=/sidon/sidu$
        initrd (loop)/boot/initrd0.686;1
}
menuentry "siduction-12.1-desperado-xfce-i386-201205212237 (vmlinuz0.686;1)" {
        insmod iso9660
        insmod part_msdos
        insmod ext2
        set root='(hd1,msdos9)'
        search --no-floppy --fs-uuid --set=root 1cadc53c-13b1-4b5a-81eb-a01fc22ce007
        loopback loop /sidon/siduction-12.1-desperado-xfce-i386-201205212237.iso
        linux (loop)/boot/vmlinuz0.686;1 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 fromiso=/sidon/sidu$
        initrd (loop)/boot/initrd0.686;1
}
menuentry "siduction-pontos (2.6.27-10.slh.1-sidux-686)" {
        insmod iso9660
        insmod part_msdos
        insmod ext2
        set root='(hd1,msdos9)'
        search --no-floppy --fs-uuid --set=root 1cadc53c-13b1-4b5a-81eb-a01fc22ce007
        loopback loop /sidon/siduction-pontos.iso
        linux (loop)/boot/vmlinuz-2.6.27-10.slh.1-sidux-686 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 $
        initrd (loop)/boot/initrd.img-2.6.27-10.slh.1-sidux-686
}
### END /etc/grub.d/60_fll-fromiso ###


Worked fine for all RCs (finaly). As you can see, the entry for an old pontos image does not have this additional  ";1" and boots fine.

After manually removing ";1" in grub.cfg, the xfce iso boots,  the lxde does not, it stopps at:

...
starting init process...
Target file system doesn't have requested /sbin/init
No init found
...

Both md5 sums are ok!
Title: (partly solved) all releases not booting ...
Post by: midrow on 2012/05/26, 20:01:07
I confirm the described behavior for the i386 KDE iso:

a) Only the desperado iso gets the additional ";1" by fll-fromiso.

b) The booting process stops with the following messages:
Code: [Select]
Mounting aufs union filesystem...
Preparing live filesystem on /root...

Starting init process...

_
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/05/29, 16:07:21
same goes for 12.1.5.rqt.

Is there really noone else (exept midrow) having this problem?

I moved the isos to /srv, still the same.
So this seems not related to strange path/Label/UUID combinations. What is / seems so special in my environment that makes  /etc/default/grub2-fll-fromiso behaving so strange?

No hint, no interest in solving this problem?
Title: (partly solved) all releases not booting ...
Post by: devil on 2012/05/29, 16:15:31
I have not used fromiso in years, so no clue really, sorry.
It's too muh work for my taste.
But we are looking into it.

greetz
devil
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/05/29, 16:56:50
Quote from: "devil"
I have not used fromiso in years, so no clue really, sorry.

So you using isos from usb-stick only?
Quote
It's too muh work for my taste.

I do not understand. With Grub2 you configure it once and your done for ever (if it works as expected). So it's less work than dd it on an stick.
Quote
But we are looking into it.

Thxx.

One observation of which I don't know wether it is related or not:
It's the naming of the kernel. IIRC in RC you used a real name and version  for the kernel (in .../iso/boot/<kernel> ; was booting and ffl-fromiso didn't create this additional ";1"), with the release you changed to ".../iso/boot/vmlinuz0.686" (not booting and ffl-fromiso does create this additional ";1").
This does not happen with an old pontos.iso from this other distro. This indicates, AFAICS that it's the iso, not the hw or its config.

I do not really need a working iso although I prefere it over booting a CD if I need a second system for maintance. So I mainly tested the ISOs out of curiosity ( I am fine with my siduction-fluxbox installation ). But as long as you ship ffl-fromiso it should work, I think.
Still wondering how few people seem to use it (given that only one other person reports this problem).
Title: (partly solved) all releases not booting ...
Post by: dibl on 2012/05/29, 17:06:35
Quote from: "michaa7"

Still wondering how few people seem to use it (given that only one other person reports this problem).


I dd'd siduction 12.1RC to a 2GB USB stick.  It took more time to look up the dd command than it took to run it, and it took more time for the writing on the USB stick than the first two steps took.  Probably total time for the task was 5 minutes.
Title: EDIT 1
Post by: michaa7 on 2012/06/05, 16:53:15
[en]

The new grub2-fll-fromiso version shows positiv and  negativ changes:

+
The additional ";1" is gone

-
The fromiso path now is wrong. Grub cannot handle a path over more than one partition. I Grub2 a path like "/media/disk1part5/sidon/foo.iso" is condemned to failure.

The older version did handle this correctly (see first post here), the newone does not:
Quote
linux (loop)/boot/vmlinuz0.686 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 fromiso=/media/disk2part9/sidon/siduction-12.1-desperado-xfce-i386-201205212237.iso ...


EDIT 1
After editing the path in both lines, grub kann begin to boot the images. xfce boots successfully, rqt still fails and frezzes the system after "start init" . It seems to panic as I can see blinking diodes on my keyboard.

[/en]


Mit der neuen grub2-fll-fromiso gibt es zwar veränderungen, jedoch sowohl zum positiven als auch zum negativen:

+
Das zusätzliche ";1" taucht nicht mehr auf

-
Der fromiso pfad wird nun falsch zusammengesetzt (was vorher richtig war). In grub sind nur pfade möglich, die innerhalb *einer* partiton liegen, pfade über partitonionsgrenzenb hinweg kann grub nicht verstehen. Daher ist eine pfadkonstruktion wie sie die neuen version von grub2-fll-fromiso nutzt nicht richtig, weil im pfad "/media/disk1part5/sidon/foo.iso" der pfadteil /"media/disk1part5/" auf einer anderen partiton liegt wie "sidon/foo.iso".

Die ältere version hat dies richtig umgesetzt (siehe mein erstes posting) die neue version (0.3.0) macht dies falsch:
Quote
linux (loop)/boot/vmlinuz0.686 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 fromiso=/media/disk2part9/sidon/siduction-12.1-desperado-xfce-i386-201205212237.iso ...
is condemned to failure.

The older version did handle this correctly (see first post here), the newone does not:
Quote
linux (loop)/boot/vmlinuz0.686 fromhd=UUID=1cadc53c-13b1-4b5a-81eb-a01fc22ce007 fromiso=/media/disk2part9/sidon/siduction-12.1-desperado-xfce-i386-201205212237.iso ...


[/en]


Mit der neuen grub2-fll-fromiso gibt es zwar veränderungen, jedoch sowohl zum positiven als auch zum negativen:

EDIT 1

Nach editieren des pfades in den beiden betreffenden zeilen bootet xfce erfolgreich, rqt beleibt nach "start init" hängen. Die blinkenden lichter auf meiner tastatur sowie der komplette freeze des rechners deuten auf eine panic hin.
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/05, 19:32:57
kurze Zusammenfassung: In einem Bugtracker würde ich jetzt declined und wont fix ranmalen. Und hier werde ich es genau so halten.

Mit anderen Worten: Wenn das Verhalten von isoinfo nicht genehm ist, dann bitte einen Bug in den Upstream malen. Wir haben nur das ;1 entfernt. Ist zwar auch ein dreckiger Hack inspieriert von mc, aber was solls. Am Zusammenschrauben irgendwelcher Pfade wurde nichts geändert. Wer Lust hat, sich um eine mögliche Lösung bemühen: Das Script findet man nach Installation des Pakets ungefähr hier: /etc/grub.d/60..

Eine Alternative ist halt das manuelle Editieren der entsprechenden Grubeinträge und eine eventuelle Verlagerung der fertigen Einträge in eine eigene Datei innerhalb von /etc/grub.d

Wenn sich bestimmte Rückmeldungen von isoinfo je nach der Version des verwendeten Buildsystems ändern und das durch jemanden nachvollziehbar ist: Bitte die Bugs an Upstream, stromabwärts werden denkbare Lösungen immer dreckiger.
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/05, 23:11:31
... was heißt denn hier "genehm"?

Willst *du* dass ein paket aus dem siduction repo funktionniert oder ist dir ein nicht funktionierendes "genehm"? Möchtes du dass bugs in siduction paketen zukünftig berichtet werden oder sind dir tester die das maul halten "genehmer"?

Und es besteht schon ein unterschied zwischen "can't fix" zu "won't fix".
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/05, 23:24:56
Und es bleibt dabei: Es ist ein simples Shell-Script. Bei mir taucht der Fehler nicht auf, also kann ich nichts analysieren. Wenn Du willst, das sich was ändert: Selbst ist der Mann, wir freuen uns über fundierte (!) Analysen und mögliche Bugfixes von Deiner Seite.
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/05, 23:41:38
Bootest du überhaupt fromiso?

Welcher fehler taucht nicht auf?

- Das zusätzliche ";1"? (wie bist du den losgeworden?)
- Das überzählige pathfragment? (echt, wo liegt das iso bei dir?)
- der boothänger von rqt? (nunja, das könnte wirklich mit isoinfo zu tun haben, der rest wohl kaum)

Trotzdem waren deine wenigen zeilen informativer als dein vorheriges posting!

Neue Bugreport policy: bugreports bitte nur noch mit lösung senden?
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/06, 00:09:13
;i- http://git.siduction.org/?p=packages/siduction-repository/grub2-fll-fromiso.git;a=commitdiff;h=87a24d2cd09a7e2fbcab55f7c8bbc298a20a7d92

übrigens in Teamarbeit und nach ausführlicher Analyse.

- ich habe keine Fragmente. siduction liegt auf sda2, die isos gammeln in meiner Archpartition (sda1), da ich grub-fll-fromiso auch mit einer minimalen Änderung in Arch nutze. bei interesse hier mal ein Paste, ist ein wenig unordentlich auf die schnelle, war zur Analyse: http://pastebin.com/7Snd4AUX

- du siehst ein jailbreak-rqt - also ein razor mit neuer Namensgebung. Gründe für die Änderung des Releasenamens siehe Forum, jailbreak ist mein privater Build ohne offiziellen Namen.


BTW: ich habe meine Isos schon aus reinem Spass an der Freude auf LVMs geleget oder auch auf nackte Raids. Bis auf die Tatsache, dass die Modulerkennung nicht wirklich rockstable ist, funktionierte das selbst in Fällen, in denen ich ein Funktionieren als recht unwahrscheinlich erachtete, im Rahmen des Zustands von grub recht stabil.

Noch ein Punkt: Wenn Du willst, dass Deine Bugs noch mehr Beachtung finden - wir haben einen öffentlichen Bugtracker. Ist recht einfach zu bedienen und eine ganz sinnvolle Einrichtung. Und vollständige Informationen wären für uns auch wichtig. Und wenns nur fragmentarisch ist wie mein paste. Wenn was fehlt, würde der Bugtracker der bessere Ort für so was sein, da lassen sich komplexere Vorgänge besser drin darstellen.
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/06, 00:45:52
die nützlichste info war bisher, dass andere (z.b. du) diese "media/diskXpartY/" fragmente nicht haben (wenn ich dich richtig verstanden habe, naja ergibt sich eigentlich aus blkid -o list vs. ... ups, nee nee, statt der geposteten, wie auch immner gestrickten "/etc/grub.d/10_isos" würde ich schon gerne die "/boot/grub/grub.cfg" sehen).

Diese info wäre schon vor wochen interessant gewesen, weil es ja nahe legt, dass es in meinem system irgenwelche besonderheiten, vielleicht in der fstab gibt, was schonmal fromiso-boot probleme verursachte.

Bist du denn sicher, dass du mit deiner nicht standard konfigurtation mein problem überhaupt nachvollziehen kannst?

Zeig bitte mal deine siduction /etc/fstab und deine /boot/grub/grub.cfg
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/06, 02:55:35
Du bist dir wirklich sicher, den Paste gelesen zu haben:
* erstes listing ist die liste der Blockdevices. Die ist ganz nett, weil da die uuids drin reingemalt sind, die man braucht, um die /boot/grub/grub.cfg lesen und interpretieren zu können.
* zweites File in dem Listing: etc/defaults/grub2-fll-fromiso - mit diesen Setting generiere ich.
* ich hab die Anfänge der Files markiert, das lange ding, was Du angemäkelt hast, ist die grub.cfg.
* ich bezweifele, dass das umbenennen eines scripts von 60_grub2-tralala nach 10_tirili irgendetwas ändert. Um dieses Verhalten auszuschließen sind aber in meinem System 2 Erstellungsscripte vorhanden. 10 und 60. Die Auswirkungen sieht man recht deutlich in der grub.cfg.
* ich weiss zwar nicht, welche Informationen Du der fstab entnehmen willst, aber seis drum: http://pastebin.com/nxz9sUPk

Zu Deiner letzten Frage: Nö, ich bin mir nicht sicher, dass ich mit meiner Konfiguration Deine Probleme nachvollziehen kann. Abgesehen von homöopathischen Eingriffen in die Konfiguration ist der Rechner unverfrickelt und am Wochenende neu aufgesetzt. Und zwar nachdem ich grub2-fll-fromiso debuggt, gebaut, hochgeladen und getestet habe. Meinen Rechner habe ich dann ohne Probleme mit den auf Arch liegenden Isos installiert.

Um einer Frage zuvorzukommen: Ja, ich denke, ich weiss relativ genau, was ich getan habe und warum das Script funktioniert. Und ich wiederhole mich recht ungern: Bei Dir läuft das Script anders als bei anderen. Das sollte aber auch kein Beinbruch sein, dann macht man es auf der Maschine, auf der es nicht nachvollziehbare Ergebnisse bringt, halt ein wenig gesprächiger. Testen ist dann relativ einfach

Code: [Select]

su
cd /etc/grub.d
bash 60...
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/06, 14:51:49
[en] in short:
changing iso mountpoints in /etc/fstab and path in grub2-fll-fromiso will not suffice if you forget to unmount from the old mountpoint before you mount the newone. The fll-script gets confused if it founds  the iso partition mounted on diffrent MPs. It will not be able to stripp the path correctly (presumably if it founds the oldone first!).

After correcting this the path now gets created as it should.
 
xfce boots completely, rqt begins to boot, but fails after "starting init process" with panic. md5sum ok.


[/en]

Quote from: "agaida"
Du bist dir wirklich sicher, den Paste gelesen zu haben:


Jain, vor lauter 60_grub2-tralala ist mir die markierung von boot/grub/grub.cfg beim lesen wohl durchgeflutscht. Danke für deine geduld.

Der fehler, soweit es die überzähligen pathfragmente betrifft ist aufgeklärt:

Nach installation der neuesten grub2-fll-fromiso hatte ich sofort update-grub ausgeführt und bei kontrolle der resutierenden boot/grub/grub.cfg bemerkt, dass nun also das ";1" nicht mehr auftaucht. Auf den pfad, der rückwirkend betrachtet zu diesem zeitpunkt vermutlich richtig war - ohne überzählige pathfragmete - hatte ich nicht geachtet. Ich wollte sofort sehen, ob es nun auch klappt, wenn die die iso enthaltente partiton statt nach "media/diskXpartY" nun nach /dtn/<Label> gemounted wäre. Also /etc/fstab geändert (daher die nachfrage nach deiner fstab), entsprechend den pfad in grub2-fll-fromiso angepasst, partition gemountet, aber leider vergessen vorher diese partition aus dem alten mountpunkt auszuhängen ... das kann das script nich ab.
Draufgekommen bin ich erst, als ich nach allerlei änderungen der mountpoints und pfade feststellte, dass nun der pfad richtig konstruiert wurde. Über "cat /etc/mtab" und lesen des fll-scripts (auch wenn ich es nicht vollständig verstehe) ist mir dann gedämmert wo der hase im pfeffer liegen könnte ... oder müsste.

In soweit ist das problem mit grub2-fll-fromiso gelöst, für den falschen pfad war ich selber verantwortlich.


Davon unabhängig scheint jedoch das problem zu sein, das rqt beim booten nach "starting init process" panikt (im gegensatz zu xfce, was normal durchbootet) und nur durch nen hard resett erlöst werden kann. Darauf bezog sich vermutlich dein hinweis bezüglich isoinfo?
Jedoch ist dazu dein setup mit dem jailbreak-rqt nicht mehr so ganz die richtige testumgebung zur bestätigung oder ausschluß von fehlern. md5sum ist ok, und soweit nicht andere hinweise kommen ist für mich hier feierabend.media/diskXpartY
Title: (partly solved) all releases not booting ...
Post by: midrow on 2012/06/06, 17:40:08
Quote from: "michaa7"
Davon unabhängig scheint jedoch das problem zu sein, das rqt beim booten nach "starting init process" panikt (im gegensatz zu xfce, was normal durchbootet) und nur durch nen hard resett erlöst werden kann.
Ich bin mir sicher, das das Nicht-Starten-Problem unabhängig von der (inzwischen gelösten) ffl-fromiso-Geschichte ist!
Nochmal der Hinweis: Der Rechner hängt bei mir (nach "Starting init process...") beim Starten der i386-KDE-Iso!

[English]
I'm sure, that the no starting problem is independent from the fll-fromiso issue (which is solved in the meantime)!
Once more my hint: My box get stuck (after "Starting init process...") booting a i386 KDE iso!
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/06, 18:49:26
@midrow: Du liegst mit Deiner Vermutung richtig. Hab Deinen Beitrag nur zu spät gesehen und keinerlei Böcke, das Folgende umzumalen.

@michaa7
Doch, isses. Ich bin nur heilefroh, dass sich das mit den Fragmenten in Wohlgefallen aufgelöst hat. Die Bewandnis hinter jailbreak ist, dass ich die Steuerung für razor durchgängig umbenamsen musste. Und Jailbreak war halt auf der Setlist der Razors Edge Tournee. Der Mensch ist halt ein visuelles Wesen, also kommt es beim debugging nicht gut, wenn Releasename und flavour einen ähnlichen oder ansatzweise gleichen Namen haben. Das stiftet Verwirrung.

*Doch isses II* :twisted: nicht nur razor panict unter gewissen Umständen, auch die anderen Flavours. Daher ist es ganz nett, mit der jailbreak ein Iso gehabt zu  haben, was keine Kernel-Panic hervorruft. Auch hier liegen die Dinge wieder anders, als erwartet. Alle Isos, die unter debian nicht laufen, starten unter Arch einwandfrei. Towo und meine Wenigkeit haben unsere Glaskugeln befragt und sind zu dem Ergebnis gekommen, dass ingenieurtechnisches Vorgehen unsere beste Möglichkeit ist. Da die Jailbreak zu einem wesentlich späteren Zeitpunkt als das Release gebaut wurde, könnte es sein, das ein Neubau ohne jegliche Änderung irgendeiner Konfiguration schon die gewünschte Problemlösung bring. Auch wenn es gern vergessen wird, siduction bleibt sid. :)
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/06, 19:03:35
Quote from: "agaida"
...Alle Isos, die unter debian nicht laufen, starten unter Arch einwandfrei. ...


Grub startet doch das iso, nicht irgendein Linux. Was also meinst du also damit technisch gesehen? Redest du hier vom starten in VMs unter Debian bzw. Arch?
Title: (partly solved) all releases not booting ...
Post by: towo on 2012/06/06, 19:04:50
Nein, Grub startet kein ISO!
Das einzige was Grub macht, es looped das iso, damit daraus Kernel und initrd geladen werden kann.
Title: (partly solved) all releases not booting ...
Post by: michaa7 on 2012/06/06, 19:16:09
Gut, ok, aber was heißt dann "unter Debian" bzw "unter Arch"? Die sind an dem loopen des isos ja nicht beteiligt.
Title: (partly solved) all releases not booting ...
Post by: agaida on 2012/06/06, 21:36:49
unter siduction oder debian oder arch heisst: ich verwende die Version des Grubs, die das jeweilige Release oder die Distribution mitbringt.

Und die unterscheiden sich halt ein wenig. Und der Spass an der Sache ist, dass mit der Version 2 beta 4 oder so in Arch: Mit diesem Grub starten die ISOs, die unter dem Grub, der mit Sid geliefert wird, Probleme bereiten. An diesem Fakt ändert auch das Kritteln an eventuell missbräuchlicher Verwendung der deutschen Sprache nichts. :twisted:

Und da wir mit dem Rotz schon eine Zeit lang zu tun haben und es immer unglaublicher wird, ist unsere Stimmung bei diesem Thema nicht die beste. Seis drum, wir haben den nicht unbegründeten Verdacht, dass sich die Startprobleme mit ziemlicher Sicherheit auf das Thema Grub reduzieren lassen. Und wenn wir ganz großes Glück haben, lösen sich die Probleme genau so, wie sie gekommen sind - von selbst.

Da es aber recht unverantworlich wäre, sich allein auf Glück zu verlassen, haben wir die ein oder andere Stunde in das Thema gesteckt. Towo wahrscheinlich mehr als ich, ich würde schätzen, es kommen ein paar Manntage zusammen. Positiv ist, dass wir alle möglichen und unmöglichen Trivialfehler ausgeschlossen haben. Negativ ist, dass die Suche mit jedem ausgeschlossenen Trivialfall komplexer wird und mehr ans Eingemachte geht.