staging.inyokaproject.org

Ja, genau deswegen habe ich das ja ins Wiki geschrieben.
Ich hatte eine vorbereitete Partition, die auch nicht formatiert werden sollte. Also habe ich nur / als mountpoint gesetzt. Dennoch kam die Meldung, dass die Partitionierung geändert und deshalb /isodevice ausgehängt werden müsse. Ich habe das dann ignorieren lassen und auf weiter gedrückt, und dann hing die Installtion und ging nicht weiter (Meldung: Dateisysteme werden gescannt). Ich habe dann die Installation abgebrochen und

sudo umount /isodevice

ausgeführt, aber es wurde nicht ausgehängt, weil es noch in Benutzung war. Ich dachte schon dass es gar nicht geht, doch dann viel mir dein Hinweis ein und mit

sudo umount -l -r -f /isodevice

hat das Aushängen und die anschließende Installation funktioniert.

Hallo,

Grub 2 und das de_ubuntu Wiki sind der Anlass für diesen Beitrag:

1. Im WIKI Artikel "Skripte" wird m.E. für die Lesenden nicht deutlich geklärt, dass es zwei Wege ( einen alten und einen neuen ) gibt, Skripte zu erstellen, was offenbar 2. mit der history der Grub2 Entwicklung bzw. des Ubuntu Wiki-Artikels zusammenhängt.

Der "alte" Weg Skripte zu erstellen führte dazu, dass nach sudo grub-mkconfig und sudo update-grub die persönlich erstellten menuentries NICHT angezeigt werden. Beim "neuen" Weg wird dies zwar erreicht, doch wird das eigentliche Ziel, nämlich das vollstänge Booten von Iso loopimages, nicht erreicht. Mag daran liegen, dass GRUB 2 noch Beta ist, doch sollte das dann auch m.E. nicht ins WIKI.

Im Einzelnen und konkreter:

I.

Abschnitt:

Erstellen eigener Menü-Einträge

Es sollte das Bearbeiten / Verändern der Standardskripte im Verzeichnis /etc/grub.d vermieden werden. Diese Veränderungen werden mit dem nächsten Update der Grub 2 Pakete zerstört!

Kein Wort darüber, dass dies usprünglich über die 40_ bzw. 41_custom skripte in /etc/grub.de/ geschah und insofern die Lesenden sozusagen zunächst ins zeitaufwändige Nirwana schickt.

II.

Abschnitt

Von ISO-Dateien mittels loopback booten

Wenn ich die in I. gelernte Art und Weise Skripte zu erzeugen anwende, dann gelange ich im Ggs. zur "alten" Variante nicht zum Erfolg. Das bedeutet, dass z.B. das partedmagic Iso zwar kernel und initrd.img zwar bootet aber dann das sqfs Image nicht findet. Benutze ich - wie gesagt - die alte Variante über das 40_custom Skript, dann startet parted magic so wie es soll.

der alte Weg funktioniert:

1
2
3
4
5
6
7
8
9

#!/bin/sh
exec tail -n +3 $0
menuentry 'Parted Magic ISO ' {
set isofile="/iso/pmagic_2013_06_15.iso"
insmod ntfs
loopback loop (hd0,5)$isofile
linux (loop)/pmagic/bzImage64 iso_filename=/iso/pmagic_2013_06_15.iso boot=live keymap=de
initrd (loop)/pmagic/initrd.img
}

der neue Weg nicht ( ich habe mal die für mein System unnötigen insmod Einträge rausgenommen):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#! /bin/sh -e

export ISOFILE="/iso/pmagic_2013_06_15.iso"
echo "Found ISOFILE image: ${ISOFILE}" >&2
cat << EOF
menuentry "Parted Magic - ISO" {
	insmod loopback
	insmod ntfs
	search -n -f --set=root ${ISOFILE}
	loopback loop ${ISOFILE}
	linux (loop)/pmagic/bzImage64 keymap=de
	initrd (loop)/pmagic/initrd.img
}
EOF

III.

Im Abschnitt

Von ISO-Dateien mittels loopback booten

über loopback Iso wird zudem das Folgende geschrieben, ohne es in einen erläuternden Kontext auch mit konkreten Beispielen zu bringen:

Einstellungen in der /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="locale=de_DE bootkbd=de console-setup/layoutcode=de"

Diese Zeilen aus /etc/default/grub wirken sich bspw. nicht beim booten des Kubuntu 14.01.1 aus, d.h. die locale de_DE wird nicht übernommen genausowenig wie die keymap.

Sorry will nicht rummeckern, aber dieser WIKI Beitrag als erste Anlaufstelle bei den ganzen google Suchmaschinen-Nutzenden führt dann imho nicht zu wohlwollender Neugierde gegenüber Linux und bindet zudem doch unnötig viele Zeitressourcen.

Soweit erst mal.

Hallo,

@IAM-AT: Danke für die Hinweis. Möchtest du den Artikel denn auch direkt überabreiten / korrigieren? Dann schieben wir dir diesen gerne in die Baustelle. Wenn ja bitte hier nochmal kurz melden ☺

Gruß, noisefloor

IAM-AT schrieb:

der neue Weg nicht ( ich habe mal die für mein System unnötigen insmod Einträge rausgenommen):

#! /bin/sh -e

export ISOFILE="/iso/pmagic_2013_06_15.iso"
echo "Found ISOFILE image: ${ISOFILE}" >&2
cat << EOF
menuentry "Parted Magic - ISO" {
	insmod loopback
	insmod ntfs
	search -n -f --set=root ${ISOFILE}
	loopback loop ${ISOFILE}
	linux (loop)/pmagic/bzImage64 keymap=de
	initrd (loop)/pmagic/initrd.img
}
EOF

Dieser Eintrag kann nicht funktionieren, weil ein Verweis auf das Iso in der Kernelzeile fehlt (isofrom=/ iso-scan/filename= ). Wie das jetzt lauten müsste, kann ich nicht sagen, da ich kein Spezialist bin.

[Edit]
IAM-AT schrieb:

Im Abschnitt

Von ISO-Dateien mittels loopback booten

über loopback Iso wird zudem das Folgende geschrieben, ohne es in einen erläuternden Kontext auch mit konkreten Beispielen zu bringen:

Einstellungen in der /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="locale=de_DE bootkbd=de console-setup/layoutcode=de"

Diese Zeilen aus /etc/default/grub wirken sich bspw. nicht beim booten des Kubuntu 14.01.1 aus, d.h. die locale de_DE wird nicht übernommen genausowenig wie die keymap.

In dem Beispiel Ubuntu-Iso werden die Variablen ${GRUB_CMDLINE_LINUX_DEFAULT} und ${GRUB_CMDLINE_LINUX} als Kernelparameter mit übergeben. Bei mir funktioniert das auch.

IAM-AT schrieb:

Abschnitt:

Erstellen eigener Menü-Einträge

Es sollte das Bearbeiten / Verändern der Standardskripte im Verzeichnis /etc/grub.d vermieden werden. Diese Veränderungen werden mit dem nächsten Update der Grub 2 Pakete zerstört!

den Satz versteh ich jetzt auch nicht - es sind doch gerade diese Scripte, mit denen die grub.cfg gesteuert wird.

Ich schreibe immer alle Systeme nach "40_custom", egal ob BIOS oder UEFI - dann noch den "os-prober" ausschalten und gut isses → funktioniert hier seit Jahren so mit Multibootmaschinen.

Die Aussage beißt sich auch mt dem Artikel

• Grub2 Konfiguration

dort steht gleich zu Beginn

Möchte man GRUB 2 trotzdem manuell anpassen - ... - so geschieht das über die Datei /etc/default/grub und über die Skripte im Verzeichnis /etc/grub.d.

Grüße

Frieder

IAM-AT schrieb:

Es sollte das Bearbeiten / Verändern der Standardskripte im Verzeichnis /etc/grub.d vermieden werden. Diese Veränderungen werden mit dem nächsten Update der Grub 2 Pakete zerstört!

Wir können an dieser Stelle wirklich keine Ungereimtheit oder gar Fehler erkennen - genauso wie der restliche Einwurf für uns einfach nur wirres Zeug ist - z.B.:

Kein Wort darüber, dass dies usprünglich über die 40_ bzw. 41_custom skripte in /etc/grub.de/ geschah und insofern die Lesenden sozusagen zunächst ins zeitaufwändige Nirwana schickt.

Hä?

Auch dieses sind "Standardskripte" und werden bei einem Update von GRUB 2 überschrieben. Diese Skripte sind als Anregung zu verstehen, mehr nicht.

Alle Wege führen nach Rom

Angelehnt an diese alte Redewendung: Ohne Nachdenken ist auch das Abweichen vom standardisiertem Weg eben nicht möglich.

Das man das Eine oder Andere auch umformulieren kann, dem stimme ich zu - aber es allen Recht machen, das ging noch nie.

Frieder108 schrieb:

den Satz versteh ich jetzt auch nicht - es sind doch gerade diese Scripte, mit denen die grub.cfg gesteuert wird.

Sichere dir mal deine Custom-Skripte und führe ein

sudo apt-get --reinstall install 

von Grub aus, dann weißt du, was gemeint ist. Neuinstallation von Grub überschreibt auch die Standardskripts. Ich bin nicht sicher, ob ein Skript überlebt, wenn du dir eine/n eigene/n Nummer/Namen ausdenkst.

lionlizard schrieb:

Ich bin nicht sicher, ob ein Skript überlebt, wenn du dir eine/n eigene/n Nummer/Namen ausdenkst.

Skripte mit eigener Nummer (regeln den Aufruf) und eigenem / geändertem Namen bleiben immer erhalten.

Veränderungen innerhalb von Standardskripten werden in der Regel erkannt - aber ein Hinweis erfolgt nur im Terminal!

Also kann es passieren, das ein verändertes Standardskript zwar abgespeichert / gesichert wird (in der Regel mit der Endung .ufc-dist bzw. .dpkg-old), aber der nächste Start dann mit dem neuen Standardskript eben nicht mehr läuft.

lionlizard schrieb:

Frieder108 schrieb:

den Satz versteh ich jetzt auch nicht - es sind doch gerade diese Scripte, mit denen die grub.cfg gesteuert wird.

Sichere dir mal deine Custom-Skripte und führe ein

sudo apt-get --reinstall install 

von Grub aus, dann weißt du, was gemeint ist.

Da passiert genau gar nix 😛

Das jetztige 14.04 war mal ein 12.04 → damals, noch mit Grub 1.99 wurde das alles eingerichtet, jetzt schreiben wir Grub 2.02 und es funzt immer noch ☺

Aber ja, schon klar, Linux mag mich halt - warum auch immer 🦆

Wow, letzter Beitrag vom April 2014 und nun gleich ein Haufen Antworten. Vielen Dank für das Feedback. ☺

@noisefloor

Möchtest du den Artikel denn auch direkt überabreiten / korrigieren? Dann schieben wir dir > diesen gerne in die Baustelle. Wenn ja bitte hier nochmal kurz melden.

😉 wäre eine gute Beschäftigungsmaßnahme, doch fühle ich mich weder kompetent genug, noch habe ich die zeitlichen Ressourcen, würde aber quer lesen, wenn eine Person, die sich einfach besser mit der Technik auskennt, da mal an die Materie setzt.

@ lionlizard

Dieser Eintrag kann nicht funktionieren, weil ein Verweis auf das Iso in der Kernelzeile fehlt (isofrom=/ iso-scan/filename= ). Wie das jetzt lauten müsste, kann ich nicht sagen, da ich kein Spezialist bin.

Danke, dass Du Dir darüber Gedanken gemacht hast. Ich habe ja den m.E. „neuen“ und „alten“ Weg in meinem vorigen post gegenübergestellt und auch, wenn ich vergessen habe, boot=live in den „neuen Weg“ als Kernelparameter mit einzufügen, so dass die Kernelparameter beider Wege sozusagen identlisch sind, funktioniert „der neue Weg“, selbst mit den GLEICHEN Kernelparametern nicht ( *.sqfs wird nicht gefunden ). Nach meinem Dafürhalten handelt es sich hierbei offensichtlich um eine Inkohärenz der Funktionen von Grub2. Um bei dem sprachlichen Bild von syscon-hh zu bleiben: der eine (alte) Weg führt nach Rom, der andere (neue) - um bei meinem Bild zu bleiben - ins Nirwana.

In dem Beispiel Ubuntu-Iso werden die Variablen ${GRUB_CMDLINE_LINUX_DEFAULT} und ${GRUB_CMDLINE_LINUX} als Kernelparameter mit übergeben. Bei mir funktioniert das auch.

Habe die Default Variablen wie folgt gesetzt:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=Linux acpi_backlight=vendor locale=de_DE bootkbd=de console-setup/layoutcode=de"

GRUB_CMDLINE_LINUX=""

das Kubuntu 14.01.1 iso Image wird nicht mit keymap de und ein Englisch geladen. Speichere ich das iso auf einen usb stick, so werde ich beim booten im LIVE Modus gefragt, welche Sprache ich benutzen will. Geht bei mir nicht. ☹

@ syscon hh

Ich verweise ich die von mir o.g. Inkohärenz. Dein Ton ist im Übrigen beleidigend und lässt eher auf Unsicherheiten bei Dir schließen. Du bist sicherlich eine könnende Person, dann lass doch andere, weniger Wissende, daran teilhaben, ohne diese bei offenen Fragen gleich zu entwerten?

@ Frieder

das jetztige ubuntu 14.04 war mal ein 12.04 → damals, noch mit Grub 1.99 wurde das alles eingerichtet, jetzt schreiben wir Grub 2.02 und es funzt immer noch

ich verstehe Deinen Beitrag nicht. Kannst Du das konkretisieren?

Danke und cheers!

Hallo,

IAM-AT schrieb:

@ syscon hh Ich verweise ich die von mir o.g. Inkohärenz. Dein Ton ist im Übrigen beleidigend und lässt eher auf Unsicherheiten bei Dir schließen. Du bist sicherlich eine könnende Person, dann lass doch andere, weniger Wissende, daran teilhaben, ohne diese bei offenen Fragen gleich zu entwerten?

Kann ich ehrlich gesagt nicht erkennen... Und abgesehen davon ist mit Sicherheit _kein_ Grund, zum subtil-verbalen Gegenschlag auszuholen.

Also bitte auf der Sachebene bleiben!

Gruß, noisefloor

ok, das mit Grub2/BIOS/MBR/UEFI scheint generell problematisch zu sein.

https://debianforum.de/forum/viewtopic.php?f=12&p=1007702#p1007479

Industriestandards wechseln, Jede Distro baut ihren Bootvorgang anders usw. usf. Beta halt. Heartbleed.

Ich mag Linux trotzdem.

IAM-AT schrieb:

ok, das mit Grub2/BIOS/MBR/UEFI scheint generell problematisch zu sein.

Hatte ich es doch vermutet - das sollte eine Support-Anfrage sein, wie man mit dem veralteten PartedMagic umgeht.

Anstatt so gewaltig alles schlecht zu machen, wäre eine schlichte Supportanfrage zum Thema, z.B. mit

• Wie starte ich "PartedMagic" über GRUB 2

ganz einfach zu beantworten gewesen.

Wie das nun mal aussieht - siehe Anlage

hey syscon hh!

Deiner Feststellung würde ich sachlich nicht zustimmen.

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, um die von mir o.g. Unstimmigkeiten überhaupt erst mal zu finden, eigene Fehler -soweit möglich- auszuschließen, um dann zu der Schlussfolgerung zu kommen, in diesem Forum zum Wiki-GRUB_2-Skripte einen konstruktiv-kritischen post zu schreiben.

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.

Dort liegen bekannte bugs schon seit Monaten auf "todo"- Insofern habe ich auch support für "uns" geleistet, finde ich. 😉

Insofern würde ich Dich bitten, sachlich zu bleiben, bewertende Äußerungen und Schlußfolgerungen zu unterlassen. Das hilft - außer Dir - niemandem.

IAM-AT schrieb:

Dort liegen bekannte bugs schon seit Monaten auf "todo" - Insofern habe ich auch support für "uns" geleistet, finde ich. 😉

Das stimmt, aber es ist normalerweise nicht Aufgabe dieses Wikis, die Fehler und Probleme der GRUB-Entwickler in allen Einzelheiten zu dokumentieren. Von dieser Regel gibt es natuerlich Ausnahmen, wenn beispielsweise so gravierende Fehler vorliegen, ueber die jeder stolpern muss. Ist das in diesem Fall gegeben?