Siduction bootet nicht

Started by sdjopa, 2023/04/12, 08:06:17

Previous topic - Next topic

edlin

Bist du inzwischen im Siduction-Manual schon bis zum Thema UUID vorgestoßen? Dort solltest du eine Antwort auf deine Katastrophen finden.

edlin
,,Ein kluger Mann macht nicht alle Fehler selber. Er lässt auch anderen eine Chance."

Winston Churchill

ro_sid

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 :).

sdjopa

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

rueX

#18
zeig mal  cat /etc/fstab
von allen eingebauten/angeschlossenen Medien/Partitionen

sdjopa

#19
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

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

Mister00X

@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?
Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. – Edward Snowden

sdjopa

...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!

towo

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.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

sdjopa

....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?

towo


QuoteWarum laufen die anderen Distris denn problemlos?
Weil die vielleicht im BIOS, aka CSM Mode installiert sind?

Ganz ehrlich, woher sollen wir das wissen?
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

ro_sid

Quote from: sdjopa on 2023/04/21, 19:14:47
....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.

sdjopa

@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

rueX


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 )





towo

Das bringt auch nicht viel!
Es ist halt keine so dolle Idee, einem System eine Platte wegzunehmen, auf der die EFI Partition drauf ist.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.