[gelöst]Nach Festplattenentfernung ist kein neues booten möglich

[frankieboy]

Hallo Forum,

ich habe einen neuen alten PC und darauf bullseye installiert. Das hat auch alles wunderbar funktioniert. Ich kann den Rechner runterfahren und wieder hoch und damit arbeiten. Alles ganz wunderbar ...

ABER: Wenn ich die Festplatte von den SATA-Anschlüssen abziehe und dann wieder anschließe, wird sie beim neuerlichen booten nicht erkannt. . Weil ich es ganz genau wissen wollte, habe ich die Installation mehrfach in allen mögliche Modi (UEFI, Lagacy) wiederholt und dabei auch das beschriebene Phänomen reproduziert. Immer alles supi, bis ich die Festplatte abziehe und wieder neu anschließe.

Eigentlich kann ich damit leben, denn ich bin nicht so der Typ, der ständig die Festplatte wechselt. Einmal drin bleibt sie auch drin bis sie dann (nach Jahren) mal gegen ein neueres Modell getauscht wird und die Daten werden ohnehin regelmäßig im NAS gesichert. Dennoch finde ich das merkwürdig, denn es bedeutet ja, dass ich zwischendurch nicht einfach mal 'ne andere Festplatte mit alternativem Betriebssystem ranklemmen kann - wie ich das perspektivisch zur Probieren anderer Betriebssysteme vorhatte - weil ich ohne Neuinstallation nicht auf die Bullseye-Festplatte zurückkommen kann ...

Woran scheitert mein Vorhaben und wie kann ich das Problem ggf. lösen?

[kalle123]

Viel Text und recht wenig Info

Schon ein einfaches

Code: Alles auswählen

~$ inxi -Fz

und die Ausgabe des Befehls hier würde da etwas Klarheit schaffen.

Hört sich sehr nach BIOS an, aber schau'n mer mal.

cu KH

[frankieboy]

Viel Text und recht wenig Info

Ja, stimmt leider. Da ich hier jedoch wie der "Ochs' vom Berg" stand (stehe) und ich keinen Plan hatte (habe), die Aufgabenstellung anzugehen, habe ich keine andere Möglichkeit gesehen, meine Beobachtungen jenseits aller Konsolenbefehle zu schildern. Sorry.

Immerhin ist es mir mit dem Rescatux-Rettungs-Image (0.74) gelungen, das installierte Bullseye wieder zu booten. Allerdings ist der Lerneffekt so natürlich nicht gegeben. Es funktioniert halt wieder, aber weshalb vorher nicht? Keine Ahnung ...

Gerade an diesem "Lernfaktor" bin ich aber interessiert Und Außerdem ist ja keineswegs gesagt, dass das Booten nach zwischenzeitlicher Entfernung der Festplatte jetzt zuverlässig funktioniert.

Schon ein einfaches

Code: Alles auswählen

~$ inxi -Fz

und die Ausgabe des Befehls hier würde da etwas Klarheit schaffen.

Gut, würde mich freuen . Hier jetzt die Ausgabe, allerdings *nachdem* ich wieder booten konnte. Vielleicht lassen sich daraus ja trotzdem noch Schlüsse für das "richtige" booten ziehen ...

Code: Alles auswählen

$ inxi -Fz
System:
  Kernel: 5.10.0-11-amd64 x86_64 bits: 64 Desktop: Xfce 4.16.0 
  Distro: Debian GNU/Linux 11 (bullseye) 
Machine:
  Type: Desktop System: wortmann product: N/A v: N/A serial: <filter> 
  Mobo: ASUSTeK model: P8H77-M LE v: Rev X.0x serial: <filter> 
  UEFI: American Megatrends v: 1501 date: 06/20/2014 
CPU:
  Info: Dual Core model: Intel Core i3-3220 bits: 64 type: MT MCP 
  L2 cache: 3 MiB 
  Speed: 2663 MHz min/max: 1600/3300 MHz Core speeds (MHz): 1: 2663 2: 2889 
  3: 1902 4: 2234 
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics 
  driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting 
  unloaded: fbdev,vesa resolution: 1: 1280x1024~60Hz 2: 1280x1024~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 2500 (IVB GT1) 
  v: 4.2 Mesa 20.3.5 
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio 
  driver: snd_hda_intel 
  Sound Server: ALSA v: k5.10.0-11-amd64 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8169 
  IF: enp3s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:
  Local Storage: total: 74.53 GiB used: 3.84 GiB (5.2%) 
  ID-1: /dev/sda vendor: Seagate model: ST3808110AS size: 74.53 GiB 
Partition:
  ID-1: / size: 24.42 GiB used: 3.73 GiB (15.3%) fs: ext4 dev: /dev/sda2 
  ID-2: /boot/efi size: 511 MiB used: 3.4 MiB (0.7%) fs: vfat dev: /dev/sda1 
  ID-3: /home size: 47.04 GiB used: 113.6 MiB (0.2%) fs: ext4 dev: /dev/sda4 
Swap:
  ID-1: swap-1 type: partition size: 977 MiB used: 0 KiB (0.0%) 
  dev: /dev/sda3 
Sensors:
  System Temperatures: cpu: 29.8 C mobo: 27.8 C 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 156 Uptime: 8m Memory: 15.51 GiB used: 1.42 GiB (9.2%) 
  Shell: Bash inxi: 3.3.01 

Hört sich sehr nach BIOS an, aber schau'n mer mal.

Irgendwie da so in diesem Bereich. Das hatte ich mir auch gedacht ...

[kalle123]

OK, mal eben drüber geschaut ....

Sieht ja eher unverdächtig aus.

Es gibt da noch ein 'etwas' neueres BIOS. Bufferbatterie Mobo ist in Ordnung? BIOS mal auf default zurückgesetzt?

Bei deiner geschilderten Problematik würde ich erst mal die Finger von EFI lassen.

Wie sieht es den aus mit nem anderen SATA port auf dem MOBO, anderes SATA Kabel und ev. einer anderen Platte.

Wenn ich das richtig verstanden hast, installierst du und alles ist in Ordnung. Dann fährst du den PC runter, ziehst den SATA Stecker und den Stromstecker von der Platte, steckst beide Stecker wieder an, schaltest ein und Debian fährt nicht hoch. Was sagt das BIOS denn, wenn du statt hochfahren, direkt beim Einschalten ins BIOS gehst, wird die Platte da angezeigt?

Mehr fällt mir da auf die Schnelle nicht ein ....

Gruß KH

[frankieboy]

OK, mal eben drüber geschaut ....

Sieht ja eher unverdächtig aus.

Es gibt da noch ein 'etwas' neueres BIOS. Bufferbatterie Mobo ist in Ordnung? BIOS mal auf default zurückgesetzt?

Das jetzt installierte BIOS habe ich erst gestern draufgespielt. Auf der ASUS-Seite ist es die neueste zum Mainboard angebotene Firmware. Ja, natürlich, es ist "alt". Das Mainboard aber ja auch ... Wo bekomme ich denn ein aktuelleres BIOS her?

Bei deiner geschilderten Problematik würde ich erst mal die Finger von EFI lassen.

Wie sieht es den aus mit nem anderen SATA port auf dem MOBO, anderes SATA Kabel und ev. einer anderen Platte.

Anderen SATA-Port und andere Festplatte habe ich schon probiert. Immer die gleiche Verhaltensauffälligkeit ... Neues SATA-Kabel muss ich mir noch besorgen

Wenn ich das richtig verstanden hast, installierst du und alles ist in Ordnung. Dann fährst du den PC runter, ziehst den SATA Stecker und den Stromstecker von der Platte, steckst beide Stecker wieder an, schaltest ein und Debian fährt nicht hoch.

1. Die Neuinstallation verläuft *immer* problemlos ...
2. Wenn ich die SATA-Verkabelung und die Festplatte *nicht* anfasse, startet und bootet der Rechner/die Festplatte auch danach wie gewünscht. Login und Nutzung ist auch wie gewünsch möglich.

3. Wenn ich jedoch (bei abgeschalteten PC) die Verkabelung aus der dem Festplatte nehme und eine andere Festplatte anschließe, bootet diese nicht.
4. Verkabel ich dann wieder die ursprüngliche Festplatte, bootet diese leider auch nicht mehr.[/quote]

Was sagt das BIOS denn, wenn du statt hochfahren, direkt beim Einschalten ins BIOS gehst, wird die Platte da angezeigt?

Nach der Neuinstallation und solange ich die Festplatte dann nicht von der SATA-Verkabelung nehme, wird die Platte als BOOT-Medium (UEFI) angezeigt. Ist die Pestplatte von der Verkabelung abgenommen und dann wieder neu verkabelt, wird sie auch nicht im BIOS angezeigt.

Allerdings habe ich jetzt einen Workaround gefunden, der zwar nicht sonderlich elegant, aber zumindest akzeptabel ist:
1. Erkenntnis, die Festplatte bootet nicht mehr.
2. Den PC mit Rescatux-Rettungssystem (Version 0.74) vom USB-Stick booten
3. In das Programm gehen. Eintrag "Easy GNU/Linux Boot Fix" wählen. "run" klicken"
4. Anzeige im Programmablauf: "Fsck partition, update grub menues, restore GRUB into the MBR and order UEFI entries"
5. Aufforderung im Programm-Ablauf: "Select items fro the List. Which GNU/Linux partition?"
6. Meine Auswahl: "sda2 Debian_GNU/Linux_11_"
7. Das Prokramm läuft durch und nach kurzer Zeit dann das okay. Überall grüne Haken
8. Mit dem Neustart des Rechners bootet die Festplatte wieder. (solange bis ich die Kabel erneut ziehe, dann wiederholt sich das Spiel).

Damit kann man (ich) leben. So oft kommt es ja doch nicht vor, dass mal eine andere Festplatte angesteckt wird. Es wäre natürlich gut, wenn es auch ohne diesen Umweg ginge ...

[kalle123]

Ich sehe da bei dir

UEFI: American Megatrends v: 1501 date: 06/20/2014

und auf

https://www.asus.com/ch-de/SupportOnly/ ... Desk_BIOS/

Version 1501 2014/09/12 4.18 MBytes

Da ist der timestamp neuer ....

Ein 2. SATA Kabel hast du nicht? NOCHMAL! BIOS zrückgesetzt?

Aber da du ja anscheinend mit der 'Krücke' leben kannst, ist es ja gut

Gruß KH

[electri]

Kann es sein, dass durch den Wechsel zur alternativen Festplatte die uefi-firmware (also das was früher bios hieß) die Booteinträge der ursprünglichen Platte "vergisst", und die ursprüngliche Platte beim Wiedereinbau dann auch nicht mehr bootet? Leider kenne ich mich mit uefi nicht so gut aus, da ich das erst seit ein paar Monaten für meinen neuen Rechner verwende. Eventuell könnte eine Installation im Bios-Legycy-Modus zielführend sein? Da kann das Bios nichts vergessen. Oder eben die Lösung über das Rettungssystem gehen.

[thoerb]

Kann es sein, dass durch den Wechsel zur alternativen Festplatte die uefi-firmware (also das was früher bios hieß) die Booteinträge der ursprünglichen Platte "vergisst", und die ursprüngliche Platte beim Wiedereinbau dann auch nicht mehr bootet?

Könnte ich mir gut vorstellen. Vielleicht muss die Festplatte im BIOS (uefi-firmware ) einfach nur neu zugewiesen werden.

[kalle123]

... habe ich die Installation mehrfach in allen mögliche Modi (UEFI, Lagacy) wiederholt und dabei auch das beschriebene Phänomen reproduziert.

Bei deiner geschilderten Problematik würde ich erst mal die Finger von EFI lassen.

KH

[OrangeJuice]

Woran scheitert mein Vorhaben und wie kann ich das Problem ggf. lösen?

Kannst du folgendes bitte mal zeigen.

Code: Alles auswählen

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Code: Alles auswählen

efibootmgr -v

[frankieboy]

[
Kannst du folgendes bitte mal zeigen.

Code: Alles auswählen

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Code: Alles auswählen

UEFI

Code: Alles auswählen

efibootmgr -v

Code: Alles auswählen

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* debian	HD(1,GPT,af9a75c7-49b1-439c-93e1-d11621e225df,0x800,0x100000)/File(\EFI\debian\shimx64.efi)

[rhHeini]

Im UEFI-Modus kenne ich das auch von einem etwa ähnlich alten Board dass das Bios die Einträge des entfernten Laufwerks löscht. Kann man fixen über einen chroot mit nem Live-Linux und einem re-install vom grub.

Rolf

[frankieboy]

.

Ich sehe da bei dir

UEFI: American Megatrends v: 1501 date: 06/20/2014

und auf

https://www.asus.com/ch-de/SupportOnly/ ... Desk_BIOS/

Version 1501 2014/09/12 4.18 MBytes

Da ist der timestamp neuer ....

Uups, das abweichende Datum war mir gar nicht aufgefallen. Hab's jetzt in der von dir angegeben Version nochmal neu installiert. Ist aber identisch mit der schon vorhandenen Firmware, auch was das "interne" Datum betrifft. Ich vermute, der Timestamp 12.09.2014 bezeichnet das Veröffentlichungs- und der 20.06.2014 das Fertigstellungsdatum. Aber: Nix genaues weiß ich nicht

Ein 2. SATA Kabel hast du nicht? NOCHMAL! BIOS zrückgesetzt?

a) Zweites SATA-Kabel? Nein, kommt mir erst am Montag ins Haus ...
b) NOCHMAL! BIOS zrückgesetzt? Ja- Unverändertes Verhalten ...

Aber da du ja anscheinend mit der 'Krücke' leben kannst, ist es ja gut

Gequältes "ja". Es kann eben nicht völlig zufriedenstellen, wenn die Dinge ungewollt von der Norm abweichen. Andererseits gibt es viiiieeeeelll Schlimmeres. Ein Stück weit ist das wie im wirklichen Leben, da kann (darf) man sich auch nicht auf völlig verrennen, sondern muss zu akzeptablen Kompromissen bereit sein.

Ich bin deshalb geneigt, den Thread auf "gelöst" zu setzen. Okay, einen Tag warte ich noch ab, aber dann

[OrangeJuice]

Meiner Meinung nach ist das kein normales Verhalten. Ich habe einen ähnlichen Fall. Das Mainboard vergisst shimx64, wenn Secure Boot aktiviert war und will einfach grubx64(ohne Secure Boot) laden, mal ebenso zwischendurch. Dazu gibt es noch ein paar weitere Eigenheiten.

Auch, wenn die SSD abgesteckt wurde, der PC angeschaltet wurde und die SSD wieder angeschlossen wurde, werden die Pfade vergessen, auch ohne Secure Boot. Das sollte so nicht korrekt sein, vor allem nicht bei einem relativ neuen PC. Das UEFI holt sich von /efi auf der SSD die korrekten Pfade.

Das kuriose bei einem Mainboard passiert das beschriebene und schließe ich die SSD an einem anderen PC an, dann wird alles wunderbar und korrekt erkannt. Meiner Meinung nach, in meinem Fall, stimmt einfach etwas mit dem Mainboard oder Bios nicht.


Hast du Secure Boot aktiviert oder es bei der Installation angeschaltet?

Code: Alles auswählen

mokutil --sb-state

Die Einträge sind auch nicht weg, sie liegen in "/boot/efi/efi"(nur mit root sichtbar).

Code: Alles auswählen

ls -la /boot/efi/efi/debian

Ich bin das Problem umgangen, indem ich ein auf der SSD installiertes Ubuntu gestartet habe und dort die shim Einträge erneuert habe(den Pfad mit /dev/sdX muss man noch anpassen). Danach ein Neustart und ein "grub-install" in Debian hat den Rest gerichtet. Man kann sicher anders und besser vorgehen, aber es war so mein Mittel der Wahl.

Code: Alles auswählen

efibootmgr --create --disk /dev/sdX --part 1 --label "DebianX" --loader \\EFI\\Debian\\shimx64.efi

[frankieboy]

Hast du Secure Boot aktiviert oder es bei der Installation angeschaltet?

Code: Alles auswählen

mokutil --sb-state

Code: Alles auswählen

SecureBoot enabled

Die Einträge sind auch nicht weg, sie liegen in "/boot/efi/efi"(nur mit root sichtbar).

Code: Alles auswählen

ls -la /boot/efi/efi/debian

Code: Alles auswählen

insgesamt 3480
drwx------ 2 root root    4096  6. Feb 15:07 .
drwx------ 3 root root    4096  6. Feb 15:07 ..
-rwx------ 1 root root     108  6. Feb 15:38 BOOTX64.CSV
-rwx------ 1 root root   84648  6. Feb 15:38 fbx64.efi
-rwx------ 1 root root     135  6. Feb 15:38 grub.cfg
-rwx------ 1 root root 1672576  6. Feb 15:38 grubx64.efi
-rwx------ 1 root root  845480  6. Feb 15:38 mmx64.efi
-rwx------ 1 root root  934240  6. Feb 15:38 shimx64.efi

[frankieboy]

Ich setzte den Thread mal auf gelöst.

Ich habe eine für mich hinreichend akzeptable Lösung des Problems gefunden: Unter Hinzuziehung des Rescatux-Rettungssystems (hier Version 0.74) kann die betreffende Festplatte jederzeit wieder bootfähig gemacht werden. Wie ich es genau gemacht habe, kann im Beitrag vom 05.02.2022 16:20:09 nachgelesen

Es stimmt zwar, dass es dieser Lösung an Eleganz fehlt und insgesamt vielleicht auch nur die Schulnote "4" reicht, jedoch ist das Mindestziel, die Festplatte wieder booten zu können, geschafft. Weil dieses Fehlerbild - keine bootfähigkeit nach abziehen der SATA-Kabel - bei mir auch nur selten auftreten wird, ist der Lösungsansatz (Rescatux-Rettungssystem) dafür auch vertretbar, jedenfalls für mich.

Ich danke allen Diskutanten für die gewährte Hilfestellung. Mein besonderer Dank geht an "kalle123", der mir in den vergangenen Tagen ein wertvoller Wegbegleiter war Vielen Dank!

[kalle123]

Hallo, danke für die 'Blumen'.

Aber solches auffällige Fehlverhalten würde mir persönlich keine Ruhe geben, aber leider hab ich die Maschine nicht hier.

In solchen Fällen hab ich immer Platten, Kabel, Netzteile, Grakas in Reserve zum Testen. Speicherriegel finden sich auch noch irgendwo und wenn das nichts bringt, bleibt nur Mobo und CPU als Übeltäter übrig.

Aber bitte sei vorsichtig, ich würde den Rechner mit Vorbehalt benutzen. Eigentlich schade, ist doch ein gutes Mobo.

Grüße - KH

[OrangeJuice]

Ich setzte den Thread mal auf gelöst.

Eine Anmerkung geben ich noch ab. Falls du Secure Boot nicht benötigst, dann kannst du versuchen ob sich etwas ändert, wenn du es abschaltest und die Plattform Keys im Bios löschst. Danach sollte doch wenigstens grubx64 gefunden und geladen werden. Ich gehe mal davon aus, dass bei dem älteren Mainboard, noch nicht die Fehler in Secure Boot geschlossen worden sind. Es gab z.B. Boothole(debian.org und heise.de).

[Sidespin]

Ich hatte zu meiner "Distrohopping-Zeit" auch ein solches Problem. Ich hatte in meinem Desktoprechner auch 2 SSD-Systemplatten zum Tauschen.
So habe ich auf einer Buster installiert und wollte dann z.B. Fedora auf die andere und habe dazu die Platten getauscht. Beim Rücktausch auf Buster
hat dieses dann auch nicht mehr gebootet. Das passierte auch nur bei Debian. Fedora, Manjaro usw. konnte ich problemlos wieder rücktauschen und alle
sind wieder hochgefahren.
Ich hatte das auch mehrmals versucht, das Ergebnis war immer das gleiche. Hier im Forum konnte man mir auch nicht weiterhelfen und diese Test-Zeiten
habe ich auch hinter mir gelassen.