Siduction Forum
Siduction Forum => Installation - Support => Topic started by: sdjopa on 2023/04/12, 08:06:17
-
Hallo allerseits, SiductionKDE frisch installiert und schon Probleme!?
Nach mehrstündiger Benutzung und Updates bleibt beim nächsten boot PC bei Meldung stehen ich möge bootbares Medium einlegen...SSD, Anschlüsse und Bios sind i.O.
Vom parallel laufenden OS kann ich auf nicht bootbare SSD zugreifen, also auch kontrollieren ob was nicht stimmt!? Hat jemand eine Idee wie ich hier auf Fehler- Reparatursuche gehen könnte?
Auf meinem Laptop genauso installiertes Siduction läuft dagegen einwandfrei, bin ratlos.
Siduction ist eine Super OS die ich gerne weiterhin benutzen würde...
Grüße sdjopa
-
Sei Willkommen! :)
Das kann unterschiedliche Ursachen haben.
Von, 'Fehler bei der Installation' bis, 'du hast vergessen, den Hauptbootloader zu aktualisieren' ist alles möglich.
Du schreibst auch nicht, ob nach der Installation siduction bereits einmal gebootet wurde.
Vielleicht magst du uns die Ausgabe des Befehl
parted -ldeines System zeigen?
-
Klingt alles stark danach, nicht im EFI Modus installiert zu haben und dann kein Bootflag gesetzt.
-
Hallo,
PC/Bios erkennt SSD mit installiertem SiductionOS wohl nicht, Bildschirm schwarz anschließend:
>reboot and select proper boot device or insert boot media in selected boot device and press a key issue<
von parallel eingegsteckter und gebooteter(Mint) SSD kann ich die Siduction-SSD allerdings öffnen!
-ja, mehrmals nach Update gebootet, am nächsten Tag = Fehlermeldung s.o.
-ja, ich habe im UEFI installiert = immer noch rat- und hilflos...jemand eine Idee?
Sicher noch mehr Infos meinerseits nötig?!
Grüße
-
Hallo nochmal, soeben Siduction nochmal mit Calamares neu installiert, geupdated und anschließend neu gestartet.
Ganze 120GB SSD für System verwendet!
Hier nun Ausgabe von parted -l
@SiductionPC:~$ parted -l
Der Befehl »parted« ist an den folgenden Orten verfügbar
* /sbin/parted
* /usr/sbin/parted
Der Befehl konnte nicht gefunden werden, weil »/sbin:/usr/sbin« nicht Teil der Umgebungsvari
able PATH ist.
Höchstwahrscheinlich besitzt Ihr Benutzerkonto keine Systemverwaltungsrechte.
parted: Befehl nicht gefunden.
Benutzerkonto hatte ich von Standard auf Systemverwalter geändert!
Hier scheint aber wohl was zu fehlen?! Hilfe erwünscht
-
Nochmal hallo,
soeben übers Terminal Thunderbird installiert, am Ende des Installationsprozesses erscheint unter anderem:
Fehler beim Ermitteln von verfügbaren Prozessor Mikrocode-Upgrades.wäre das eine mögliche Fehlerquelle?
Grüße
-
Hallo!
Hallo allerseits, SiductionKDE frisch installiert und schon Probleme!?
Nach mehrstündiger Benutzung und Updates bleibt beim nächsten boot PC bei Meldung stehen ich möge bootbares Medium einlegen...SSD, Anschlüsse und Bios sind i.O.
Vom parallel laufenden OS kann ich auf nicht bootbare SSD zugreifen, also auch kontrollieren ob was nicht stimmt!? Hat jemand eine Idee wie ich hier auf Fehler- Reparatursuche gehen könnte?
Auf meinem Laptop genauso installiertes Siduction läuft dagegen einwandfrei, bin ratlos.
Siduction ist eine Super OS die ich gerne weiterhin benutzen würde...
Grüße sdjopa
In der Tat ist es ohne weitere Information nicht leicht zu sagen, was das Problem ist.
Man kann ja aber schon einmal Grundlegendes testen: Wenn man den PC beim Starten in den Modus "Boot von ausgewähltem Gerät" (oft durch Drücken der Taste F10 oder F12 zu der Zeit zu der man auch ins "Setup" gehen kann) versetzt, kann man feststellen, ob die betroffene SSD überhaupt ausgewählt werden kann. Falls nicht, läge es nicht an der Siduction-Installation, sondern an der SSD selbst.
Eine weitere Idee, falls die Hardware vorhanden ist: Es gibt "Gehäuse" mit denen man SSDs als USB-Geräte anschließen und booten kann. Damit fiel es mir immer leicht(er), Boot-Probleme zu lösen, da man Dinge damit schneller ändern und ausprobieren kann. Auch werden die SSDs dann als /dev/sdx und nicht /dev/nvme angesteuert, womit andere Kerneltreiber involviert sind.
Viel Erfolg!
-
Fehler beim Ermitteln von verfügbaren Prozessor Mikrocode-Upgrades.wäre das eine mögliche Fehlerquelle?
Nicht unmöglich, aber eher nicht.
-
Benutzerkonto hatte ich von Standard auf Systemverwalter geändert!
Ich bin mir nicht sicher, ob das "reicht" um auch den Pfad (PATH) zu ändern (echo $PATH). Die Rechte sollten dann aber vorhanden sein. parted einfach mal als "/sbin/parted ..." aufrufen.
Leichter erscheint mir zu sein, sich mit "su -" zu "root" zu machen.
Hier scheint aber wohl was zu fehlen?! Hilfe erwünscht
Hmm, auf jeden Fall muß man sich nach so einer Änderung aus dem Konto aus- und wieder einloggen!
-
siehe unten
-
hier mal parted als root
root@SiductionPC:~# parted -l
Model: ATA Apacer AS340 120 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2097kB 317MB 315MB fat32 boot, esp
2 317MB 120GB 120GB btrfs root
Model: ATA SAMSUNG SSD PM81 (scsi)
Disk /dev/sdb: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 256GB 256GB ext4
Model: ATA SATA SSD (scsi)
Disk /dev/sdc: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 128GB 128GB ext4wie bereits erwähnt ist
sda die SystemSSD ,per hotplug wechselbar, sdb und sdc meine "immer wieder verfügbaren" Daten + Sicherung
jemand einen Fehler bisher gefunden?
-
Hmm. Parted liefert (mir) keine Erkenntnisse, die Partitionierung - es interessiert hier ja nur sda - ist in Ordnung und vom Prinzip her (U)EFI-bootbar.
Mir ist vom root@SiductionPC:~# parted -l her nicht klar, wie diese Ausgabe zustande kommt. Hier scheint "Siduction" doch zu laufen oder ist es Mint?
Falls es Siduction ist, wie wurde es gebootet? Das sollte doch das Problem sein.
Falls es Mint ist, wieso ist sda dann die Siduction-SSD? Man kann einem laufenden System (Mint) ja nicht seinen System-Datenträger entziehen.
Wie bootete das System, als es früher noch problemlos klappte? Grub? Oder direkt aus UEFI heraus mit entsprechendem Eintrag in den UEFI-vars? Daß "Secure-Boot" derzeit nicht(!) aktiviert ist, darf ich doch voraussetzen?
Manchmal entwickelt auch die UEFI-Boot-Partition (hier sda1) einen Dateisystemfehler (FAT32), indem z.B. die beiden FATs nicht übereinstimmen. Das kann man bei nicht(!) gemounteter Partition mal mit "fsck /dev/sda1" testen.
Mehr fällt mir augenblicklich und ohne weitere Information leider nicht dazu ein.
-
ja, im Moment läuft und bootet Siduction problemlos.
Das Problem tritt am nächsten Tag (also evtl. heute) oder später auf,
in dem mir
>reboot and select proper boot device or insert boot media in selected boot device and press a key issue<
angezeigt wird!?
Also wird ab und an Siduction-SSD nicht gefunden, auch keine Anzeige/Auswahl im BIOS!
Wenn ich aber anschließend im gleichen hotplug-Einschub eine Mint-SSD mit boote, klappt das einwandfrei.
Das Problem tritt bislang auch nur bei Siduction auf, alle anderen von mir getesteten Distros,
egal ob Arch-, Debian- oder ...basiert funkionieren einwandfrei,
auch mit der gleichen SSD auf der Siduction installiert war, also an der Hardware sollte es nicht liegen!?
Booten tue ich ohne eine weitere Auswahl zutreffen, automatisch im Grub wie installiert.
Bin da nach wie vor ratlos, wie teste ich denn -heute nachmittag- "fsck /dev/sda1" ?
-
Einfache Dinge zuerst ;):
Bin da nach wie vor ratlos, wie teste ich denn -heute nachmittag- "fsck /dev/sda1" ?
Falls von Siduction gebootet, nur darauf achten, ob sda1 "gemountet" ist - etwa per "mount"-Befehl. Falls beim "mount" sda1 nicht aufgeführt wird ist es in Ordnung. Sonst (als "root") "umount /dev/sda1" ausführen.
Danach (als root) "fsck /dev/sda1" (das Dateisystem sollte automatisch erkannt werden). Nötigenfalls "fsck -t vfat /dev/sda1".
Werden Fehler gemeldet, werden sie standardmäßig allerdings nicht(!) repariert. Zum Reparieren bitte die Manualpage durchlesen ("man fsck.vfat") und sich die Optionen ansehen; meist ist dann "-r" eine angemessene Wahl.
Falls nicht von Siduction gebootet - etwa Mint -, dann analog verfahren, aber sda1 durch die Wahl des richtigen Geräts (sd?1) ersetzen. Automatisch gemountet ist es dann höchstwahrscheinlich sowieso nicht, aber man kann natürlich auch das vorher überprüfen.
auch mit der gleichen SSD auf der Siduction installiert war, also an der Hardware sollte es nicht liegen!?
Nein, sieht dann zunächst nicht so aus, allerdings darf das ...
Also wird ab und an Siduction-SSD nicht gefunden, auch keine Anzeige/Auswahl im BIOS!
... in so einem Fall auch nicht passieren, denn bei der Auswahl "Boot from Device" muß - nach meiner Erinnerung - jede(!) potentiell bootfähige Hardware aufgeführt werden, auch wenn es darauf nichts zu booten gibt. Ich werde das aber später an meinem Gerät noch mal verifizieren - und dies widerrufen, falls es nicht stimmt :).
Der versprochene Nachtrag: Ich muß nichts widerrufen - Gott sei Dank. Sogar eine "leere", nicht mal partitionierte SSD wird von UEFI/BIOS bei "Boot from Device" angeboten. Sie war, wie oben beschrieben, über ein USB-Gehäuse angebunden. Wenn man dieses Gerät auswählt, landet man nach kurzer Zeit wieder bei diesem Bildschirm.
-
mmmh hier ist was äußerst seltsam:
gerade mit Entsetzen festgestellt, das die Bezeichnungen meiner SSDs bei/nach jedem booten wechseln!?
Mal ist die Sid-SSD = sda, mal sdb und dann mal als sdc bezeichnet!
Kann sowas sein, liegt evtl. hier der Hase im Pfeffer?
3 SSDs habe ich insgesamt verbaut,
normalerweise sda für System, sdb = Daten, sdc = Sicherung
Per hotplug habe ich zwei externe SSD-Einschübe zum schnellen wechseln auf Mainboard-Steckplatz
1 (System) und 2 (Reserve),
zwei interne Plätze sind sind für Daten und Sicherung auf Sata-Plätze 5 und 6 gelegt/gesteckt.
Das gestern neu installierte Sid. hatte ich auf der ersten SSD -also sda- installiert und fährt bis jetzt jedesmal zuverlässig hoch, aber ein mulmiges Gefühl bleibt....
-
Bist du inzwischen im Siduction-Manual schon bis zum Thema UUID vorgestoßen? Dort solltest du eine Antwort auf deine Katastrophen finden.
edlin
-
Mal ist die Sid-SSD = sda, mal sdb und dann mal als sdc bezeichnet!
Kann sowas sein, liegt evtl. hier der Hase im Pfeffer?
Bei drehenden Festplatten - alle fest eingebaut - habe ich das schon erlebt, insbesondere wenn diese an verschiedenen Controllern angebunden waren. Dabei liegt es am "ready"-Status, was ich auf das unterschiedlich schnelle "Hochdrehen" der Platten geschoben habe. Die Reihenfolge am selben blieb immer erhalten. Die in diesem Sinn schnellste Platte eines Controllers hat immer das Rennen für alle Platten dieses Controllers gemacht. Bei SSDs würde ich das Verhalten nicht erwarten, sie sind ja nach dem elektrischen Einschalten sofort "ready", kann es aber auch nicht ausschließen.
Falls das Nicht-Booten das nächste Mal passiert, würde ich die "anderen" sd? durchprobieren. Falls das funktioniert ist die Abhilfe das Eintragen der UUID - oder, was ich lieber mache, LABEL zu vergeben und deren Namen einzutragen. Beide Vorgehensweisen sind natürlich generell eine gute Idee :).
-
Vielen Dank an Alle mal bis hierhin,
einiges angelesen und ausprobiert,
im Moment scheint da nix zu mucken, will heißen bootet jedesmal nach dem Einschalten,
läuft jetzt auch aber erst zwei Tage nach Installation ich werde evtl. berichten....
Gibt 's noch ein Tipp fürs labeling?
Grüße sdjopa
-
zeig mal cat /etc/fstab
von allen eingebauten/angeschlossenen Medien/Partitionen
-
Hallo, wie gewünscht
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=9468-6DD9 /boot/efi vfat umask=0077 0 2
UUID=9146ce8d-301e-4f95-83d9-eb458e9ed989 / btrfs subvol=/@,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=9146ce8d-301e-4f95-83d9-eb458e9ed989 /.snapshots btrfs subvol=/@snapshots,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=9146ce8d-301e-4f95-83d9-eb458e9ed989 /home btrfs subvol=/@home,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=9146ce8d-301e-4f95-83d9-eb458e9ed989 /root btrfs subvol=/@root,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=9146ce8d-301e-4f95-83d9-eb458e9ed989 /var/log btrfs subvol=/@var@log,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
hier dürften allerdings noch die beiden SSDs für Daten und Sicherung fehlen, die beiden werden nicht automatisch eingehängt!
Disk /dev/sdb: 119,24 GiB, 128035676160 bytes, 250069680 sectors
Disk model: SATA SSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 13F354D3-DE0D-432C-B2D7-0191790088FA
Device Start End Sectors Size Type
/dev/sdb1 2048 250068991 250066944 119,2G Linux filesystem
Disk /dev/sdc: 238,47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG SSD PM81
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 86F483D1-60F4-416E-968A-B558300912B0
Device Start End Sectors Size Type
/dev/sdc1 2048 500117503 500115456 238,5G Linux filesystem
Grüße sdjopa
-
Hallo allerseits, Super-DAU/GAU eingetroffen:
nach entfernen der SID.-SSD und wieder einschieben in den HOTPLUG-Einschub
findet PC die SSD nicht mehr!
Anzeige am Monitor:
>Reboot and Select proper Boot device or Insert Boot media in selected Boot device and press a key<
Wie gesagt das passiert ausschließlich mit den SSDs auf denen Siduction installert ist?!
Wenn ich Sid._SSD im Einschub lasse, findet PC die SSD mit installiertem Siduction.
Arch- Mint- oder ...andere OS kann ich so oft wie gewünscht ein- und wieder ausstecken! Echt seltsam..🤔
Jemand eine Idee? Grüße sdjopa
-
@sdjopa kann es sein, dass dein UEFI/BIOS secure boot wieder aktiviert hat?
Oder kann es alternativ sein, dass deine SSD defekt ist? Ist das eine SATA SSD oder eine NVMe SSD?
-
...nein, die Sata-SSD ist nicht defekt und -ebenfalls nein- secure boot ist auch nicht wieder aktiviert!
Wie bereits erwähnt geschieht das Szenario nur wenn ich die Sid.-SSD entferne und wiedereinstecke!
-
Nuja, ich würde mal orakeln, dass die PC-Firmware den EFI Booteintrag für Siduction Rausschmeisst, wenn Du diese Platte entfernst und mit einer Anderen Platte Bootest.
Vielleicht bootest Du die anderen Systeme ja im CSM Mode.
Wir wissen es nicht, weil nur Du vor der Kiste hockst und wissen kannst, was Du wie gemacht hast.
-
....CSM Mode, das ist es wohl, steht auf Auto.
Bisher habe ich nirgends ein Hinweis gefunden, das der deaktiviert werden muss?!
Warum laufen die anderen Distris denn problemlos?
-
Warum laufen die anderen Distris denn problemlos?
Weil die vielleicht im BIOS, aka CSM Mode installiert sind?
Ganz ehrlich, woher sollen wir das wissen?
-
....CSM Mode, das ist es wohl, steht auf Auto.
Bisher habe ich nirgends ein Hinweis gefunden, das der deaktiviert werden muss?!
Warum laufen die anderen Distris denn problemlos?
Muß er vielleicht nicht. Bei meinem Thinkpad gibt es (zusätzlich) die Option "EFI first" oder "BIOS first". Falls beides "vorhanden" ist, aber nur ein Modus - hier der falsche - funktioniert ...
Leichter würde es, wenn bei auch eingesteckter Siduction-SSD "grub" zur Verfügung stünde, z.B. per Mint oder so. Dann kann man an der Stelle des Boot-Menüs per "c" in einen command-line-Modus gehen. Dort kann man per 'ls' festellen, welche Disks "existieren", per Wahl einer Root-Partition (set root=) diese untersuchen und ermitteln, wie der Zustand ist.
A propos, welchen "Buchstaben" (/dev/sd?) hat denn die Siduction-SSD nach dem "Swap"? Das ging doch auch (mal) durcheinander.
-
@towo: hast wohl keine Geduld mit mir, frag mich doch bitte wenn du noch was wissen musst, genau dafür ist diese Seite doch da?!
@ro_sid: da werde ich mal was ausprobieren, vielen Dank
wäre schade wenn ich die tolle Distri nicht lauffähig halten könnte. Grüße
-
evtl. könnte Dir dieses Posting weiterhelfen:
https://forum.manjaro.org/t/calamares-fails-to-install-boot-on-efi-partition/62630
im Text-Bereich zu finden bei:
in your UEFI motherboard
disable secure boot
disable fast boot
disks on AHCI
no legacy
no CSM
UEFI only or others ( not windows )
-
Das bringt auch nicht viel!
Es ist halt keine so dolle Idee, einem System eine Platte wegzunehmen, auf der die EFI Partition drauf ist.
-
Zeig doch mal die /etc/fstab von einem System welches nach dem Austausch und wieder Einschub bootet.
-
hier mal parted als root
root@SiductionPC:~# parted -l
Model: ATA Apacer AS340 120 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2097kB 317MB 315MB fat32 boot, esp
2 317MB 120GB 120GB btrfs root
wie bereits erwähnt ist
sda die SystemSSD ,per hotplug wechselbar, sdb und sdc meine "immer wieder verfügbaren" Daten + Sicherung
jemand einen Fehler bisher gefunden?
-
Hallo,
hier fehlt meiner Meinung nach eine Partition. Siehe Nr.2 "BIOS_GRUB". (towo möge mich berichtigen wenn es nicht stimmt.)
Sector size (logical/physical): 512B/512B
Disk /dev/nvme0n1: 250GB
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 211MB 210MB fat16 EFI boot, esp
2 211MB 221MB 10,5MB BIOS_BOOT bios_grub
3 221MB 234GB 234GB btrfs ROOT
6 234GB 250GB 16,0GB linux-swap(v1) SWAP swapUnd die Platte mit den hier gezeigten Partitionen 1 und 2 sollte IMMER im Gehäuse bleiben.
Woher soll das (U)EFI des Mainboard sonst wissen was es booten soll?
-
Also eine BIOS Grub Partition ist auf einem EFI System nicht notwendig, ich habe auch keine.
Bei mir bleibt die Platte aber auch immer im Rechner.
-
@towo: OK.
@sdjopa: Wie soll man deine Aussage verstehen?
sda die SystemSSD ,per hotplug wechselbar, sdb und sdc meine "immer wieder verfügbaren" Daten + Sicherung
Du bootest siduction von sda, entfernst dann während des Betriebs die sda und steckst statt dessen eine Mint-sda rein (hotplug)?
Ein Wechsel der Systemplatte in ausgeschaltetem Zustand verursacht bei mir keine Probleme. Einzig ist regelmäßig eine Anpassung der Optionen im EFI oder BIOS notwendig. Das wurde hier bereits ausführlich beschrieben.
-
In meinen Augen ist das größte Problem, daß wir nicht genau wissen, wie "sdjopa" genau bootet.
Ist es ein UEFI-Eintrag? Falls ja, Boot in einen Bootmanager (a la Grub) oder direkter Kernelboot? Bei letzterem könnte einfach der Eintrag nicht (mehr) stimmen oder gar nicht mehr vorhanden sein.
Das ist der Grund, warum ich gerne "in Grub" und dort in den Kommandozeilenmodus gehen würde, um zu sehen: Wird die Siduction-SSD in der Liste der Laufwerke überhaupt aufgeführt? Falls ja, könnte man per "configfile"-Kommando aus diesem Grub die "grub.cfg" ausführen lassen und sehen, ob Siduction dann "normal" gebootet wird.
Da ich Siduction bisher nur als Live-System einsetze, weiß ich nicht, welche "EFI"-Einträge Siduction bei einer Installation in der EFI-Partition "macht". Falls es "nur" ein /EFI/siduction (oder Vergleichbares) ist, wird vielleicht lediglich der Eintrag nicht gefunden. Ein /EFI/BOOT muß/müßte dagegen immer als "default" ausgeführt werden. Weiß einer der Diskussionspartner, wie Siduction die (U)EFI-Partition (genau) einrichtet und welche Einträge/Dateien dort angelegt werden?
Ich mag nicht glauben, daß die SSD "beschädigt" wird. Außerdem habe ich ja schon ausgeführt, daß das Laufwerk auf jeden Fall aufgeführt werden muß, wenn man im BIOS/UEFI ein "Boot from device" (meist F10 oder F12) ausführt, selbst wenn dort kein Bootcode existiert. Wir brauchen das genaue Verhalten und das Wissen über sein Zustandekommen nach dem Einschalten des Geräts!
-
Da ich Siduction bisher nur als Live-System einsetze, weiß ich nicht, welche "EFI"-Einträge Siduction bei einer Installation in der EFI-Partition "macht". Falls es "nur" ein /EFI/siduction (oder Vergleichbares) ist, wird vielleicht lediglich der Eintrag nicht gefunden. Ein /EFI/BOOT muß/müßte dagegen immer als "default" ausgeführt werden. Weiß einer der Diskussionspartner, wie Siduction die (U)EFI-Partition (genau) einrichtet und welche Einträge/Dateien dort angelegt werden?
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:
# tree /boot/efi/
/boot/efi/
└── EFI
├── boot
│ └── bootx64.efi
└── siduction_2021.1.1
└── grubx64.efi
Und laut efibootmgr gibt es bei mir genau einen Boot-Eintrag:
# efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001
Boot0001* UEFI OS
Also nehme ich an @ro_sid, da hast du deine Antwort.
-
@Mister00X: Ja, vielen Dank, das war genau was ich "suche"!
# tree /boot/efi/
/boot/efi/
└── EFI
├── boot
│ └── bootx64.efi
└── siduction_2021.1.1
└── grubx64.efiDas sieht doch gut aus! Allerdings wird der "siduction"-Teil nur gefunden, wenn der (hier einzige) Eintrag 0001
# efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001
Boot0001* UEFI OSdarauf verweist. Ist dieser Verweis bei @sdjopa "falsch" - etwa falsches Laufwerk durch Tausch oder weil von anderem Betriebssytem überschrieben -, wird er natürlich nicht gefunden. Immerhin würde sonst Grub gestartet ;).
Gefürchtet ist bei mir auch ein BIOS-/UEFI-Update, da dabei alle Einträge auf "Standard" (=nur Microsoft) zurückgesetzt werden und ich alles "von Hand" wieder anpassen muß.
Ins "bootx64.efi" wird meines Wissens auch ein "root"-Pfad zur "grub.cfg"-Konfiguration eingetragen. Der sollte(!) allerdings immer funktionieren. Daher weiterhin mein Vorschlag: Grub -> "c" (Kommandozeile) -> "ls" (welches ist das "richtige" Laufwerk) -> "set root=(siehe vorher - dort zweite Partition(=btrfs)!)" -> "configfile /boot/grub/grub.cfg" und sehen, was passiert.
-
Hallo allerseits, also nochmal zur Aufklärung:
in meinem PC befinden sich 2 SSDs intern 1x für Daten 1x Sicherung,
werden nicht gewechselt, bleiben also drin!
Von extern habe ich ebenfalls zwei Einschübe,
nur einen Einschub verwende ich jeweils für das lfd. System, den anderen als Reserve.
Ich habe 4 SSDs mit jeweils nur einem OS,
auf jeweils einer separaten SSD habe ich auch nur ein OS im UEFI-Mode installiert,
SSD Nr.1 mit Siduction, die 2.SSD mit Mint, die 3.SSD mit Garuda, die 4.SSD mit Kubuntu,
PC ist stromlos, nun stecke ich SSD Nr. 2, 3, oder 4 ein und boote, arbeite mit dem lfd. OS und
fahre PC wieder runter, SSD wieder raus, wieder stromlos, nun stecke ich Siduction-SSD rein,
boote = nix passiert = Bildschirm schwarz = BIOS findet SSD auch nicht!
Alle SSDs/OS werden nacheinander gefunden, außer Siduction-SSD!
Versuch: PC aus und stromlos,
nun stecke ich neben Siduction-SSD eine z.B. Mint-SSD rein (zwei SSDs mit versch. OS extern eingesteckt)
schalte PC an = Mint bootet, im BIOS wird Sid.-SSD wieder nicht gefunden nur die anderen OS,
vom lfd. Mint kann ich die Sid.-SSD sehen und auch drauf zugreifen.........
Wenn ich die Sid.-SSD drin lasse, wird Sid. auch gefunden bei jedem PC einschalten und hochfahren,
sobald ich SSD entferne und wieder einstecke findet PC Sid.-SSD nicht,
alle anderen SSDs/OS schon.
Noch Fragen? Also ich bin hier absolut ratlos! Grüße
-
@sdjopa,
hattest du während der Installation von siduction eine vierte SSD mit einem deiner anderen OS eingesteckt?
Und / oder war während der Installation von siduction der CSM Mode in der Firmware aktiviert?
Ich habe bei mir testweise eine Installation durchgeführt.
Ausgangslage:
- nvme0n1 mit siduction und EFI
- SSD (/dev/sda) für die Neuinstallation. Partitionen wie auf der nvme0n1 (siehe Gestern um 13:35:25)
- CSM Mode in der Firmware aktiv
Ergebnis:
- Installation auf sda erfolgreich.
- Grub Menü wie vorher, das von der nvme0n1, ohne die neue Installation.
- In der Firmware ist die SSD auswählbar und bootet.
- Das Verzeichnis "/boot/efi/" existiert nicht. Das Verzeichnis "/EFI" auf sda1 existiert auch nicht.
Nächster Schritt:
- nvme0n1 booten, "update-grub" ausführen.
- Das Boot Menü enthält nun den zusätzlichen Eintrag für die SSD (sda)
Dritter Schritt:
- CSM Mode in der Firmware deaktiviert.
- SSD ist in der Firmware nicht mehr auswählbar.
- Die SSD bootet, wie gehabt, über das Grub Menü der nvme0n1.
Vierter Schritt:
- In die SSD booten.
- Die /etc/fstab um die Zeile "UUID=<uuid-of-sda1> /boot/efi vfat umask=0077 0 2" erweitern.
- Das Verzeichnis "/boot/efi" anlegen
- Den Befehl "journalctl daemon-reload" ausführen.
- Den Befehl "mount /boot/efi" ausführen.
- Das Verzeichnis "/boot/efi/EFI" anlegen.
- Den Befehl "update-grub" ausführen.
- Den Befehl "grub-install" ausführen.
Die Terminal Ausgabe muss so aussehen:
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Was wurde erreicht? Weitere Überlegungen.
- Der Bootmanager Grub der SSD wurde im EFI Modus installiert und wird jetzt benutzt.
Und natürlich auch die "grub.cfg" auf der sda. (Das habe ich für mein System natürlich wieder geändert.)
- Meine Vermutung: Bei Vorhandensein eines weiteren Systems mit EFI Bootmanager
wird Grub im MBR/BIOS Modus installiert. Eventuell trifft diese Aussage auch zu, wenn
der CSM Mode in der Firmware aktiviert ist.
(Wer es besser weiß, darf mich gerne berichtigen oder Erklärungen anfügen.)
- Mit der Grub Installation im EFI Modus sollte die SSD bei sdjopa immer als Bootmedium
erkannt werden, vorausgesetzt die Firmware würfelt die Platten nicht durcheinander
(siehe Antwort #14 am: 2023/04/13, 18:41:33) und der CSM Mode ist nicht aktiviert.
-
beides mit nein beantwortet:
(https://i.imgur.com/YLXANML.png)
Den "Vierter Schritt" werde ich baldmöglichst mal antesten.
Vielen Dank bis hierher an Scholle!
Grüße
-
@sdjopa: Nachfrage zu meinem Verständnis:
[...]
Versuch: PC aus und stromlos,
nun stecke ich neben Siduction-SSD eine z.B. Mint-SSD rein (zwei SSDs mit versch. OS extern eingesteckt)
schalte PC an = Mint bootet, im BIOS wird Sid.-SSD wieder nicht gefunden nur die anderen OS,
vom lfd. Mint kann ich die Sid.-SSD sehen und auch drauf zugreifen.........
[...]
"im BIOS wird Sid.-SSD wieder nicht gefunden" bedeutet, daß, wenn man ins BIOS-/UEFI-Setup (Del/F1 etc.) geht, der "Steckplatz/Platteneintrag" dieser SSD als leer/nicht-vorhanden angezeigt wird? Dort wo sonst (z.B.) "Samsung SSD 970 EVO 1TB" (oder so) steht?
Falls das so ist, hat es ziemlich sicher nichts mit Siduction zu tun. An der Stelle ist ja von "Booten" noch überhaupt keine Rede.
Ich wollte, ich wüßte, wie man so etwa "provoziert". Das wäre ja der Sicherheitsmechanismus. Platte eingesteckt, aber nicht ansprechbar, jedoch nicht kaputt.
Andererseits, wie findet dann das gebootete OS die Platte anschließend?
Die einzige Idee, die ich dazu hätte ist, daß zum Erkennen des Wechselplatteneinschubs ein Treiber benötigt wird, der vom gebooteten OS oder wenigstens dessen SSD stammt. Das müßte dann aber schon eine .efi-Erweiterung sein.
[So etwas mußte ich (über den Bootmanager "rEFInd") installieren, um beim Thinkpad (dann) vom SD-Card-Slot booten zu können, was die UEFI-Firmware von Lenovo nicht von Haus aus unterstützt. (Schleichwerbung: rEFInd ist toll! :))]
Nachtrag: Im laufenden OS (wenn es geht mal Siduction, mal anderes "bootendes" Linux) "efibootmgr -v" eingeben. Durchs "-v" sieht man das "Disk- und Bootfile"-Auswahlkriterium. Danke.
-
so Leute, hier nach Vorschlag von Scholle1 Vierter Schritt mal probiert nach frisch installiertem und geupdatetem Siduction:
Ausgabe im Terminal
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Siduction runter gefahren >SSD raus >anderes OS gebootet >wieder runtergefahren >SSD raus >SiductionSSD wieder
rein >PC findet Sid.-SSD nicht!
anschließend Vorschlag von ro_sid bei gebootetem Mint:
"efibootmgr -v" eingeben
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....................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.C.T.1.2.0.B.X.5.0.0.S.S.D.1....................A.................................>..Gd-.;.A..MQ..L.8.1.5.3.1.E.3.5.A.B.0.2. . . . . . . . ........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,527498fa-fcb5-48af-83b1-2817e4450703,0x800,0x100000)/File(\EFI\Ubuntu\shimx64.efi)..BO
hilft 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!?
-
@sdjopa,
wie hast du denn siduction vor dieser Aktion gebootet?
Siduction runter gefahren >SSD raus >anderes OS gebootet >wieder runtergefahren >SSD raus >SiductionSSD wieder
Wenn du noch einmal so weit kommst, dann erfülle bitte den Wunsch von ro_sid nach der Ausgabe von "efibootmgr -v" aus siduction.
-
ro_sid hat mich auch gerade auf eine Idee gebracht die noch sein kann.
Mir ist es schon mehrfach passiert, dass mein UEFI ein live system nicht von jedem USB-Slot aus booten kann.
Vielleicht ist das hier ähnlich. sdjopa hast du mal geschaut, ob das Problem bei dir mit unterschiedlichen Drive-Bays auftritt oder auch nicht.
Dann gibts noch was, dass ich anmerken möchte, es "dürfte" eigentlich kein Problem sein mehrere EFI-Partitionen auf mehreren Laufwerken zu haben, sonst wäre das booten eines Live-Systems ja ganz und gar unmöglich. Schwierig wirds wenn sich mehrere Betriebssysteme eine EFI-Partition teilen, vor allem dann wenn man da dann Laufwerke entfernt. Im Boot-Menü des UEFIs müssten eigentlich alle Laufwerke auftauchen. Das alles hier finde ich höchst mysteriös.
-
[...]
anschließend Vorschlag von ro_sid bei gebootetem Mint:
"efibootmgr -v" eingeben
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:
# 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!
-
Update 19:54 Uhr:
also nochmal Siduction im UEFI-mode frisch installiert und efibootmgr -v:
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!?
-
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 (https://askubuntu.com/questions/342365/what-is-the-difference-between-grubx64-and-shimx64)
und, es sind alle Klarheiten beseitigt! ;D
-
update 20:01, Sid. runtergefahren zusätzlich Mint-SSD eingeschoben, gebootet und efibootmgr -v
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!!
-
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.........
-
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)
-
@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?
-
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>
-
.....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
-
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?