staging.inyokaproject.org

black_tencate schrieb:

das bekannte ubiquity Verhalten

Der Threadstarter nutzt aber Lubuntu, da ist nichts mit diesem Ubiquity-Mist, verwendet wird Calamares.

black_tencate schrieb:

Die Frage kann ich Dir leider nicht beantworten

mit 22.04.2 ist es auf alle Fälle noch so, daß, wenn man (im CSM) "Platte löschen und installieren" wählt, die Installation am Ende in beiden Modi lauffähig ist (das bekannte ubiquity Verhalten).

Ich habe es nach wie vor praktisch nicht getestet, würde aber mutmaßen, dass sich an dem Verhalten bei der Installation nichts ändert. Das Problem hat ja mit dem eigentlichen Live-System nichts zu tun. Es handelt sich ja um ein Erkennungsproblem des USB-Ubuntu-Mediums seitens der Firmware. Um das noch mal genauer zu erklären (damit nachfolgende Leser auch nachvollziehen können, wie sich das Problem äußert):

• CSM/Legacy/BIOS-Boot ist auf dem System in der Firmware aktiviert

• Im Firmware-Boot-Menü wird der USB-Stick auch zweimal angezeigt - also einmal als UEFI-Boot-Option und einmal als Legacy-Boot-Option

• Wählt man den Stick in der Legacy-Variante zum Start aus, dann erhält man von der Firmware nach etwas Wartezeit

  Error: No boot disk has been detected or the disk has failed.

  Die Fehlermeldung kann je nach Firmware sicherlich auch abweichen.

• Die UEFI-Boot-Variante des Sticks startet aber ohne Probleme

Übrigens ist es bei meinem "Problem"-System so - und das klingt auch bei genauem Lesen in dem launchpad-Thread oben an - dass das Lubuntu 22.04.X-ISO von DVD im BIOS-Boot-Modus startet. Wer von dem Problem betroffen ist, kann also gegebenenfalls auch auf die Verwendung einer DVD zurückgreifen. Bei Lubuntu reicht dafür eine normale DVD für Ubuntu bräuchte es aber schon eine Double-Layer-DVD.

Ich habe das Problem übrigens so gelöst, dass ich bei dem USB-Stick die GPT mit Hilfe von gdisk in eine MPT gewandelt und dann mittels fdisk die erste Partition in der MPT aktiv gesetzt habe, also:

sudo umount /dev/sdX*
sudo gdisk /dev/sdX

Innerhalb des interaktiven gdisk dann der Reihe nach folgende Tasten drücken:
p (damit überprüft man zur Sicherheit noch mal, dass man den richtigen Datenträger ausgewählt hat). Der Ubuntu 22.04.2-Stick sieht dann bezüglich des Partitionslayouts z.B. so aus:

...
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): A0891D7E-B930-4513-94D9-F629DBD637B2
Partition table holds up to 248 entries
Main partition table begins at sector 2 and ends at sector 63
First usable sector is 64, last usable sector is 9624128
Partitions will be aligned on 4-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         9613459   4.6 GiB     0700  ISO9660
   2         9613460         9623527   4.9 MiB     EF00  Appended2
   3         9623528         9624127   300.0 KiB   0700  Gap1

Dann geht es mit folgenden Tasten weiter:
r
g
w

Anschließend dann:
sudo fdisk /dev/sdX

Innerhalb des interaktiven fdisk dann der Reihe nach folgende Tasten drücken:
a
1
w

Fertig! 

WICHTIG: sdX muss dabei selbstverständlich an das eigene System angepasst werden und steht für den Ubuntu-USB-Stick!

Bei meinem Problem-System startet der so veränderte Stick dann im BIOS- und im UEFI-Boot-Modus. Eine Installation von dem Stick habe ich bisher dabei noch nicht durchgeführt, gehe aber nicht davon aus, dass diese scheitern würde.

LG, Newubunti

Hej Newubunti,

Newubunti schrieb:

... Ich habe das Problem übrigens so gelöst, dass ich bei dem USB-Stick die GPT mit Hilfe von gdisk in eine MPT gewandelt und dann ...

kann man machen, von hinten durch die Brust ins Auge *grins*.

Dann doch lieber gleich EWMS oder Ventoy.

Werde dann wohl mal Übersicht Live-USB anpassen.

Gruß black tencate

black_tencate schrieb:

kann man machen, von hinten durch die Brust ins Auge *grins*.

Naja, IMO berücksichtigst Du dabei aber nicht, dass der Stick bereits fertig vorlag. Der ganze geschilderte Vorgang des Wandelns dauert insgesamt vielleicht 15 Sekunden; hängt auch etwas von der eigenen Tipp-Geschwindigkeit ab. Wenn man das das erst mal macht, dauert es entsprechend länger. Das gilt aber für EWMS und Ventoy ebenso.

Bei mir geht - für diesen speziellen Fall, dass man den Stick mit dd oder Startmedienersteller nun schon mal vorliegen hat - jedenfalls keine andere Methode schneller.

Informiert man sich im Vorfeld und hat noch kein fertiges Medium vorliegen, dann sieht das mit den Zeiten unter Umständen anders aus. Außerdem hängt es auch davon ab, ob man das Live-Medium ständig nutzt oder nur mal alle paar Jahre.

Ich persönlich finde es halt immer praktisch, wenn ich nicht erst irgendetwas installieren muss, aber das ist letztlich nur eine Frage persönlicher Präferenzen und keine Frage von "besser" oder "schlechter". Viele Wege führen bekanntlich nach Rom!

Also nichts gegen EWMS oder Ventoy!

LG, Newubunti

So, wollte mich nochmal kurz zu Wort melden.

Also erstens - größere SSD: warum? Der Platz der /home - Partition wird im Leben nicht ausgereizt! Da sind ein paar Bilder drauf, da sind ein paar Textdateien drauf, fertig. Nochmal: es ist der Rechner meiner Schwiegermutter, die Frau (ü70) macht nichts weiteres wie ab und zu mal im Internet was bestellen (lassen, weil sie's selber geistig nicht hinbekommt), die Vermeldungen der örtlichen Pfarrgemeinde ausdrucken, ihre eMails abrufen. Da würde normalerweise ein Minimalstsystem reichen!

Und nein, mit einem Tablet würde die Frau garantiert nicht zurechtkommen (das Smartphone ist ja schon kritisch)...

Warum nur 20 GB für / ? Nun, bei 20.04 waren's noch weniger (glaube 16 GB, bin mir aber nicht mehr sicher), und da hat's dicke gereicht. Außer den Programmen, die bei einer Standartinstallation eh drauf sind, ist zusätzlich nur Thunderbird drauf. Vielleicht schmeiße ich von den Programmen, die drauf sind, noch was runter. Die komplette LibreOffice-Suite z. B. - Abiword würde dicke reichen (wenn was geschrieben werden muß, müssen sowieso wir das das machen)...

Kritik an Ubuntu - lese ich immer öfters. Wechseln - zu was denn? OpenSuse? Mageia habe ich schon öfters positives gelesen, mich aber noch nicht mit befasst.

Alter der Legacy-Version - nun, beim Startbildschirm wird mir was von 2012 angezeigt. Ist mir aber auch wurst, solange das System läuft.

Thomasbaerteddy schrieb:

größere SSD: warum? (...) Warum nur 20 GB für / ? Nun, bei 20.04 waren's noch weniger (glaube 16 GB, bin mir aber nicht mehr sicher), und da hat's dicke gereicht.

Es ist Dir erklärt worden, Du mußt auch mal lesen.

Man kann mit 20 GiB für / hinkommen, aber da ist stetige Systempflege mit Wissen um die Materie angesagt, sprich Aufräumen (deb und vor allem snap, letzteres explodiert geradezu).

Du kannst die Ratschläge auch in den Wind schießen, nur brauchst Du da auch nicht mehr fragen - und wenn sich das herumspricht, bekommst Du auch keine Antworten mehr, da sich die Mühe bei Dir nicht lohnt.

Standartinstallation

Standard

Newubunti schrieb:

black_tencate schrieb:

Bei nur Legacy bootet er vom Stick nicht, bei nur UEFI kann ich ihn nicht auswählen.

für einen mit Startmedienersteller hergestellten Stick nicht glaubhaft, da so ein Stick eben beide Modi beherrscht.

Einspruch!

Stattgegeben! Zwar sollte ein solcher Stick beide Modi beherrschen, und früher war das auch so, aber heutzutage trifft es leider nicht mehr zu.

Ich habe mir einmal ein Ubuntu-22.04.1-ISO-Abbild und ein Lubuntu-22.04.2-ISO-Abbild angeschaut:

• Im Sektor 0 gibt es den MBR-Loader von GRUB und eine Protektive-MBR/DOS-Partitionstabelle (also nur ein Eintrag für eine Pseudo-Partition über das gesamte Abbild)

• ab Sektor 1 gibt es eine GPT-Partitionstabelle für maximal 248 (!?) Einträge und tatsächlich 3 Partitionseinträgen, von denen keine als legacy-bootbar markiert ist:

  • das zu startende eigentliche Betriebssystem

  • eine EFI-Systempartition

  • eine als Gap1 bezeichnete Partition für was auch immer

Ein Datenträger mit solcher Struktur kann im Bios-Modus nicht starten. Der Bootmanager in der Rechner-Firmware wird zwar im Bios-Boot-Modus die erste Stufe von GRUB starten, dieser findet aber in der MBR/DOS-Partitionstabelle keine Partition, aus der er seinen weiteren Code laden könnte und stürzt daher ab.

Leider scheint es so zu sein, dass bei aktuellen Ubuntu-Hybrid-Startmedien "Hybrid" nur noch bedeutet: „Kann von Festplatte/USB-Stick/SSD im EFI-Modus starren und kann vom optischen Datenträger im CD-Modus starten“ (ob das Bios-CD-Modus oder EFI-CD-Modus oder beides bedeutet, lasse ich offen).

Ob dieser Verzicht auf die Legacy-Bootbarkeit der Ubuntu-Startmedien nun Absicht oder ein Fehler ist, bleibt offen. Dumm ist es auf jeden Fall, auf eine Funktionalität zu verzichten ohne dafür einen erkennbaren Vorteil zu erhalten.

Hallo kb,

kB schrieb:

... Der Bootmanager in der Rechner-Firmware wird zwar im Bios-Boot-Modus die erste Stufe von GRUB starten, dieser findet aber in der MBR/DOS-Partitionstabelle keine Partition, aus der er seinen weiteren Code laden könnte und stürzt daher ab.

Wie kommst Du darauf bzw. wie weit ins Detail hast Du das untersucht?

Denn:

Für GRUB selbst, spielt es zunächst grundsätzlich keine Rolle, ob irgendwo eine Partition in der Partitionstabelle verzeichnet ist oder nicht. Der Code von GRUB im MBR - seit GRUB 2 als boot.img bezeichnet - enthält einfach eine Blocksprung-Anweisung. D.h. da steht im Prinzip: "Fahre mit dem Laden von Code in den Speicher mit Sektor X fort". Siehe:

https://www.gnu.org/software/grub/manual/grub/grub.html#Images, dort zu boot.img.

Wenn man außerdem die Threads

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1883040

betrachtet, dann kann man da herauslesen, dass nicht grundsätzlich alle Systeme mit BIOS-Boot(-Modus) betroffen sind bzw. sein sollen.

Das spricht eher dafür, dass es an der Art der Implementierung seitens der Firmware liegt.

In der Windows-BIOS-Boot-Modus-Welt und ich glaube auch nach ursprünglicher IBM-kompatibler Spezifikation ist es AFAIK ursprünglich so, dass nur von einer der Primär-Partitionen einer MPT gebootet werden kann, von welcher wird dabei durch die Boot-Markierung (Active-Flag) gekennzeichnet.

Hält sich eine Firmware streng an diese Maßgabe, dann kann es möglich sein, dass der IPL aus dem MBR gar nicht erst geladen wird. Ich meine mich erinnern zu können, dass es zu GRUB-Legacy- und reinen BIOS-Zeiten schon gelegentlich das Problem gab, dass auf einigen Systemen für Linux die aktiv-Markierung gesetzt werden musste, obwohl von Linux-Bootmanagern - oder zumindest von GRUB - gar nicht gefordert.

Die bei meinem Problem-System ausgegebene Fehlermeldung klärt diese Frage aber nicht eindeutig, weil es AFAIK so ist, dass die Meldung

Error: No boot disk has been detected or the disk has failed.

zwar von der Firmware kommt, aber auch ausgegeben wird, wenn bereits der IPL bei der Ausführung scheitert und deswegen an die Firmware zurückgibt.

Bei GRUB-Legacy war es so, dass bei Offset 0040h im MBR stand, ob der GRUB-IPL von dem selben oder einem anderen Datenträger Stage 1.5 oder Stage 2 nachlädt und bei Offset 0044h-0047h stand dann in Little Endian die LBA bzw. der Sektor von Stage 1.5 oder 2.

Bei GRUB 2 haben sich die Offsets AFAIK geändert. Ich habe das noch nicht weiter untersucht.

Hast Du das bei Deiner Betrachtung untersucht?

Ob dieser Verzicht auf die Legacy-Bootbarkeit der Ubuntu-Startmedien nun Absicht oder ein Fehler ist, bleibt offen. Dumm ist es auf jeden Fall, auf eine Funktionalität zu verzichten ohne dafür einen erkennbaren Vorteil zu erhalten.

Also laut launchpad Thread https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308 und dort explizit Post #10 scheint es so zu sein, dass es neue Firmware-Implementierungen zu geben scheint, die mit dem alten MAC-Partitionstabelle-Hybrid-ISO Probleme haben und dann gibt es eben Alt-Systeme - wobei nicht alle betroffen sein sollen - die im BIOS-Boot(-Modus) mit dem neuen ISO nicht klarkommen.

Warum man von syslinux weg wollte, steht zumindest ansatzweise in dem folgenden Post: https://askubuntu.com/questions/1289400/remaster-installation-image-for-ubuntu-20-10/1289505#1289505

Also finde ich die These "ohne dafür einen erkennbaren Vorteil zu erhalten" ein wenig steil.

Man muss auch einfach mal ein praktisches Problem dabei berücksichtigen:

Anno 2023 ist es praktisch ziemlich schwer, die Kompatibilität hinsichtlich reiner BIOS-Systeme oder hinsichtlich UEFI-Systemen, deren BIOS-Boot-Implementierung eine fehlerhaft oder streng ist, zu berücksichtigen. Die Macher des ISO müssten dazu selbst über solche Systeme verfügen, was eben mit fortschreitender Zeit immer unwahrscheinlicher wird.

LG, Newubunti