(partly solved) all releases not booting ...

[michaa7]

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:

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!

[midrow]

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...

_

[michaa7]

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?

[devil]

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

[michaa7]

I have not used fromiso in years, so no clue really, sorry.

So you using isos from usb-stick only?

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.

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).

[dibl]

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.

[michaa7]

[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:

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:

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:

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.

[agaida]

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.

[michaa7]

... 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".

[agaida]

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.

[michaa7]

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?

[agaida]

;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.

[michaa7]

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

[agaida]

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...


[michaa7]

[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]

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