staging.inyokaproject.org

IAM-AT schrieb:

Wie von mir in meinen posts oben sachlich nachvollziehbar ausgeführt, liefert das Wiki zwar einen Warnhinweis ganz zu Anfang, doch muss man sich schon ganz schön reinarbeiten,

Ja, ein Wiki bedarf einer ghörigen Portion verstehenden Lesens, anders als eine Kurzanleitung.

um die von mir o.g. Unstimmigkeiten überhaupt erst mal zu finden,

Ja ich zum Beispiel kann gar keine Unstimmigkeiten finden.

Ich habe gezielt diesen Weg in diesem Wiki gewählt, weil ich anderen diese Mühe ersparen will. Zugegeben support war auch mit enthalten, doch das eigentliche Problem wurde nicht von Euch gelöst, sondern liegt bei den Entwicklern von grub2.

Das glaube ich nicht. Auch der Eintrag in diesem Forum enhält einen Fehler. Weil du als Namen des Iso nur den Pfad zugewiesen hast, jedoch nicht den Namen des Iso.

Ich gebe zu, dass es nicht immer ganz einfach ist, so einen komplexen Vorgang, wie das Einbinden einer ISO-Datei zu verstehen. Auch ich habe eine Weile gebraucht, bis ich das kapiert habe, vor allem auch, weil eben der Einsatz der verschiedenen Variablen etwas verwirrend sein kann. (Und ich behaupte nicht, ich wüßte wie es funktioniert: Aber ich kann einen solchen Eintrag erfolgreich erstellen 😉 )

Allerdings deine Unkenntnis jetzt dem Wiki und den Grub2 Entwicklern zuzuschieben, halte ich für ziemlich arrogant.

ok, ich muss zugeben, ich war etwas genervt und habe zu wenig hervorgehoben, dass die englischen und deutschen ubuntu WIKIs sehr hilfreich sind, ehrlich gesagt sogar mein erster Anlaufpunkt. Mag sein, dass meine von mir als konstruktiv gedachte Kritik als arrogant empfunden wurde, was mit leid tut. Es lag nicht in meiner Absicht, Eure wertvolle Arbeit zu entwerten.

Weil aber geschrieben wurde, dass ich "wirr" schrieb, im folgenden Absatz noch mal der Versuch einer Erläuterung für alle die an Rechthabereidiskussionen interessiert sind. Der an diesen Absatz anschließende Absatz ist dann aber wieder wichtig. Mein Punkt zielte auf die Historie des deutschen grub2 skripte Wiki ab. D.h. alter Weg über custom 40 und 41 und nun über 10_eigenes Skript. Ich meine mich zu erinnern, dass das Skripte Wiki vor 1-2 Jahren auch noch eher den Fokus auf die 40 bzw. 41 custom Skripte in /etc/grub.d/ setzte. Fehlt dieser Bezug, führt dies -zumindest bei mir- zu dem Eindruck der Inkohärenz, weil fehlende "historische" Bezüge weggefallen sind, an die ich hätte anknüpfen können.

Wichtig erscheint mir jetzt jedoch vielmehr, dass erstens, neben dem Betastadium von grub2 auch noch zweitens, die unterschiedlichen Konzepte der Initrd's (Initialen Ramdisks) zu Startproblemen wie z.B. panic oder "/sbin/init not found" Abbrüchen führen. Drittens wäre dann noch die Rolle des BIOS ( UEFI oder legacy ) zu nennen.

Von einige Initrds (initrd.img, initrd64.img, initrd.lz, minirt.gz, initramfs-grsec etc.), die in aktuellen Distros sowie deren Live Versionen enthalten sind, booten einige trotz kleiner Fehler in den cheatcodes bzw. kernel Paramtern ( kubuntu, Parted-Magic, Slax), andere wiederum, obwohl ich in den grub2-Skripten alles penibel überprüft habe (Knoppix, Slitaz, Puppy, Slacky, Alpine) nicht. :-\

Kurzum, auch hier gibt es -aus meiner laienhaften Sicht- keine Regelmäßigkeiten. Mal geht's mal nicht. Liegt es nur an mir? Oder evtl. auch an grub2 oder an den initrds oder am BIOS?

Das wir uns nicht falsch verstehen, die live iso's von allen o.g. Distros lassen sich wunderbar in Virtualbox starten, nur eben nicht realiter auf meinem Notebook via grub2. Und das Notebook hat schon das neueste Firmware udpate drauf.

hier gibt es keine Regelmäßigkeiten

Vollkommen richtig.

Das loopback-Feature von Grub ist reine Augenwischerei. Das Feature ist komplett unnötig. Du kannst das gleiche auch mit jedem anderen Bootloader machen der kein loopback-Feature hat.

Der einzige Unterschied ist dieser: Grub kann Kernel und Initrd direkt aus der ISO herausziehen. Bei einem anderen Bootloader müsstest du die ISO selbst mounten und Kernel+Initrd als eigenständige Dateien auf die Bootpartition legen.

Das ist alles. Wenn der Bootloader den Kernel und das Initrd geladen und Kernelparameter übergeben hat, dann ist er fertig.

Die eigentliche Magie findet dann erst später statt: Das Initramfs schaut sich die Kernelparameter an. Das heißt jetzt zwar Kernelparameter, aber vom Kernel selber werden diese iso-scan-Geschichten gar nicht interpretiert. Das sind frei dazuerfundene Parameter die vom Initramfs vielleicht interpretiert werden, vielleicht auch nicht.

Ein Initramfs ist (in der Regel) nur ein Shellscript. Und da nutzt jede Distribution, jede LiveCD, ein anderes. Und jedes kann anders arbeiten, andere Parameter verstehen, ... ergo keine Regelmäßigkeit, jeder kocht sein eigenes Süppchen. Manche ISOs können alle Partitionen nach einer Datei abklappern. Manche wollen den Gerätenamen und Pfad direkt genannt haben. Manche können das überhaupt nicht und unterstützen damit gar keinen loopback-Boot.

Wenn du die zum loopback-Boot nötigen Parameter einer ISO nicht schon kennst, dann musst du sie suchen. Entweder mit Google (wenn ein anderer sich die Arbeit schon gemacht hat) oder eben selbst. Initramfs auspacken, Script lesen, ...

Bei mir sieht das im Moment so aus: https://bpaste.net/show/0fd09f8087b8

frostschutz schrieb:

Wenn du die zum loopback-Boot nötigen Parameter einer ISO nicht schon kennst, dann musst du sie suchen. Entweder mit Google (wenn ein anderer sich die Arbeit schon gemacht hat) oder eben selbst. Initramfs auspacken, Script lesen, ...

Wenn die entsprechende CD/DVD Isolinux zum starten benutzt, kann man auch vorher im ISO im Verzeichnis /isolinux nachschauen, mit welchen Parametern dort das initramfs aufgerufen wird. Andererseits habe ich eben auch festgesetllt, dass ISO-Dateien, die per loop auf meinem Rechner nicht starten auch als CD nicht zu starten sind.

lionlizard schrieb:

kann man auch vorher im ISO im Verzeichnis /isolinux nachschauen, mit welchen Parametern dort das initramfs aufgerufen wird.

Ja. Da stehen die Kernelparameter die die CD sonst so verwendet, und die man also auch ins Grub übernehmen sollte.

Aber der isoloop-Parameter steht da normalerweise nicht dabei, da das isolinux diese ja nicht braucht. Das ist dann so wie die echte CD bootet.

Vielen Dank @Frostschutz.

Auf die Idee muss man auch erst einmal kommen. Einfach nicht die neueste KNOPPIX Version 7.4 herunterladen, sondern so wie bei Deiner grub.cfg die CD Version 7.2. Funktioniert super. Einziger Nachteil, im neuen Kernel sind noch nicht die neuesten LAN Treiber implementiert, was bei einem LIVE Image dann natürlich Probleme mit sich bringt.

Dennoch ist das wirklich ein guter Schritt voran für mich. Danke nochmals.

@alle anderen: das würde ich auf jeden Fall als Tipp auch ins Wiki schreiben, bevor mensch sich graue Haare wachsen lässt. 😉

IAM-AT schrieb:

@alle anderen: das würde ich auf jeden Fall als Tipp auch ins Wiki schreiben, bevor mensch sich graue Haare wachsen lässt. 😉

Hier schreibst du noch, das würdest du nicht:

😉 wäre eine gute Beschäftigungsmaßnahme, doch fühle ich mich weder kompetent genug, noch habe ich die zeitlichen Ressourcen,…

Aber man kann ja seine Meinung ändern. 😉

frostschutz schrieb:

Das loopback-Feature von Grub ist reine Augenwischerei. Das Feature ist komplett unnötig. Du kannst das gleiche auch mit jedem anderen Bootloader machen der kein loopback-Feature hat. ... Wenn du die zum loopback-Boot nötigen Parameter einer ISO nicht schon kennst, dann musst du sie suchen. Entweder mit Google (wenn ein anderer sich die Arbeit schon gemacht hat) oder eben selbst. Initramfs auspacken, Script lesen, ...

Bei mir sieht das im Moment so aus: https://bpaste.net/show/0fd09f8087b8

Ggf. sollte man dies im wiki genauer hervorheben: dass das Booten mit loopback von einer ISO Datei nicht einfach intuitiv lösbar ist sondern nur mit den richtigen Optionen funktionieren kann aber nicht muss. Und das ggf. jede ISO Datei anders ist, und damit u.U. ein anderes grub2 loopback Script benötigt.

Viele Grüße u1000

u1000 schrieb

Ggf. sollte man dies im wiki genauer hervorheben: dass das Booten mit loopback von einer ISO Datei nicht einfach intuitiv…

Es geht ja in erster Linie um die ISO-Dateien von *buntu. Und damit funktioniert das loopback, wenn man es richtig macht und sich an die Vorgaben hält. Und ohne das jetzt überprüft zu haben, bin ich sicher, dass auch die im Beispiel angeführte Version des Parted Magic Images funktioniert, wenn man es richtig macht.

IAM-AT macht Fehler in seinen Einträgen und lastet diese grub an.

Grub sucht nicht automatisch nach den nötigen Starteinträgen in einem ISO um dieses dann zu starten. Ob man es deswegen als reine Augenwischerei bewertet, ist Ansichtssache.

Ich finde das Loopback-Feature von Grub nicht weniger intuitiv als das Programm insgesamt, und halte es für übertrieben, das hervorzuheben. Da gibt es m.E ganz andere Kandidaten, die im WIki weit intuitiver erscheinen, als sie in Wirklichkeit sind (ich denke da z.B. an LVM.)

lionlizard schrieb:

IAM-AT macht Fehler in seinen Einträgen und lastet diese grub an.

+1

Das hatte ich ja auch schon mehrfach versucht klar zu stellen - wurde jedoch als arrogante Einmischung abgebügelt. Auf das Erstellen einer Supportanfrage warte ich diesbezüglich immer noch!

Und mit den richtigen Kerneloptionen funktioniert das auch einwandfrei mit "PartedMagic" (mit letzter, kostenloser Version 2013_08_01 verifiziert). Und klar ist auch, diese haben sich zu denen im WIKI geändert - nur dass kann man in keinem WIKI aktuell halten - wir haben noch Anderes zu tun (wieder arrogant 😳 ).

Und nun auch das noch: Es funktioniert, so wie es ist, sogar unter einem EFI Bootmanagement → nur ohne secure-boot!

Also ich finde man sollte die Kritik IAM-AT nicht einfach damit abtun, dass er sie falsch begründet hat.

Das Wiki sollte dazu dienen, dass derjenige der es liest, das Thema bzw. die Aufgabe lösen und nachvollziehen kann. IAM-AT lastet die Fehler die er gemacht hat fälschlicherweise GRUB 2 an, ja, aber dahinter steckt doch auch, dass er aus dem Artikel bzw. dem Abschnitt nicht schlau geworden ist.

Und das ist IMO nachvollziehbar, denn der Abschnitt enthält einfach nur zwei Beispiele. Was hier IMO noch hilfreich wäre ist, dass man am Anfang des Abschnitts eine allgemeine Erklärung liefert, was für Einträge man für ein Loopback-Menü-Eintrag mindestens braucht. Außerdem sollte der Absatz mit den Kerneloptionen auch vor den Beispielen stehen. Also als ganz grober Roh-Entwurf:

Um einen Loopback-Menü-Eintrag zu erstellen, braucht man mindestens die folgenden Zeilen im Skript: ...

Dann der Absatz mit bezüglich der Kerneloptionen und dann anschließend die Beispiele, wobei man vielleicht auch noch den Inhalt der jeweiligen korrespondierenden isolinux.cfg oder welche Datei sonst die Optionen im ISO-Image enthält mit anfügt, damit das ganz noch etwas deutlicher nachvollziehbar wird.

Gruß, Martin

Newubunti schrieb:

Also ich finde man sollte die Kritik IAM-AT nicht einfach damit abtun, dass er sie falsch begründet hat.

Das Wiki sollte dazu dienen, dass derjenige der es liest, das Thema bzw. die Aufgabe lösen und nachvollziehen kann.

Es sind alle nötigen Informationen enthalten, um einen funktionierenden ISO-Loop-Eintrag zu erstellen.

Und das ist IMO nachvollziehbar, denn der Abschnitt enthält einfach nur zwei Beispiele. Was hier IMO noch hilfreich wäre ist…

Es gibt eine ganz klare Aussage des Wiki-Teams, dass das WIki kein Howto sein soll. Man kann natürlich darüber streiten, wie niedrig der Verständnislevel gesetzt werden sollte, für den man einen Part formuliert.

Auf der anderen Seite erwarte ich von einem User, der eigene Skripte für Grub erstellt soviel Verständis der Vorgänge, dass er sich nach einem mkconfig die erstellte grub.cfg anschaut, um festzustellen, dass der Name des ISO gar nicht im Menüeintrag auftaucht. Dann kann er mit diesem Hinweis entweder seinen Fehler finden oder eine Supportanfrage stellen.

Hallo,

also wenn jemand den Artikel überarbeiten möchte → gerne. Da ich von dem Thema selber wenig Ahnung habe kann ich halt vorher schlecht sagen, ob der Artikel nach der Überarbeitung vielleicht nicht doch zu detailliert ist. Nennt man dann wohl Restrisiko des Autors 😉

Gruß, noisefloor

noisefloor schrieb:

Nennt man dann wohl Restrisiko des Autors 😉

Ich weiß…

Hej,

ich bin über die Aussage

(Ein so gestartetes System...)

im Abschnitt Von-ISO-Dateien-mittels-loopback-booten gestolpert, und muß dem widersprechen:

Ich habe diesen Stick (s. Bild im Anhang) als einziges Medium am Laptop (Platte entfernt), auf

• sdb1 ist ein stand-alone grub,

• sdb2 enthält ausschließlich 2 iso files (die aber bei diesem Vorgang nicht benutzt werden)

• sdb3 ist leer

• sdb5 enthält beim Versuchsbeginn ausschließlich ubuntu-14.04.1-desktop-amd64.iso

Mittels grub_2 wird mit diesem menuentry

menuentry "Trusty Thar rev.1 auf sda5" {
set root=(hd0,5)
loopback loop /ubuntu-14.04.1-desktop-amd64.iso
linux (loop)/casper/vmlinuz.efi boot=casper root=(hd0,5) toram iso-scan/filename=/ubuntu-14.04.1-desktop-amd64.iso locale=de_DE bootkbd=de console-setup/layoutcode=de 
initrd (loop)/casper/initrd.lz
}

Trusty Thar gestartet, und anschließend aus dem LiveSystem auf genau die Partition installiert.

Den Umweg über

sudo umount -l -r -f /isodevice

brauchte ich gar nicht zu gehen, weil nämlich das LiveSystem sdb2 als isodevice eingehängt hat. Die Frage von ubiquity Partitionen von sda aushängen – sda, weil einziges und erstes Device – habe ich mit "ja" beantwortet. Könnte sein, daß nur deshalb (isodevice) die Installation komplett funktionierte, kann das gerne bei Bedarf nochmal prüfen mit nur einer einzigen Partition neben grub, hatte allerdings ja schon viel früher einen ähnlichen Vorgang beschrieben (s. meine Benutzerseite - > direkt-auf-HD-mit-Windows-Linux-installieren.

Gruß black tencate