staging.inyokaproject.org

Hej,

eine "saubere" Installation (im CSM) mit dem verhunzten ubiquty scheint – für den unerfahrenen user – auch nicht mehr möglich. Tolle Stolperfalle!

Gruß blacktencate

Was ist deine Frage dazu?

Im Jahr 2022 kann man schon davon ausgehen, das es keine „normalen“ Rechner/Laptops mit BIOS mehr gibt. Es gibt also auch keinen Grund mehr Krückenlösungen wie CSM zu aktivieren.

Noch haufenweise Rechner haben CSM standardmäßig aktiv (Modus Hybrid). Win 10 ist dann im UEFI installiert, aber man kann den Ubuntu-Stick noch im CSM-Modus booten. Kommt diese Meldung denn auch bei einem Rechner mit klassischen BIOS, noch vor der UEFI-Zeit? Generell bin ich der Meinung, dass man hier einen Bug melden sollte, wenn dem so ist.

Hallo black_tencate,

Wahrscheinlich auch deshalb sollte "ubiquity" ursprünglich aus der 22.04 verschwinden ... was man ja nicht geschafft hat.

Gruss Lidux

black_tencate schrieb:

[…] eine "saubere" Installation (im CSM) mit dem verhunzten ubiquty scheint – für den unerfahrenen user – auch nicht mehr möglich.

Was passiert denn auf einem Bios-Boot-System, wenn man – wie es der Dialog ja anbietet – einfach auf eigenes Risiko weitermacht?

Hej ChickenLipsRfun2eat,

ChickenLipsRfun2eat schrieb:

... Im Jahr 2022 kann man schon davon ausgehen, das es keine „normalen“ Rechner/Laptops mit BIOS mehr gibt.

Na, dann frag mal die Aktualität der hier bei den usern in Benutzung befindlichen Rechnern. Nach der Logig wäre es konsequent, eine Installation in dem Modus gar nicht erst noch anzubieten.

Und ob jetzt überall so eine große Affinität und Lust auf EFI besteht, wage ich auch zu bezweifeln.

Der "Witz" ist ja, es geht ja (man muß die verquere Meldung einfach nur ignorieren).

Es gibt also auch keinen Grund mehr Krückenlösungen wie CSM zu aktivieren.

es gibt aber schon Gründe, EFI nicht für DAS Allheilmittel für den Bootvorgang zu halten.

1. meine Frage – wenn Du meinst, daß das noch nötig ist – wassollderScheiß?

2. alter nurBIOS-Rechner zwar vorhanden, der tut 's aber nur bis kernel 4.13 (oder so ähnlich) teste gerade mit nomodeset

3. Lubuntu macht das aber schon seit (min.) 20.04 mitcalamares (→ Baustelle/Ubuntu Installation – Gegenüberstellung der Flavours

EDIT.: Derselbe Sch.... in grün (Anhang)

Gruß black tencate

black_tencate schrieb:

Na, dann frag mal die Aktualität der hier bei den usern in Benutzung befindlichen Rechnern. Nach der Logig wäre es konsequent, eine Installation in dem Modus gar nicht erst noch anzubieten.

Für Ubuntu auf jeden Fall. Die Rechner, die so alt sind, das sie noch BIOS haben, die schaffen eh kein *buntu mehr, zumindest nicht nutzbar. Es gibt aber durchaus Gründe, weswegen das noch drin sein könnte, bspw. für Distributionen mit 32bit im Angebot.

Und ob jetzt überall so eine große Affinität und Lust auf EFI besteht, wage ich auch zu bezweifeln.

Gut, der Käse ist gegessen. Da hat MS sich durchgesetzt und jetzt haben wir es. Mittlerweile ja auch gut brauchbar.

es gibt aber schon Gründe, EFI nicht für DAS Allheilmittel für den Bootvorgang zu halten.

Definitiv. Es ist auch kein Allheilmittel, sondern bietet nur dem Betriebssystem noch mehr Kontrollmöglichkeiten. Das kann man auch so und so sehen. Da wir es aber nun sowieso haben und freie BIOS-Versionen nirgends mehr laufen, hilft es auch nichts sich da noch gegen zu wehren — es sei denn da findet jmd. einen Hersteller, der noch sowas anbietet. Purism versucht sich da dran, scheitert aber auch an den üblichen Problemen, außer bei den eigenen Geräten.

1. meine Frage – wenn Du meinst, daß das noch nötig ist – wassollderScheiß?

Ich glaube „wassollderScheiß“ ist kein Supportthema 😀 Das wäre ja wirklich eher Entwicklersache. Ob sich Canonical immer was dabei denkt, lasse ich an der Stelle mal offen 😇

1. alter nurBIOS-Rechner zwar vorhanden, der tut 's aber nur bis kernel 4.13 (oder so ähnlich) teste gerade mit nomodeset

Kommt auf die Komponenten an. Wenn das hauptsächlich sehr gängige Chips/Komponenten sind, kann das funktionieren. Nomodeset ist aber „böse“. Custom Kernel wäre vielleicht interessant. Welche Module der braucht, kannst du ja mit dem 4.13 herausfinden.

1. Lubuntu macht das aber schon seit (min.) 20.04 mitcalamares (→ Baustelle/Ubuntu Installation – Gegenüberstellung der Flavours

Calamares ist wieder was anderes.

Beide sind aber Installer, die es dem Nutzer leicht machen sollen. Da ist ein UEFI-Zwang sinnvoll, da sich Windows sicher nicht mehr im MBR breit macht, sondern UEFI nutzt. Gerade bei Neulingen, die Dual-Boot wollen, ist das wichtig. Und da stimme ich dir zu: Aus den grafischen Installern kann der klassische BIOS-Kram raus. Das schafft nur Unsicherheit und falls wirklich jmd. ein solches Gerät hat, wird der sowieso Hilfe brauchen das lauffähig zu bekommen oder nicht auf einen Installer angewiesen sein.

Hej,

ich hänge hier mal diesen Link an.

Gruß black tencate

ChickenLipsRfun2eat schrieb:

Was ist deine Frage dazu?

Das frage ich mich auch. Auf dem Bild gibt es ja einen "Weiter" Button.

Im Jahr 2022 kann man schon davon ausgehen, das es keine „normalen“ Rechner/Laptops mit BIOS mehr gibt. Es gibt also auch keinen Grund mehr Krückenlösungen wie CSM zu aktivieren.

Im Jahr 2022 kann man schon davon ausgehen, dass es noch haufenweise virtuelle Maschinen mit einem (emulierten) BIOS gib.

Aber ja, für CSM sehe ich im Jahr 2022 auch keine wirkliche Verwendung mehr.

apt-ghetto schrieb:

Das frage ich mich auch…

Das war auf die ursprüngliche Position in den Supportforen gemünzt. Ich hatte gedacht, da fehlt die Frage, bspw. nach einer command line option oder sowas.

Im Jahr 2022 kann man schon davon ausgehen, dass es noch haufenweise virtuelle Maschinen mit einem (emulierten) BIOS gib.

Ja, OVMF wird ja auch erst seit 2012 unterstützt. Das ist natürlich sehr knapp 😉 Erinnert mich an das Geschrei, als GNOME nach 10 Jahren mal seine Richtlinien versucht hat umzusetzen. Es kann immer noch Gründe geben, klar, aber die müssen nicht vom Standard-Installer abgedeckt werden.

Könnte natürlich sein, das da keine Unterscheidung gemacht wird, ob für ARM (IoT) oder AMD64 gepackt wird und daher beides drin ist.

Hej,

dann bleibt die Frage, warum hier in letzter Zeit vermehrt gerade dazu ("This system will likely not be able to boot successfully...") Anfragen aufgetaucht sind?

Es geht (mir) nicht darum, ob CSM sinnvoll ist oder nicht. Es geht! Aber mit der o.g. Stolperfalle.

Im Falle einer "automatischen" (Platte löschen,und Ubuntu installieren) CSM Installation wird eine GPT angelegt und selbverständlich eine dann notwendige bios-boot benutzt. Also, das Wissen (und Erkennen) um die Zusammenhänge liegt ja offensichtlich bei ubiquity vor, warum dann die user in die Irre führen.

Gruß black tencate

Könnte auch der GRUB SECURITY PATCH 116/117 mit der Abschaltung vom os-prober per default mit im Spiel sein?

UEFI and BIOS boot

Other operating systems are not displayed in the boot menu anymore, unless Ubuntu has been installed alongside another operating system. Once all other operating systems are removed from the machine, detection of other operating systems is disabled, and to re-enable if after installing another OS, you will have to delete /boot/grub/grub.cfg and immediately run update-grub again.

Zitat aus:

• Jammy Jellyfish Release Notes

Ich war jetzt doch mal neugierig, bin mir aber noch nicht sicher die richtige Meldung gefunden zu haben. Als Basis habe ich 1444104 entdeckt, der eine ähnliche Nachricht hat. Da wurde wohl eine unglückliche Formulierung noch unglücklicher gestaltet^^

Beim Lesen bin ich übrigens auch über ARM gestolpert, also bietet Ubiquity wohl ein „Rundumsorglospaket“ an, was erklärt, wieso nicht nur noch UEFI unterstützt wird, auch wenn „Desktop“ dransteht.
https://git.launchpad.net/ubiquity/tree/d-i/source/partman-auto scheint es erst seit groovy zu geben, in focal wurde noch mit anderen Listen gearbeitet, es gibt aber für amd64 tatsächlich nur ein -efi-Verzeichnis, in den Standardrezepten scheint eine Boot-Partition auch vorgesehen zu sein. So ganz blicke ich da aber auch nicht durch.

ChickenLipsRfun2eat schrieb:

apt-ghetto schrieb:

Das frage ich mich auch…

Das war auf die ursprüngliche Position in den Supportforen gemünzt. Ich hatte gedacht, da fehlt die Frage, bspw. nach einer command line option oder sowas.

Du hast schon Recht. Die Frage fehlt wirklich.

Im Jahr 2022 kann man schon davon ausgehen, dass es noch haufenweise virtuelle Maschinen mit einem (emulierten) BIOS gib.

Ja, OVMF wird ja auch erst seit 2012 unterstützt. Das ist natürlich sehr knapp 😉

Von wem wird OVMF unterstützt? Meines Wissens nutzen die meisten Virtualisierungen (auch solche, die auf KVM/Qemu basieren) standardmässig nach wie vor BIOS als "Firmware". Und da geschätzte 99% aller VMs nur genau ein System installiert haben, reicht BIOS vollkommen dafür aus.

Und wenn man 100 VMs am Laufen hat und jede davon 100 MiB für die ESP verwendet, dann hat man gut 10 GiB an Speicherplatz verschwendet.

black_tencate schrieb:

Hej,

dann bleibt die Frage, warum hier in letzter Zeit vermehrt gerade dazu ("This system will likely not be able to boot successfully...") Anfragen aufgetaucht sind?

Inwiefern ist die Anzahl von Supportanfragen relevant? Vermutlich ist die Anzahl derer, die in der gleichen Situation keine Supportanfrage stellen, signifikant höher.

Es geht (mir) nicht darum, ob CSM sinnvoll ist oder nicht. Es geht! Aber mit der o.g. Stolperfalle.

Wenn du eine stinknormale Meldung als Stolperfalle ansiehst, dann ist da tatsächlich eine Stolperfalle da. Für die meisten ist es nur eine Meldung, ein Hinweis.

apt-ghetto schrieb:

Von wem wird OVMF unterstützt? Meines Wissens nutzen die meisten Virtualisierungen (auch solche, die auf KVM/Qemu basieren) standardmässig nach wie vor BIOS als "Firmware". Und da geschätzte 99% aller VMs nur genau ein System installiert haben, reicht BIOS vollkommen dafür aus.

Da ich nur qemu/kvm nutze, kann ich das nicht beantworten. Das unterstützt auf jeden Fall ovmf. seabios ist mir zu umständlich für multiboot. Und wieso sollte man pro System 100 MiB für die ESP verwenden, wenn da nur eins installiert ist? Ich bin zwar mit meinen 3-4 VMs nicht representativ, aber ich nutze nur eine ESP für alle VMs — allerdings ohne auch dort liegende Kernel mehrfach zu nutzen. Wenn du nur ein System pro VM installierst, kannst du auf bios/efi verzichten und den Kernel direkt starten, was auch der einfachste Weg für qemu/kvm ist:

1
2
3

<kernel>/kernel/pfad</kernel>
<initrd>/initrd/pfad</initrd>
<cmdline>--kernel--argumente</cmdline>

Inwiefern ist die Anzahl von Supportanfragen relevant? Vermutlich ist die Anzahl derer, die in der gleichen Situation keine Supportanfrage stellen, signifikant höher.

Das gilt wohl für alle Probleme, das die meisten sie nicht haben. So grobe Fehler werden ja von den Tests schon weitreichend abgedeckt.

Wenn Software umgestellt wird, gibt es aber immer mehrfache Anfragen, man siehe sich die Historie von Mir, Upstart, Snap an und die Umstellungen — oder natürlich die Einführung von EFI mit SecureBoot und derlei Scherzen.