[DE] Siduction bootet nicht

[ro_sid]

[...]
anschließend Vorschlag von ro_sid bei gebootetem Mint:
"efibootmgr -v" eingeben

Code: [Select]

BootCurrent: 000F
Timeout: 1 seconds
BootOrder: 000F,000E,000D
Boot000D  Hard Drive BBS(HD,,0x0)..GO..NO........u.S.A.T.A. .S.S.D.....BO..NO........u.C.T.1.2.0.B.X.5.0.0.S.S.D.1.[...]
Boot000E* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........u.H.L.-.D.T.-.S.T. .D.V.D.R.A.M. .G.U.D.0.N..[...]
Boot000F* ubuntu HD(1,GPT,527498fa-fcb5-48af-83b1-2817e4450703,0x800,0x100000)/File(\EFI\Ubuntu\shimx64.efi)..BOhilft das euch weiter?

Mir war ja auch einige Posts vorher aufgefallen, das meine mind. 3SSDs, je nach Bootvorgang anders bezeichnet werden, es wird also mal sda zu sdb, mal sdb zu sdc, mal sdc zu sda >also ganz und gar willkürlich!?

hilft das euch weiter?: Vielleicht zumindest habe ich eine Idee. Doch zuerst die Fakten:

Es gibt (derzeit) nur zwei aktive ('*') Booteinträge. 000E ist ein (vermutlich physisches) CD-/DVD-Laufwerk und wird (hier) wohl weiter keine Rolle spielen.

Bleibt noch 000F hat Mint über den Eintrag "ubuntu" gebootet, was von einer "HD" (auch SSD im Slot 1, GPT-formatiert von der Partition mit der GPT-Id 527498fa-fcb5-48af-83b1-2817e4450703 und dort der Datei /EFI/Ubuntu/shimx64.efi getan wird - die '\' sind die FAT-üblichen MS Pfadtrenner.

Was auffällt: "shimx54.efi" ist die Boot-Datei für "secure boot", die allerdings (per Weiterleitung) auch funktioniert, wenn "secure boot" nicht aktiviert ist. Immerhin wäre das aber möglich und Siduction verfügt bestimmt nicht über solche Kernel. Daher bitte im UEFI-Setup sicherstellen, daß "secure boot" deaktiviert ist. [Das ist allerdings wahrscheinlich, da Siduction ja schon mal erfolgreich gebootet wurde.]

Die Antwort

[...]
Also hier™ auf meinem PC (selbst gebaut, hat genau ein OS und zwar siduction und es war auch nie vorher was anderes drauf), sieht /boot/efi wie folgt aus:

Code: [Select]

# tree /boot/efi/
/boot/efi/
└── EFI
    ├── boot
    │   └── bootx64.efi
    └── siduction_2021.1.1
        └── grubx64.efi
[...]

zeigt, daß die Datei "shimx64.efi" bei Siduction nicht installiert wird. Deren Rolle übernimmt "bootx64.efi", was nicht "secure boot"-fähig ist oder - bei entsprechendem UEFI-Eintrag ein direkter Auruf von "Grub" als - grubx64.efi. Jedoch ist "siduction_2021.1.1" nicht in UEFI und "Ubuntu" nicht auf der Partition.
Es könnte - muß aber nicht(!) - sein, daß alle anderen OS den "Ubuntu-Shim" verwenden und so booten. [Kann man durch Nachsehen auf der jeweiligen EFI-Partition der anderen OS feststellen.]
Was mir in der UEFI-Tabelle fehlt, ist ein Eintrag, der "beliebige" Disks booten soll/kann. Das könnte 000D sein, für mich paßt aber das Muster des Eintrags nicht - etwa BBS; allerdings habe ich da bisher auch keine große Erfahrung (mit anderen Systemen). Bei mir etwa: Boot0022  Other HDD VenMsg(bc7838d2-0f82-4d60-8316c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)

Daher ist es interessant zu sehen, wie "efibootmgr -v" bei erfolgreichem Boot von Siduction aussieht.
Am besten gäbe es einen weiteren(!) Eintrag, der /EFI/siduction_2021.1.1/grubx64.efi zum Inhalt hat. Dieser sollte/darf nicht gelöscht werden! Was dann allerdings die Änderung in den UEFI-Einträgen auslöst, wäre/ist mir noch ein Rätsel.

Wir brauchen neue Einsichten . Viel Erfolg!

[sdjopa]

Update 19:54 Uhr:
also nochmal Siduction im UEFI-mode frisch installiert und efibootmgr -v:

Code: [Select]

BootCurrent: 0000

Timeout: 1 seconds

BootOrder: 0000,000E,000D

Boot0000* siduction     HD(1,GPT,fca9e2ac-4860-6a42-a36e-0c93224d07ac,0x1000,0x96000)/File(\EFI\siduction\grub
x64.efi)

Boot000D  Hard Drive    BBS(HD,,0x0)..GO..NO........u.A.p.a.c.e.r. .A.S.3.4.0. .1.2.0.G.B....................A
.................................>..Gd-.;.A..MQ..L.3.K.6.3.2.3.0.R.1.0.5.1. .3. . . . . . ........BO..NO......
..u.S.A.T.A. .S.S.D....................A.................................>..Gd-.;.A..MQ..L.8.9.0.6.7.0.C.2.A.0
.8.0.0.0.0.0.9.4.5.3........BO..NO........u.S.A.M.S.U.N.G. .S.S.D. .P.M.8.1.0. .F.D.E. .2...5.". .2.5.6.G.B...
.................A.................................>..Gd-.;.A..MQ..L. . . . . . .0.S.8.S.E.N.B.A.0.9.7.3.5.3..
......BO

Boot000E* CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........u.H.L.-.D.T.-.S.T. .D.V.D.R.A.M. .G.U.D.0.N............
........A.................................>..Gd-.;.A..MQ..L.Y.K.J.4.E.9.0.G.4.7. .4. . . . . . . . ...
interessant war, heute nachmittag hieß die vermeintlich leere SSD (zur Installation von Siduction) = sdb, heute abend sda!
Hier liegt sicher der Hase im Pfeffer!?

[unklarer]

Wir brauchen neue Einsichten

Warum?
@towo hat doch schon richtig "orakelt". Ein klein wenig Recherche, z.B. (übersetzt)

Normalerweise ist EFI/ubuntu/grubx64.efi auf der EFI-Systempartition (ESP) die GRUB-Binärdatei und EFI/ubuntu/shimx64.efi ist die Binärdatei für shim. Letzteres ist ein relativ einfaches Programm, das eine Möglichkeit bietet, auf einem Computer mit aktiviertem Secure Boot zu booten. Auf einem solchen Computer lässt sich eine unsignierte Version von GRUB nicht starten, und das Signieren von GRUB mit den Schlüsseln von Microsoft ist unmöglich. shim überbrückt also die Lücke und fügt seine eigenen Sicherheitstools hinzu, die denen von Secure Boot entsprechen. In der Praxis registriert sich shim bei der Firmware und startet dann ein Programm namens grubx64.efi in dem Verzeichnis, aus dem es gestartet wurde. Auf einem Computer ohne Secure Boot (z. B. einem Mac) ist das Starten von shimx64.efi also genau wie das Starten von grubx64.efi. Auf einem Computer mit aktivem Secure Boot sollte das Starten von shimx64.efi zum Starten von GRUB führen, während das direkte Starten von grubx64.efi wahrscheinlich nicht funktionieren wird.

Beachten Sie, dass eine gewisse Zweideutigkeit möglich ist. Insbesondere, wenn Sie einen anderen Bootmanager oder Bootloader als GRUB in einer Secure Boot-Umgebung mit shim verwenden wollen, müssen Sie dieses Programm grubx64.efi nennen, auch wenn es nicht GRUB ist. Wenn Sie also rEFInd auf einem Secure Boot-fähigen Computer installieren, könnte grubx64.efi das rEFInd-Binary sein. Diese Binärdatei würde sich aber wahrscheinlich nicht in EFI/ubuntu befinden; sie und eine Shim-Binärdatei würden wahrscheinlich in EFI/refind abgelegt. Da Sie einen Mac haben (der Secure Boot nicht unterstützt), ist es auch nicht nötig, rEFInd auf diese Weise zu installieren; es ist viel sinnvoller, rEFInd als EFI/refind/refind_x64.efi zu installieren (sein Standardspeicherort und -name).

Quelle
und, es sind alle Klarheiten beseitigt!  

[sdjopa]

update 20:01, Sid. runtergefahren zusätzlich Mint-SSD eingeschoben, gebootet und efibootmgr -v

Code: [Select]

BootCurrent: 0000

Timeout: 1 seconds

BootOrder: 0000,000F,000E,000D

Boot0000* siduction     HD(1,GPT,fca9e2ac-4860-6a42-a36e-0c93224d07ac,0x1000,0x96000)/File(\EFI\siduction\grub
x64.efi)

Boot000D  Hard Drive    BBS(HD,,0x0)..GO..NO........u.A.p.a.c.e.r. .A.S.3.4.0. .1.2.0.G.B....................A
.................................>..Gd-.;.A..MQ..L.3.K.6.3.2.3.0.R.1.0.5.1. .3. . . . . . ........BO..NO......
..u.S.A.T.A. .S.S.D....................A.................................>..Gd-.;.A..MQ..L.8.9.0.6.7.0.C.2.A.0
.8.0.0.0.0.0.9.4.5.3........BO..NO........u.S.A.M.S.U.N.G. .S.S.D. .P.M.8.1.0. .F.D.E. .2...5.". .2.5.6.G.B...
.................A.................................>..Gd-.;.A..MQ..L. . . . . . .0.S.8.S.E.N.B.A.0.9.7.3.5.3..
......BO..NO........u.P.a.t.r.i.o.t. .B.u.r.s.t....................A.................................>..Gd-.;.
A..MQ..L.F.7.4.C.7.0.8.0.7.0.8.0.0.0.0.3.2.3.0.1........BO

Boot000E* CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........u.H.L.-.D.T.-.S.T. .D.V.D.R.A.M. .G.U.D.0.N............
........A.................................>..Gd-.;.A..MQ..L.Y.K.J.4.E.9.0.G.4.7. .4. . . . . . . . ........BO

Boot000F* ubuntu        HD(1,GPT,ed447237-112e-4b39-a404-fc1359824962,0x800,0x100000)/File(\EFI\Ubuntu\shimx64
.efi)..BO

jetzt ist Sid.-SSD als sdc bezeichnet!!

[sdjopa]

update 20:10
Sid. runter gefahren > PC angeschaltet > während des POST F8 zur Auswahl BIOS gedrückt > beide SSD werden angezeigt,
also Siduction-SSD sowie Mint-SSD, mit Cancel Vorgang abgebrochen, PC wird schwarz :
Reboot and install a proper...
ausgeschaltet > wieder eingeschaltet > Siduction bootet normal
mmh?! Sitze gerade hier wie ein Karnickel vorm Fuchs.........

[Mister00X]

Auch wenn das mehr geraten ist, scheint mir das so als würde dein UEFI dich nicht mögen.

Hast du schon mal probiert dein UEFI zu aktualisieren, also falls es eine neuere Version von deiner Firmware gibt?
(Dran denken, Firmware-Updates sind bisschen riskant)

[ro_sid]

@sdjopa: Einen Teil der Erklärung haben wir nun:
Erst gab es nur 0000 (Siduction). Nun ist auch 000F (Mint) da.
Solange beide Einträge vorhanden sind, wird alles gut gehen. Die Frage ist für mich aber: Wie/wodurch kam 000F zustande?
Derselbe Mechanismus könnte, wenn die Siduction-SSD nicht mehr angeschlossen ist, für die Löschung des Eintrags sorgen.
Es könnte auch sein, daß (nach Wechseln) nur eine gewisse Anzahl von Einträgen gleichzeitig möglich ist.
0000 muß erhalten bleiben!

An Siduction (selber) liegt es nicht.

Mit sda/b/c könnte es sich verhalten, wie bei MS mit dem Laufwerk "C:". In einem laufenden(!) System bekommt die root-Disk immer sda, wenn sie zur sd?-Familie gehört und nicht etwa zu nvme oder anderen. Damit müssen andere Disks "ausweichen".
[Im BIOS/UEFI ist das (noch) nicht so; jedenfalls nicht notwendigerweise - dort eh '0', '1', ... siehe HD(1,...).]
Bei als "remote" geltenden Laufwerken muß(!) als Default, solange nichts anderes "greift", (auch) der Pfad /EFI/boot ausgewertet werden. Ich kann aber nicht mit Sicherheit sagen, daß das für alle "Platten" stimmt, etwa für fest eingebaute. Und schon gar nicht, wie sich das mit Wechselfestplatten verhält.

Wir brauchen den Mechanismus, der die UEFI-Einträge (automatisch?) "anpaßt". Das habe ich bisher nicht erlebt.

Nachtrag: Den 0000-Eintrag hat die Siduction-Installation angelegt, genauer der Grub dort; das ist normal!
Gibt es irgendwo eine "Bedienungsanleitung" zum BIOS/UEFI und vor allem zum Softwareverhalten des Wechselplattenrahmens?

[Mister00X]

Mit sda/b/c könnte es sich verhalten, wie bei MS mit dem Laufwerk "C:". In einem laufenden(!) System bekommt die root-Disk immer sda, wenn sie zur sd?-Familie gehört und nicht etwa zu nvme oder anderen. Damit müssen andere Disks "ausweichen".

Den Punkt kann ich aufklären:

<klugscheißermodus>
Meines Wissens nach werden die Laufwerke in der Reihenfolge benannt in der Sie "auftauchen".
Sprich, wenn der Kernel bootet sucht er erstmal nach allen verfügbaren Laufwerken und nummeriert sie (also (sd)a,b,c usw. für SATA und SCSI; (hd)a, b, c usw. für PATA; nvmeX für nvme namespaces) in der Reihenfolge in der sie "auftauchen", heißt langsame Laufwerke bekommen eine/n höhere/n Nummer/Buchstaben. Ich habe da z. B. ein Debian-System indem die Platte mit dem Root-Dateisystem immer sdb ist weil die einfach langsamer (da älter) ist. Wenn die Platten ungefähr gleich schnell sind dann können die mit jedem Bootvorgang wechseln.

Man kann sich auf jeden Fall NIE auf den Buchstaben verlassen, weshalb man immer UUIDs, LABELs, PARTUUIDs, PARTLABELs oder bei lvm den Pfad zum Logischen Laufwerk (/dev/vg*/lv* oder /dev/mapper/vg*-lv*) für die fstab nehmen sollte.
</klugscheißermodus>

[sdjopa]

.....bleibt festzustellen daß entweder Calamares SiductionOS anders auf dem PC installiert oder
Siduction andere Vorraussetzungen für einen reibungslosen Start/Gebrauch nötig hat als z.B.
Mint, Kubuntu, Garuda...
Das von mir geschilderte Problem tritt nur bei Siduction auf!!
Eine Lösung finde ich und auch die vielen Helfer hier auf diesem Wege sicher nicht!?
Trotz weiter bestehender Probleme möchte ich mich bei Allen sehr bedanken,
ich werde das Thema mal schließen.
vielen Dank nochmal Grüße sdjopa

[sdjopa]

Update: so lange die Siduction-SSD angeschlossen/verbunden bleibt, kann ich immer wieder Siduction booten.
Wenn ich aber die Sid.-SSD abziehe ein anderes OS boote, nach Gebrauch runterfahre und dann wieder Siduction anschließe
und booten will startet Siduction nicht mehr...Jemand eine Idee was da falsch/anders läuft?