staging.inyokaproject.org

Hej,

ubiquity ist in 23.04 nicht mehr vorhanden! Darüberhinaus ist der Schalter -b in man ubiquity nicht dokumentiert.

Gruß black tencate

black_tencate schrieb:

EDIT.: ? /boot/efi/boot/grub/grub.cfg sowas habe ich noch nie gesehen, in der ESP gibt es ...

Bei mir gibt's da die (ESP)/EFI/Ubuntu\grub.cfg

search.fs_uuid BC5C-B7DD root hd0,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

und die verweist auf (ESP)/boot/grub/grub.cfg

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
  font=unicode
else
  font="/boot/grub/fonts/unicode.pf2"
fi
if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
terminal_output gfxterm

#insmod png
#background_image /boot-efi/grub/pict3.png

#set color_normal=light-gray/black
#set menu_color_normal=yellow/black
#set menu_color_highlight=red/black

timeout_style=menu
timeout=5

set default=4


menuentry "EFI-PC" { # dieser Eintrag dient lediglich der schnellen Erkennung, in welchem Modus auf dem Rechner gebootet wurde
	set-root=(hd0,gpt1) # ohne 'gültige' Zeile keine Anzeige
        rmmod tpm  # erforderlich für das Booten mittels loopback 
}
menuentry "Stop" {
	halt
}

insmod part_gpt
menuentry "Windows 8.1 auf /dev/sda4" {
	## UUID von EFI-Partition /dev/sda1 :
	search --fs-uuid --set=root BC5C-B7DD
	chainloader /efi/microsoft/boot/bootmgfw.efi
}
insmod ext2
insmod configfile
insmod test
insmod loadenv
insmod gzio
insmod xzio
insmod lzopio
insmod echo
insmod linux
insmod linuxefi
menuentry "Menü von Ubuntu-64 20.04 auf /dev/sda7" {
	search --no-floppy --fs-uuid --set=root 82b4acde-4db6-48b0-9d00-a09fb995b330
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 18.04 auf /dev/sda9" {
	search --no-floppy --fs-uuid --set=root ec7ee724-6bed-4ee0-8056-8ecf44bb46b9
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-64 16.04 auf /dev/sda11" {
	search --no-floppy --fs-uuid --set=root 944662da-df21-471e-b041-082090aaa22e
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 16.04 auf /dev/sda13" {
	search --no-floppy --fs-uuid --set=root c4f2f460-289a-446b-9551-68ea832826f3
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-Unity-64 22.04 auf /dev/sda15" {
	search --no-floppy --fs-uuid --set=root 1b7c43c5-bc91-4317-b7cc-9385392dabd3
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}
menuentry "Menü von Ubuntu-32 16.04 auf USB-Stick" {
	insmod part_msdos
	## Ubuntu_16.04 auf dem USB-Stick /dev/sdb5 :
	search --no-floppy --fs-uuid --set=root 12242877-0cc0-4f7b-afb0-ffadeca726a0
	unset chosen
	set prefix=($root)'/boot/grub'
	configfile $prefix/grub.cfg
	# configfile /boot/grub/grub.cfg
}

Und darin wird dann auf die /boot/grub/grub.cfg der jeweiligen Installationen verwiesen.

Ja das ist bei mir so, weil ich ja Deinen GRUB-stand-alone verwende. Vermutlich verweist die (ESP)/EFI/Ubuntu\grub.cfg direkt in die grub.cfg der Partition (kann ich bei mir jetzt nicht mehr nachgucken), von der zuletzt GRUB aktualisiert wurde, und die wird immer referenziert, wenn es sich um einen signierten GRUB handelt, egal wie viele GRUBs man wo auch immer getrennt installiert hat.

nun, ich finde es ein gutes Recht eines O/S, seinen eigenen Bootloader so zu platzieren, daß das System auch bootet!

Dieses Recht soll auch nicht verwehrt werden. Nur wäre es eben nicht notwendig, die anderen dabei zu deaktivieren, oder wie Windoof es macht, gleich ganz zu überschreiben.

Das Überschreiben von <ESP>/efi/ubuntu erspart jedem Flavour eine eigene Signatur.

Mein Verbesserungsvorschlag #2 würde das aber auch. Ich würde mich sehr freuen, wenn da noch andere "affects me" aktivieren, damit sich da von Ubuntu vielleicht mal jemand mit befasst.

Falls Du über das UEFI Menü in dem *.webm "stolperst", damit zeige ich doch lediglich, daß die beiden Installationen getrennt aufrufbar sind, ihre jeweils eigene grub.cfg verwenden

... die aber dann die *buntus jeweils in anderer Reihenfolgen anzeigen, und das hat Peter.S doch gestört. Und um von der von DJKUHpisse vorgeschlagenen UEFI-Boot-Menü-Funktionalität profitieren zu können, müsste er vorher dann in dieses auch noch rein und Secure-Boot könnte er auch nicht mehr nutzen. Ich denke, so kompliziert wollte es Peter.S nicht. Da ist doch die Methode über ubuquity -b viel einfacher und eleganter.

Das UEFI Menü wird normalerweise nur auf Anforderung (Taste) gezeigt,

Manchmal braucht's auch 2 oder 3

ich hätte auch per sudo efibootmgr -n xxxx && reboot die Unabhängeigkeit von zwei derart installierten *buntus zeigen können.

Ach ich glaube, ich verstehe jetzt, was Du damit sagen willst, nämlich dass man die GRUB-Installationen grundsätzlich trennen, und wie von DJKUHpisse vorgeschlagen dann auch getrennt verwenden kann, wenn man auf Secure-Boot verzichtet, aber wenn man letzteres eben nicht nutzt, dann immer das Menü des 1. *buntu vorfindet. Richtig?

black_tencate schrieb:

ubiquity ist in 23.04 nicht mehr vorhanden! Darüberhinaus ist der Schalter -b in man ubiquity nicht dokumentiert.

Na toll, Canonical nähert sich immer mehr dem "Nur ich bin wichtig"-Gebaren von Windoof. ☹

black_tencate schrieb:

Hej,

ubiquity ist in 23.04 nicht mehr vorhanden! Darüberhinaus ist der Schalter -b in man ubiquity nicht dokumentiert.

Ist da dann überall Calamares im Einsatz?

DJKUhpisse schrieb:

Ist da dann überall Calamares im Einsatz?

Guckst du: https://ikhaya.ubuntuusers.de/2023/04/24/ubuntu-wochenrueckblick-2023-16/#Der-neue-Ubuntu-Installer

black_tencate schrieb:

[…] ubiquity ist in 23.04 nicht mehr vorhanden!

Das Paket ubiquity gibt es nach wie vor auch bei 23.04 und es ist auch für mantic vorgesehen:
https://packages.ubuntu.com/lunar/ubiquity

Darüberhinaus ist der Schalter -b in man ubiquity nicht dokumentiert.

Das ist allerdings so und zwar mindestens zurück auch bereits bei 18.04. Verwirrt mich jetzt etwas.

black_tencate schrieb:

Darüberhinaus ist der Schalter -b in man ubiquity '''nicht''' dokumentiert.

Und der Schalter --no-bootloader, den es wohl auch gibt, auch nicht.

kB schrieb:

Das ist allerdings so und zwar mindestens zurück auch bereits bei 18.04. Verwirrt mich jetzt etwas.

Tja was machen wir nun? Nach Deiner Devise soll ja nichts im Wiki beschrieben werden, was nicht offiziell dokumentiert ist.

Hej kB,

kB schrieb:

... Das Paket ubiquity gibt es nach wie vor auch bei 23.04 und es ist auch für mantic vorgesehen:
https://packages.ubuntu.com/lunar/ubiquity

was hilft's? (siehe → 9376153)

Und noch eins zu dem iso-file mit ubiquity: Ich suche (bislang vergeblich) nach entsprechenden isos für die anderen Flavours. ubiquity -b ist ja imho gerade dafür gedacht, bei einer Dualboot Installation die Klippe, wie sie Peter.S hier aufgezeigt hat, zu umschiffen.

Es bleibt dafür dann nur

1. <ESP>/efi/ubuntu "umlenken" auf ein Abstellgleis → EFI Nachbearbeitung (Abschnitt „Zusaetzliches-Bootverzeichnis-erstellen“)

2. Anpassung der /boot/efi/EFI/Ubuntu/grub.cfg (nicht dauerhaft)

3. in PCs ohne secure boot → GRUB 2/Konfiguration (Abschnitt „GRUB-DISTRIBUTOR“)

4. jeder Installation seine eigene ESP spendieren

Gruß black tencate

black_tencate schrieb:

Es bleibt dafür dann nur [.....]

Auch diese Methoden sind, soweit mir bekannt, nicht offiziell dokumentiert, und gehörten demnach dann auch nicht ins Wiki.

UlfZibis schrieb:

black_tencate schrieb:

Es bleibt dafür dann nur

Auch diese Methoden sind, soweit mir bekannt, nicht offiziell dokumentiert, und gehörten demnach dann auch nicht ins Wiki.

das hast du wohl falsch verstanden, die aufgezeigten Wege stammen ja nicht vom "HörenSagen", sondern sind allesamt experimentell belegt.

black_tencate schrieb:

das hast du wohl falsch verstanden, die aufgezeigten Wege stammen ja nicht vom "HörenSagen", sondern sind allesamt experimentell belegt.

Die Befehle apt purge und apt autopurge sind auch experimentell belegt, sollen aber nicht ins Wiki.

black_tencate schrieb:

Und noch eins zu dem iso-file mit ubiquity: Ich suche (bislang vergeblich) nach entsprechenden isos für die anderen Flavours.

Also ich kann es noch nicht für alle Flavours sagen, aber Kubuntu 23.04 verwendet nach wie vor ubiquity. Die Flavours sind doch mit den Neu-Einführungen in der Regel konservativer bzw. bekommen die Neuerungen erst mit, wenn sie schon da sind und schieben das dann frühstens eine Version später nach.

Ich gehe mal davon aus, dass die anderen Flavours auch noch ubiquity verwenden, daher gibt es dann eben auch keine entsprechenden Legacy-Desktop-Images.

Davon abgesehen, bestünde in einer solchen Situation - bei Neu-Einführung von irgend etwas - ja auch immer noch die Möglichkeit der Meldung eines BUG.

LG, Newubunti

kB schrieb:

black_tencate schrieb:

[…] ubiquity ist in 23.04 nicht mehr vorhanden!

Das Paket ubiquity gibt es nach wie vor auch bei 23.04 und es ist auch für mantic vorgesehen:
https://packages.ubuntu.com/lunar/ubiquity

Darüberhinaus ist der Schalter -b in man ubiquity nicht dokumentiert.

Das ist allerdings so und zwar mindestens zurück auch bereits bei 18.04. Verwirrt mich jetzt etwas.

Diesmal bist u.a. Du es, der in mindestens dieser Weise hier gegen die Regeln verstößt. Es geht hier um die GRUB-Reparatur, und nicht um den Artikel Ubiquity. Und in dem abgespaltenen Artikel ging es immer noch um den Inhalt des Artikels apt/apt. "Der Stand der Dokumentation von apt" war dafür lediglich Referenz. Von daher verstand / verstehe ich nicht den Sinn der Abspaltung. Außerdem wurde das Thema "Dokumentation von apt" schon hier von Dir dort eingeführt, und seitenweise von verschiedenen Beteiligten, bis zuletzt hier von noise_floor, immer wieder aufgegriffen. Die Diskussion wurde also mittendrin abgespalten.

UlfZibis schrieb:

...Es geht hier um die GRUB-Reparatur, und nicht um den Artikel Ubiquity.

sorry, aber

1. hast Du selber ubiquity ins Spiel gebracht → post 9374753, und

2. geht es schon auch hier bei der Grub 2/Reparatur im Falle eines wie von Peter.S beschriebenen Dualboot zu reparierendes Systems ein bißchen um ubiquity.

black_tencate schrieb:

UlfZibis schrieb:

...Es geht hier um die GRUB-Reparatur, und nicht um den Artikel Ubiquity.

sorry, aber

1. hast Du selber ubiquity ins Spiel gebracht → post 9374753, und

2. geht es schon auch hier bei der Grub 2/Reparatur im Falle eines wie von Peter.S beschriebenen Dualboot zu reparierendes Systems ein bißchen um ubiquity.

Ja schon, aber nur in Bezug darauf, ob man GRUB nachträglich in der Weise "reparieren" kann, um in einen Zustand zu kommen, der unter ubiquity -b von selbst entstanden wäre, aber nicht mehr darum, in welchen neueren Versionen von Ubuntu Ubiquity noch und wie zur Verfügung steht, wie das dokumentiert ist, und welchen Ersatz es dafür in Zukunft geben könnte. In dem anderen Thread ging es darum, ob und wie sich der Artikel an der offiziellen Dokumentation von Apt orientiert, und dafür war das Feststellen von "Der Stand der Dokumentation" eben notwendig und nicht OT, um für den betreffenden Artikel eine Entscheidung zu finden.

Für den Artikel "GRUB-Reparatur" ist die oben genannte Diskussion über die Politik von Canonical bzgl. Ubuquity auch vollig irrelevant, und sollte, wenn man schon so enge Maßstäbe wie bzgl. des Apt-Artikels anlegt, hier erst recht als OT gewertet werden.