staging.inyokaproject.org

Hej,

@UlfZibis

Ich verstehe den Sinn des Ganzen nicht wirklich!

Ich habe auf einer Platte einen stand-alone grub (!im EFI-Modus ▶ Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD), installiere von einem Flashkey (ebenfalls EFI-Modus) ein 32Bit System mit am Ende abgebrochner Installation wegen Nicht-Installierbarkeit von grub. Für dieses Mate lege ich in der (zum stand-alone grub gehörenden) grub.cfg einen menuentry an und boote (Punkt).

menuentry "Beaver Mate i386" {
	set root=(hd0,gpt7)
	linux /vmlinuz root=UUID=c81a5bf1-38a3-44c1-a5af-0d54b19cb93b ro
    initrd /initrd.img
}

blacktencate@t520-xx:~$ sudo blkid
/dev/sda1: LABEL="Wiederherstellung" UUID="A07C9F927C9F61B8" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="9aa5b0ae-a3de-42c3-938e-ccb921b6e26c"
/dev/sda2: UUID="F6A1-149C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="930f1e62-4939-4873-8f47-a297095a9066"
/dev/sda4: UUID="F0A6FFAFA6FF7506" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="317806a5-7814-439f-a69e-d9f419cbb08d"
/dev/sda5: LABEL="BB-M500" UUID="9d2ba6ce-faa0-40cb-b0f8-6f288a7dbd77" TYPE="ext4" PARTUUID="158a46f3-988c-4282-99f3-05d006db04f7"
/dev/sda6: LABEL="BB-home-M500" UUID="532b36dc-ddcb-445d-b29d-1f7628f7e70b" TYPE="ext4" PARTUUID="849aba3e-e090-4a0c-a172-a8d124f607b2"
/dev/sda7: UUID="c81a5bf1-38a3-44c1-a5af-0d54b19cb93b" TYPE="ext4" PARTUUID="de753d59-a61a-4dd0-800e-b813fa3085e4"
/dev/sda8: UUID="bb4c71d9-a087-477f-a3dd-1d07774d2156" TYPE="ext4" PARTUUID="faf40a6d-b069-46a2-a15b-6b969221001d"
/dev/sda9: LABEL="Budgie-M500" UUID="f6b84754-97ac-4f0f-9b13-2376ef76475f" TYPE="ext4" PARTUUID="f9549179-c1b2-4d73-b24c-5e7be431368e"
/dev/sda10: LABEL="Budgie-home-M500" UUID="28548340-e1a0-4d09-8e1d-84f9e7251c71" TYPE="ext4" PARTUUID="aa3c54c7-bb8c-4766-a9f3-d4d2108bf8de"
/dev/sda11: LABEL="rescue-bilder-M500" UUID="67FD8F2504326747" TYPE="ntfs" PARTUUID="4d153d70-5c3f-4efe-a104-8d97818f2344"
/dev/sdb1:[...]
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="e93423fe-e2ca-47b1-b288-42989f738537"
blacktencate@t520-xx:~$

und wenn ich denn (nach einem kernel update) den alten nochmal booten wollt, ändere ich die beiden Symlinks.

Gruß black tencate

Hai black_tencate

schrieb:

Ich verstehe den Sinn des Ganzen nicht wirklich!

Ich habe auf einer Platte einen stand-alone grub (!im EFI-Modus ▶ Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD), installiere von einem Flashkey (ebenfalls EFI-Modus) ein 32Bit System mit am Ende abgebrochner Installation wegen Nicht-Installierbarkeit von grub. Für dieses Mate lege ich in der (zum stand-alone grub gehörenden) grub.cfg einen menuentry an und boote (Punkt).

Diese Anleitung kannte ich bisher noch gar nicht, danke für den Hinweis. Aber wie steht da so schön: ... nur für fortgeschrittene Benutzer gedacht. Außerdem habe ich da mal eine 3. noch einfachere Variante ergänzt.

Meine Anleitung soll diese Einschränkung umgehen, und erlaubt auch das (quasi) automatische Update von GRUB. Die weitere Pflege des System kann man dann auch einem Computer-Dummie zumuten.

und wenn ich denn (nach einem kernel update) den alten nochmal booten wollt, ändere ich die beiden Symlinks.

Welche Symlinks meinst Du?

Gruß Ulf

Hej UlfZibis,

UlfZibis schrieb:

... ...Aber wie steht da so schön: ... nur für fortgeschrittene Benutzer gedacht.

na ja, das war die Meinung von noisefloor, ich halte das für deutlich übertrieben, ein simples sudo grub-install... an den richtigen Ort, das sollte jeder hinbekommen.

...Außerdem habe ich da mal eine 3. noch einfachere Variante ergänzt.

nichts gegen Multisystem (ist ein Wahnsinnsteil, keine Frage), verwende ich selber seit langem, aber (Zitat von hier)

Für das Erzeugen eines Live-USB flashkey werden (hier bei ubuntuusers.de) meistens zwei Vorgehensweisen empfohlen

das jedenfalls würde ich für Multisystem nicht unterschreiben 😕 Und auch kann der nicht alles, jedenfalls nicht das, was den Zweck der im Artikel beschriebenen Verwendung betrifft.

Meine Anleitung soll diese Einschränkung umgehen

Du beziehst Dich auf die Warnung bezgl. Sicherheitslücke? Nun ja, Verwendung von Paßwort innerhalb von grub scheint ja eher weniger verbreitet, oder warum konnte der Fehler so lange unentdeckt bleiben?

Welche Symlinks meinst Du?

▶

menuentry ...

linux /vmlinuz root=UUID=c81a5bf1-38a3-44c1-a5af-0d54b19cb93b ro
initrd /initrd.img
}

resp. vmlinuz.old und initrd.img.old, die verweisen auf den zuvor aktuellen kernel

Btw.: Den internen Link auf grub 2 halte ich für überflüssig, das ist doch nur der Übersichtsartikel (in welchen der Artikel ja selber verlinkt ist -z.Z. Vorletzter).

Gruß black tencate

black_tencate schrieb:

nichts gegen Multisystem (ist ein Wahnsinnsteil, keine Frage), verwende ich selber seit langem, aber (Zitat von hier)

Danke für den Hinweis.

Für das Erzeugen eines Live-USB flashkey werden (hier bei ubuntuusers.de) meistens zwei Vorgehensweisen empfohlen

das jedenfalls würde ich für Multisystem nicht unterschreiben 😕

Oh, guter Hinweis, die Formulierung müsste dann angepasst werden. Hast Du eine elegante Idee wie?

Und auch kann der nicht alles, jedenfalls nicht das, was den Zweck der im Artikel beschriebenen Verwendung betrifft.

Hm, was kann denn MultiSystem nicht? Ich verstehe nicht ganz.

Meine Anleitung soll diese Einschränkung umgehen

Du beziehst Dich auf die Warnung bezgl. Sicherheitslücke? Nun ja, Verwendung von Paßwort innerhalb von grub scheint ja eher weniger verbreitet, oder warum konnte der Fehler so lange unentdeckt bleiben?

Nein, das meine ich nicht. Ich meine die ziemlich aufwendige manuelle Installation von GRUB und die manuelle Erstellung von Menü-Einträgen.

▶

menuentry ...

linux /vmlinuz root=UUID=c81a5bf1-38a3-44c1-a5af-0d54b19cb93b ro
initrd /initrd.img
}

resp. vmlinuz.old und initrd.img.old, die verweisen auf den zuvor aktuellen kernel

Ach ich verstehe, ich dachte Du meintest den Symlink von /initrd.img nach /boot/initrd.img-x.y.z-generic
Aber egal, das ist nicht so vielseitig wie die normalen Grub-Menü-Einträge unter "Erweiterte Optionen für Ubuntu" und nur "fortgeschrittenen Benutzern" möglich.

Hej UlfZibis,

UlfZibis schrieb:

... Oh, guter Hinweis, die Formulierung müsste dann angepasst werden.

nein, wozu, hier im Forum wird eben vornehmlich nicht Multisystem zur Erzeugung eines USB Sticks genannt (mehr steht nicht in dem Vorwort und gehört da auch nicht hin)

Hm, was kann denn MultiSystem nicht? Ich verstehe nicht ganz.

mir kam noch überhaupt nicht in den Sinn, Multisystem als Bootloader in meinem PC zu vervenden, k.A., ob man das damit bewerkstelligen könnte. In jedem Falle müßtest Du auch dort in der grub.cfg die selben Einträge (von Hand) erzeugen, wie das bei dem stand-alone grub der Fall ist.

Nein, das meine ich nicht. Ich meine die ziemlich aufwendige manuelle Installation von GRUB und die manuelle Erstellung von Menü-Einträgen.

tja, wenn Du das für zu aufwendig hälst, kannst Du dich ja mehr auf die scripte konzentrieren (und mal herausfinden, warum die solche irren grub.cfg-files erzeugen 😈

Ach ich verstehe, ich dachte Du meintest den Symlink von /initrd.img nach /boot/initrd.img-x.y.z-generic

scheint mir nicht so, mach doch mal ein ls -l /, dann siehst das vielleicht. Oder Du schaust hier ▶ GRUB 2/Shell (Abschnitt „Starten-mit-Hilfe-des-Rettungsmodus“) (9.)

Aber egal, das ist nicht so vielseitig wie die normalen Grub-Menü-Einträge unter "Erweiterte Optionen für Ubuntu"

bei mir steht da gewöhnlich nur noch ein einziger (was soll ich mit den alten kerneln?), und falls ich das Menü aus /boot7grub/grub.cfg haben möchte, lade ich es einfach über configfile /boot7grub/grub.cfg.

Allerdings hatte ich auch noch nie so was verrücktes, wie es wohl irgendwie der os-prober erzeugt hat

(

	menuentry ' (auf /dev/sda6) (auf /dev/sda1) (auf /dev/sdb3) (auf /dev/sda1) (auf /dev/sdb3) (auf /dev/sda1) (auf /dev/sda6)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--110ede42-a303-4584-9592-f7ac53683761' {
		insmod part_msdos
		insmod ext2
		set root='hd0,msdos6'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6  110ede42-a303-4584-9592-f7ac53683761
		else
		  search --no-floppy --fs-uuid --set=root 110ede42-a303-4584-9592-f7ac53683761
		fi
		linux /vmlinuz root=/dev/sda6
		initrd /initrd.img.old
	

Ooops, man soll nie nie sagen...s. Anhang ( 👿 S....ß scripte)

...und nur "fortgeschrittenen Benutzern" möglich.

wenn Du meinst.

Gruß black tencate

black_tencate schrieb:

... aber (Zitat von hier)

Für das Erzeugen eines Live-USB flashkey werden (hier bei ubuntuusers.de) meistens zwei Vorgehensweisen empfohlen

das jedenfalls würde ich für Multisystem nicht unterschreiben 😕 Und auch kann der nicht alles, jedenfalls nicht das, was den Zweck der im Artikel beschriebenen Verwendung betrifft.

In dem Absatz geht es aber nicht um den "Zweck des Artikels" (stand-alone auf USB flashkey und internen HDD und SSD), sondern um "Für das Erzeugen eines Live-USB flashkey ...".

Btw.: Den internen Link auf grub 2 halte ich für überflüssig, das ist doch nur der Übersichtsartikel (in welchen der Artikel ja selber verlinkt ist -z.Z. Vorletzter).

Ich nicht. Beim Studieren des Artikels hatte ich nämlich genau das Problem, dass ich zum besseren Verständnis in den GRUB-Hauptartikel reingucken wollte, und zum Aufrufen desselben umständlich die Suchfunktion bemühen musste, was mir genau dieser Link erspart hätte.

black_tencate schrieb:

Oh, guter Hinweis, die Formulierung müsste dann angepasst werden.

nein, wozu

Oh, ich hatte nicht bemerkt, dass Du meine Ergänzung wieder rausgenommen hattest. Meine dritte Variante stand dann im Widerspruch zu "meistens zwei Vorgehensweisen".

black_tencate schrieb:

Hm, was kann denn MultiSystem nicht? Ich verstehe nicht ganz.

mir kam noch überhaupt nicht in den Sinn, Multisystem als Bootloader in meinem PC zu vervenden, k.A., ob man das damit bewerkstelligen könnte. In jedem Falle müßtest Du auch dort in der grub.cfg die selben Einträge (von Hand) erzeugen, wie das bei dem stand-alone grub der Fall ist.

Klar, aber in dem Absatz geht es doch nur um einen Hinweis auf das allgemeine Erzeugen eines USB-Flash-Key, und dafür ist MultiSytem doch bestens geeignet. Ich verstehe nicht, warum das allgemein auf ubuntuusers.de ignoriert wird.

Nein, das meine ich nicht. Ich meine die ziemlich aufwendige manuelle Installation von GRUB und die manuelle Erstellung von Menü-Einträgen.

tja, wenn Du das für zu aufwendig hälst, kannst Du dich ja mehr auf die scripte konzentrieren (und mal herausfinden, warum die solche irren grub.cfg-files erzeugen 😈

So einen Fall hatte ich auch mal. Deshalb hatte ich dazu dann einen Fehlerbericht verfasst. Wäre nett, wenn Du Dich da unter "This bug affects you" eintragen könntest, dann sollte der Bug automatisch den Status confirmed bekommen.

Ach ich verstehe, ich dachte Du meintest den Symlink von /initrd.img nach /boot/initrd.img-x.y.z-generic

scheint mir nicht so, mach doch mal ein ls -l /, dann siehst das vielleicht.

Eben, genau da erscheinen doch diese Symlinks.

Oder Du schaust hier ▶ GRUB 2/Shell (Abschnitt „Starten-mit-Hilfe-des-Rettungsmodus“) (9.)

Aber egal, das ist nicht so vielseitig wie die normalen Grub-Menü-Einträge unter "Erweiterte Optionen für Ubuntu"

bei mir steht da gewöhnlich nur noch ein einziger (was soll ich mit den alten kerneln?), und falls ich das Menü aus /boot7grub/grub.cfg haben möchte, lade ich es einfach über configfile /boot7grub/grub.cfg.

Eben, wenn ich die Standard-GRUB-Konfiguration von Ubuntu verwende, erhalte ich bequem die Einträge für den Rettungsmodus, bei "stand-alone" müsste man das alles manuell basteln, bzw configfile /boot7grub/grub.cfg erfordert doch schon einen "fortgeschrittenen Benutzer".

...und nur "fortgeschrittenen Benutzern" möglich.

wenn Du meinst.

Ich meine, dass es verantwortungslos wäre, vor allem einem fremden "Computer-Dummy" so ein "stand-alone"-System zu installieren, denn der wäre damit überfordert, das System aktuell zu halten.

EDIT BTW: Ich denke, wir sind hier schon ziemlich OT vom eigentlichen HowTo. Seit 9014178 sind wir doch eher in Diskussion um Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD. Vielleicht wäre es sinnvoll, dass ein Moderator dieses Nebenthema geeignet dorthin abspaltet.

Hej UlfZibis,

ich mach' jetzt hier mal ein dickes OT, denn was hat diese Diskussion denn nun mit Deinem HowTo zutun?

OT

UlfZibis schrieb:

black_tencate schrieb:

... aber (Zitat von hier)

Für das Erzeugen eines Live-USB flashkey werden (hier bei ubuntuusers.de) meistens zwei Vorgehensweisen empfohlen

das jedenfalls würde ich für Multisystem nicht unterschreiben 😕 Und auch kann der nicht alles, jedenfalls nicht das, was den Zweck der im Artikel beschriebenen Verwendung betrifft.

In dem Absatz geht es aber nicht um den "Zweck des Artikels" (stand-alone auf USB flashkey und internen HDD und SSD), sondern um "Für das Erzeugen eines Live-USB flashkey ...".

wieder falsch, es ist ein Hinweis im Vorwort darauf, was hier bei UUde meistens empfohlen wird, und dabei ist mir eher ganz selten auch mal Multisystem untergekommen.

Btw.: Den internen Link auf grub 2 halte ich für überflüssig, das ist doch nur der Übersichtsartikel (in welchen der Artikel ja selber verlinkt ist -z.Z. Vorletzter).

Ich nicht. Beim Studieren des Artikels hatte ich nämlich genau das Problem, dass ich zum besseren Verständnis...

wäre ja interessant, an welcher Stelle Dir letztlich welcher (Unter)Artikel Aufhellung verschafft hat. Im Umkehrschluß könnte ich daraus ja eine Artikelverbesserung ableiten?

...in den GRUB-Hauptartikel reingucken wollte,

und dazu kannst du nicht \https://wiki.ubuntuusers.de/Startseite/ aufrufen und schnell Startseite durch grub_2 resp. efi_bootmanagement ersetzen? tz, tz.

*Ironie ein* Außerdem ist der Artikel ja nur für Fortgeschrittene, die wissen das *ironie aus*

/OT

Gruß black tencate

black_tencate schrieb:

ich mach' jetzt hier mal ein dickes OT, denn was hat diese Diskussion denn nun mit Deinem HowTo zutun?

Siehe mein obiges EDIT.

wieder falsch, es ist ein Hinweis im Vorwort darauf, was hier bei UUde meistens empfohlen wird,

Ja genau, deshalb schwebte mir ja eine Umformulierung vor, z.B. mittels:

Eine weitere elegante Möglichkeit ist die Nutzung von: 3. Basis O/S Linux: ▶ ( → MultiSystem)

• kann alles, ist einfach zu bedienen, sogar exotische Floppy-Images lassen sich mit etwas Handarbeit starten.

und dabei ist mir eher ganz selten auch mal Multisystem untergekommen.

Schade eben, deshalb wird es IMHO mal Zeit, das geniale MultiSystem öfter mitzuerwähnen.

Btw.: Den internen Link auf grub 2 halte ich für überflüssig, das ist doch nur der Übersichtsartikel (in welchen der Artikel ja selber verlinkt ist -z.Z. Vorletzter).

Ich nicht. Beim Studieren des Artikels hatte ich nämlich genau das Problem, dass ich zum besseren Verständnis...

wäre ja interessant, an welcher Stelle Dir letztlich welcher (Unter)Artikel Aufhellung verschafft hat.

Statt des Übersichtsartikels könnte man natürlich auch einen speziellen GRUB-Artikel verlinken, Frage ist nur welchen? ... denn jeder möchte vielleicht was anderes nachschlagen.

...in den GRUB-Hauptartikel reingucken wollte,

und dazu kannst du nicht \https://wiki.ubuntuusers.de/Startseite/ aufrufen und schnell Startseite durch grub_2 resp. efi_bootmanagement ersetzen? tz, tz.

Ja natürlich k(ö/o)nnte ich das.

*Ironie ein* Außerdem ist der Artikel ja nur für Fortgeschrittene, die wissen das *ironie aus*

Dürfen es Fortgeschrittene nicht auch mal bequem haben?

Tach Leute,

hab mal eine böse Frage: nachdem die einzigen Ubuntuversionen momentan 16.04 auf Standard-Ubuntu und 18.04 auf Standard und Derivaten sind, die noch 32-bit unterstützen, dürfte es nicht mehr sinnvoll sein, auf welchem EFI-System auch immer ein 32-bit-Ubuntu zu installieren, denn sobald das System einen 64-bit-Prozessor hat sollte man mittlerweile für die Zukunft immer ein 64-bit-System installieren, oder? Und wenn man einen 32-bit-Prozessor hat, hat dieser ziemlich sicher kein EFI, oder? Ist dann dieser Artikel noch sinnvoll oder sollte man ihn besser archivieren?

Viele Grüße

Federicus

Federicus schrieb:

hab mal eine böse Frage: nachdem die einzigen Ubuntuversionen momentan 16.04 auf Standard-Ubuntu und 18.04 auf Standard und Derivaten sind, die noch 32-bit unterstützen, dürfte es nicht mehr sinnvoll sein, auf welchem EFI-System auch immer ein 32-bit-Ubuntu zu installieren,

Kommt drauf an, wie viel Performance in Kombination mit Bedienkomfort Du von Deinem System erwartest. Dieser Vergleichstest war der Grund für diese Anleitung.

... sollte man mittlerweile für die Zukunft immer ein 64-bit-System installieren, oder?

Was hast Du davon, der Zukunftsvorsorge wegen eine Krankenschwester oder Ärztin zu heiraten, wenn Du mir ihr schon jetzt schlechten Sex etc. hast.

Und wenn man einen 32-bit-Prozessor hat, hat dieser ziemlich sicher kein EFI, oder?

EFI steckt nie im Prozessor, sondern im ROM des Mainboards.

Ist dann dieser Artikel noch sinnvoll oder sollte man ihn besser archivieren?

Ob er für Dich sinnvoll ist, musst Du selbst entscheiden. Das heißt aber nicht, dass alle Artikel im Wiki die Für Dich nicht sinnvoll sind, dass das für andere auch so ist. Gültig ist er noch solange, solange es noch 32-Bit-Ubuntu gibt.

UlfZibis schrieb:

Kommt drauf an, wie viel Performance in Kombination mit Bedienkomfort Du von Deinem System erwartest. Dieser Vergleichstest war der Grund für diese Anleitung.

Achso, danke, gut zu wissen, auch wenn selbst mein alter Dell Latitude D830 mit 2,2 GHz Dual Core auf 64-bit-Kubuntu ziemlich ansehnlich läuft... Nun gut...

Was hast Du davon, der Zukunftsvorsorge wegen eine Krankenschwester oder Ärztin zu heiraten, wenn Du mir ihr schon jetzt schlechten Sex etc. hast.

Da empfehle ich, Single zu bleiben, aber das ist in unserem Kontext wohl keine Option 😉

EFI steckt nie im Prozessor, sondern im ROM des Mainboards.

Gut ich korrigiere auf "Wenn man einen 32-bit-Prozessor hat, hat das Mainboard ziemlcih sicher kein EFI, oder?"

Gültig ist er noch solange, solange es noch 32-Bit-Ubuntu gibt.

Heißt, das steht hier noch 3 Jahre bis es obsolet ist? ^^

Federicus schrieb:

Da empfehle ich, Single zu bleiben, aber das ist in unserem Kontext wohl keine Option 😉

Genau, ohne Computer und Ubuntu ist das Leben noch einsamer. 😀

Gut ich korrigiere auf "Wenn man einen 32-bit-Prozessor hat, hat das Mainboard ziemlcih sicher kein EFI, oder?"

Aber es gibt sie, und dafür gibt es grub-efi-ia32, sogar für 20.04.

Heißt, das steht hier noch 3 Jahre bis es obsolet ist? ^^

Ungefähr so, ja.

Hallo,

Heißt, das steht hier noch 3 Jahre bis es obsolet ist? ^^

Korrekt. So ist das bei Howtos und Wikiartikeln. Der Artikel bleibt, so lange der *buntu-Release noch Support hat. Im gegebenen Fall also bis April 2023, wenn Bionic EOL ist.

Gruß, noisefloor

vielen dank für diese anleitung!

als anmerkung: damit kann man auf einem 64bit computer, der ein 32bit uefi hat, die aktuelle 20.04 als 64 bit zum laufen bekommen!