[Gelöst] Kein boot von SSD mehr

[gm2601]

Hallo gm2601,

aus den openSUSE Release notes (gilt, soweit mir bekannt, auch für openSUSE Leap 15.2):
https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/index.html#sec.install.uefi]1.4 UEFI—Unified Extensible Firmware Interface
[...]
Hast Du das schon überprüft?

Die ehrliche Antwort -- Du hast das erwartet-- heißt "Nein". ps:
Mir hat UEFI im Feb. 2020, als ich mich erstmalig an 15.x wagte, in Gegensatz zur heutigen Minivorstellung, noch überhaupt nichts gesagt und ich installierte wie immer nach der Methode "das Installationsprogramm wird wissen was es tut".
Dazu kommt, dass ich noch nie BIOS oder einschlägige neuere FW geladen habe und einen Heidenrespekt davor hätte.

 

[gm2601]

Hallo Christina,

.... schon überprüft?
z.B. damit?

Emil-4:~ # /usr/sbin/dmidecode -t 0,2
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
        Vendor: American Megatrends Inc.
        Version: 5220
        Release Date: 09/12/2019
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 16 MB
        Characteristics:
                PCI is supported
                APM is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 5.13

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: PRIME A320M-K
        Version: Rev X.0x
        Serial Number: 191059912202419
        Asset Tag: Default string
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: Default string
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

Eventuell: https://www.asus.com/de/Motherboards-Components/Motherboards/PRIME/PRIME-A320M-K/HelpDesk_BIOS/

Dein Tipp mit "PRIME A320M-K" war goldrichtig, die FW habe ich in ~/Downloads, den Mut dazu noch nicht.

 

[gm2601]

Hallo @gm2601,

ist das aktuelle Datum und die aktuelle Uhrzeit im EFI zu sehen?

Ja, aber um zwei Stunden gegenüber MEZ verschoben.

Falls das Datum und Uhrzeit nach einer Korrektur verschwindet dann ist das ein Indiz auf eine leere Batterie. Am besten das Datum und Uhrzeit einstellen dann den Lappi herunterfahren und am nächsten Tag die Einstellung prüfen.
Warum komme ich zu dem Entschluss?
Deine EFI Änderungen verschwinden nach der Änderung.

An dem sollte es bestimmt nicht scheitern, obwohl ich das noch nie zu machen brauchte, und die Kiste ja erst gut 1½ Jahre alt ist.

 

[Christina]

Hallo Christina,
(…)
Dein Tipp mit "PRIME A320M-K" war goldrichtig, die FW habe ich in ~/Downloads, den Mut dazu noch nicht.

Der Tipp von susejunky 25. Okt 2021, 16:32 war goldrichtig.
Übrigens wird Leap 15.2 noch maximal bis Ende Dez. 2021 unterstützt. Benötigst du das jetzt wirklich noch?

 

[susejunky]

Hallo gm2601,

... Dazu kommt, dass ich noch nie BIOS oder einschlägige neuere FW geladen habe und einen Heidenrespekt davor hätte.

eine Firmware-Aktualisierung ist immer mit einem gewissen Risiko verbunden, daher kann ich Deinen "Heidenrespekt" gut nachvollziehen. Im schlimmsten Fall (z.B. Stromausfall während der Aktualisierung) ist die Systemplatine eventuell erst einmal unbrauchbar und ob sich eine Reparatur lohnt, ist dann immer fraglich.

Ich kann zwar sagen, dass ich bereits die Firmware einiger Systemplatinen von PCs (BIOS, UEFI), Laptops (BIOS, UEFI), Smartphones und Tablets ohne Probleme (lass uns auf Holz klopfen ...) aktualisiert habe, aber ...

Was sind Deine Alternativen:

1. Aktuell installierte Firmware beibehalten und ihr (noch nicht eindeutig nachgewiesenes!) Fehlverhalten akzeptieren.
2. Einen PC-Reparaturservice beauftragen, die Firmwareaktualisierung durchzuführen und für das erfolgreiche Gelingen zu haften.
3. Im Bekanntenkreis einen "PC-Guru" suchen, der bei der Aktualisierung unterstützt.
4. Warten, bis sich hier im Forum jemand findet, der das identische Modell Deiner Systemplatine besitzt und damit schon einmal eine Firmware-Aktualisierung durchgeführt hat.
5. Die einschlägige Dokumentation des Systemplatinenherstellers suchen und durchlesen und anschließend ...

Außer den ersten beiden, bergen alle Alternativen die Gefahr des potentiellen Verlusts der Systemplatine (zzgl. der damit verbundenen Reparaturaufwände). Daher kannst nur Du entscheiden, welche der Alternativen für Dich in Frage kommt!

Viele Grüße

susejunky

 

[susejunky]

Hallo gm2601,

... Ja, aber um zwei Stunden gegenüber MEZ verschoben.

bis zum Samstag ist das so in Ordnung .

Hier noch ein paar Hintergrundinformationen.

Viele Grüße

susejunky

 

[Christina]

eine Firmware-Aktualisierung ist immer mit einem gewissen Risiko verbunden, daher kann ich Deinen "Heidenrespekt" gut nachvollziehen. Im schlimmsten Fall (z.B. Stromausfall während der Aktualisierung) ist die Systemplatine eventuell erst einmal unbrauchbar und (…)

Für diesen Fall gibt es eine Notfallprozedur, die auch im Handbuch beschrieben ist.
https://www.asus.com/de/Motherboards-Components/Motherboards/PRIME/PRIME-A320M-K/HelpDesk_Manual/

The ASUS CrashFree BIOS 3 is an auto recovery tool that allows you to restore the BIOS file
when it fails or gets corrupted during the updating process.

Auf Deutsch: https://www.asus.com/de/support/FAQ/1012219/
Sogar mein altes Motherboard (f.AMD) hat sowas schon. Und das ist noch mit klassischem BIOS.

 

[susejunky]

... Für diesen Fall gibt es eine Notfallprozedur, die auch im Handbuch beschrieben ist.

Da ich keine ASUS-Systemplatine besitze, kann ich dazu nichts sagen.

Was jetzt für gm2601 ggf. noch von Interesse wäre:

Hat jemand bereits einmal diese Notfallprozedur mit dieser Systemplatine erfolgreich angewendet?

Viele Grüße

susejunky

 

[josef-wien]

An susejunky: Du wirst wohl kaum jemanden finden, der nach einem während der Aktualisierung aufgetretenen Stromausfall sein BIOS/UEFI wiederherstellen mußte.

An gm2601: Im Dokument E13571_BIOS_Update_EM_V4_WEB.pdf ist der Punkt 1.3 für Dich wichtig (und der Punkt 1.4 im bei mir noch nie eingetretenen Katastrophenfall). Den Weg über einen USB-Stick wirst Du wahrscheinlich nicht brauchen, kopiere einfach die entpackte Datei PRIME-A320M-K-ASUS-5606.CAP nach /boot/efi. Unter "ASUS EZ Flash 3 Utility" wählst Du dann die richtige Deiner 3 EFI-Systempartitionen und dort die Datei aus. Die Datei wird vom UEFI geprüft (wenn ich meinem UEFI Deine Datei vorwerfe, weigert es sich, damit etwas zu tun), und bevor die Aktualisierung startet, wirst Du gefragt, ob Du das tun willst.

 

[susejunky]

Hallo josef-wien,

An susejunky: Du wirst wohl kaum jemanden finden, der nach einem während der Aktualisierung aufgetretenen Stromausfall sein BIOS/UEFI wiederherstellen mußte.

Tja, dann bleiben gm2601 nur zwei Optionen.

• Augen zu und durch (und Daumen drücken, dass im Falle des "Super-GAUs" die Notfallprozedur funktioniert).
• Die aktuell installierte Firmware beibehalten und ihr (noch nicht eindeutig nachgewiesenes!) Fehlverhalten akzeptieren.

Viele Grüße

susejunky

 

[gm2601]

Übrigens wird Leap 15.2 noch maximal bis Ende Dez. 2021 unterstützt. Benötigst du das jetzt wirklich noch?

Ja, denn 15.3 ist noch ein Torso ohne meine persönlichen Daten und es befindet sich auf den gemütlicheren HDD.

[...]
Was sind Deine Alternativen:

1. [Aktuell installierte Firmware beibehalten und ihr (noch nicht eindeutig nachgewiesenes!) Fehlverhalten akzeptieren.
2. [...]

Nimm's mir nicht übel, Variante 1 in Verbindung mit der Empfehlung von @josef-wien "Super_Grub_2" zu probieren, ist für mich ein akzeptabler Workaround, denn damit gelingt im Notfall auch der Boot von der SSD und ich habe wieder mindestens ein System mit dem ich im Notfall ins Web komme.

Für diesen Fall gibt es eine Notfallprozedur, die auch im Handbuch beschrieben ist.
https://www.asus.com/de/Motherboards-Components/Motherboards/PRIME/PRIME-A320M-K/HelpDesk_Manual/

The ASUS CrashFree BIOS 3 is an auto recovery tool that allows you to restore the BIOS file
when it fails or gets corrupted during the updating process.

Auf Deutsch: https://www.asus.com/de/support/FAQ/1012219/
Sogar mein altes Motherboard (f.AMD) hat sowas schon. Und das ist noch mit klassischem BIOS.

Danke, das kann ich mir überlegen, wenn ich einen sehr mutigen Tag habe.

An gm2601: Im Dokument E13571_BIOS_Update_EM_V4_WEB.pdf ist der Punkt 1.3 für Dich wichtig (und der Punkt 1.4 im bei mir noch nie eingetretenen Katastrophenfall). Den Weg über einen USB-Stick wirst Du wahrscheinlich nicht brauchen, kopiere einfach die entpackte Datei PRIME-A320M-K-ASUS-5606.CAP nach /boot/efi. Unter "ASUS EZ Flash 3 Utility" wählst Du dann die richtige Deiner 3 EFI-Systempartitionen und dort die Datei aus. Die Datei wird vom UEFI geprüft (wenn ich meinem UEFI Deine Datei vorwerfe, weigert es sich, damit etwas zu tun), und bevor die Aktualisierung startet, wirst Du gefragt, ob Du das tun willst.

Danke, auch da würde ich mich wohl wie auf einem dünnen Siel tanzend fühlen, womit ich wieder beim sehr mutigen Tag wäre.

[...]Tja, dann bleiben gm2601 nur zwei Optionen.
a. [...]
b. Die aktuell installierte Firmware beibehalten und ihr (noch nicht eindeutig nachgewiesenes!) Fehlverhalten akzeptieren.

Das und "Super_Grup_2" lassen mich wieder ruhig schlafen.


Ich finde es bewundernswert mit welchem Engagement ihr einem User helft, der dann doch immer wieder zum Zögern und Zaudern neigt.
D A N K E !

 

[susejunky]

Hallo gm2601,

... Nimm's mir nicht übel, Variante 1 in Verbindung mit der Empfehlung von @josef-wien "Super_Grub_2" zu probieren, ist für mich ein akzeptabler Workaround, ...

Deine Entscheidung geht für mich vollkommen in Ordnung!

Auch wenn ich bislang noch nie Probleme mit Firmware-Aktualisierungen hatte, zu 100% ausschließen kann man sie aber nie und da beim Fehlschlage ggf. auch ein wirtschaftlicher Schaden droht ...

Viele Grüße

susejunky

 

[Heinz-Peter]

Ich habe nun meine HDD mit 15.3 bei abgesteckter SSD installiert, danach gelang mir ein einziges Mal von SSD zu booten -- es

Grub verwendet die Datei devices.map zur Zuordnung zwischen den Laufwerken.
Die besagte Datei wird erstellt nach dem ersten Start von Grub. Die Datei wird allerdings nach dem Hinzufügen neuer Laufwerke nicht automatisch aktualisiert. Die Datei soll sich irgendwo im Ordner /boot/* befinden.

Hast Du so eine Datei und falls ja, was steht in der Datei drin?

Grüße, Heinz-Peter

 

[gm2601]

Grub verwendet die Datei devices.map zur Zuordnung zwischen den Laufwerken.
[...]
Hast Du so eine Datei und falls ja, was steht in der Datei drin?

Bei 15.3 (HDD), von der ich boote, finde ich diese Datei nicht

localhost:/boot> ll -R | grep -i device
localhost:/boot>

Bei 15.2 (SSD) finde ich nur "device.map" und da steht nichts anderes drin als:

Emil-4:/boot> cat /boot/grub2/device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb

ob das DVD-Laufwerk da mit hinein gehören sollte, weiß ich nicht, ich wüsste auch nichts von einem mapping von /dev/sr0.

 

[Heinz-Peter]

Bei 15.3 (HDD), von der ich boote, finde ich diese Datei nicht

Du hast "Leap 15.3" auf die HDD installiert aber die SSD war zu diesem Zeitpunkt nicht angeschlossen also wurde auch keine Datei device.map durch Grub2 geschrieben.

Bei 15.2 (SSD) finde ich nur "device.map" und da steht nichts anderes drin als:

Emil-4:/boot> cat /boot/grub2/device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb

Das genügt dem Bootmanager vollkommen um die angeschlossene FP zu finden.
Bei der HDD fehlt die Datei device.map also sucht er auch nicht nach SSD, er bootet einfach (hd0) /dev/sda.
Wie Du aus dem Dilemma herauskommst kann ich nicht sagen, vielleicht findet sich hier jemand die das hinbekommt.
Ich hätte ein Backup meiner Dateien gemacht dann eine GParted heruntergeladen und die beiden FP neu aufgesetzt.

ob das DVD-Laufwerk da mit hinein gehören sollte, weiß ich nicht, ich wüsste auch nichts von einem mapping von /dev/sr0.

Grub2 interessiert dein /dev/sr0 überhaupt nicht, das ist Sache des BS.

Grüße, Heinz-Peter

 

[josef-wien]

An Heinz-Peter: Löse Dich von Deinem "BIOS-Modus"-Denken, wir haben es mit UEFI zu tun: https://linux-club.de/forum/viewtopic.php?p=797058#p797058

Das UEFI interessiert überhaupt nicht, mit welchen Dateien ein von ihm gestartetes Programm wie z. B. ein Bootmanager wie GRUB 2 arbeitet. Und GRUB 2 (der bei gm2601 beide Systeme starten kann) hat mit dem UEFI-Bootmenü (wo Eintragungen verschwinden) nichts zu schaffen.

P. S. Eine vernünftige GRUB 2-Einrichtung sollte bei einer GPT mit Attributen wie z. B. PARTUUID und nicht mit Altlasten wie device.map arbeiten. Wie das die Distributionen machen, kann ich nicht sagen.