SATA NVME ersetzen

[jochen02]

Hallo,

die SATA NVME (SanDisk Ultra NVMe 3D SSD) in meinem Notebook mit Debian 12 hat Schäden.
Deshalb will ich sie durch eine neue SSD ersetzen. Bootmodus ist UEFI, es gibt ein ausreichend aktuelles Backup, das mit rsnapshot angelegt wurde.
Bisher habe ich:

• Wie in viewtopic.php?t=190892&hilit=UEFI#p1374907 beschrieben, EFI-Partition mit gparted angelegt,

• Backup zurückgelesen, dazu den neuen Datenträger per USB-Adapter an einen Rechner gehängt und mit rsync wiederhergestellt.

Leider beschwert sich das Notebook, es sei kein boot device vorhanden:

Code: Alles auswählen

"Default boot device missing or boot failed.
Insert recovery media and hit any key.
Then select 'Boot Manager' to choose a new boot device or to boot recovery media"

Die neue SSD wird im BIOS an sich erkannt, sie wird aber im boot manager nicht angezeigt. In der NVMe controller configuration steht schön die (neue) Samsung SSD 990 PRO 'drin.

Es schaut so aus, als hätte ich einen entscheidenden Schritt versäumt -- welchen?

Danke schon mal.

[Saxman]

Ich hab auch gerade ein System von einer SSD auf eine nvme umgezogen und dabei gleich von legacy Bios auf Uefi umgestellt.

Du hast ja bereits eine UEFI Partition angelegt. Darüber hinaus musst du evtl noch Grub updaten und ggfs. die Initramfs neu bauen. Vergiss auch nicht die fstab anzupassen, wenn sich die UUID oder die Laufwerksbezeichnungen geändert haben. Am einfachsten geht das alles, wenn man ein chroot in das neue Laufwerk macht und die Änderungen von da vornimmt.

Bei mir hat das alles gut funktioniert. Die Schritte waren im Wesentlichen:

1. Neue nvme partitionieren (GPT, separate Partitionen für efi & Boot, LVM für das System, nicht vergessen die efi Partition als esp zu markieren)
2. System von der SSD auf die nvme kopiert.
3. chroot in das neue laufwerk. Im chroot dann grub-pc gegen grub-efi-amd64 getauscht, initramfs neu geschrieben, update-grub und fstab angepasst.
4. Reboot und im Bios die legacy Bios Funktion deaktiviert und statt dessen UEFI eingestellt.
5. Start ins neue System

Vielleicht hilft dir das ja.

[jochen02]

Danke für die schnelle Antwort.

Mein Problem sieht etwas anders aus. Das System auf der defekten SSD war schon UEFI, daher muss ich sicherlich nichts tun, was für den Wechsel von legacy auf UEFI notwendig wäre.

Ich kann auch gar nicht so weit, dass grub ins Spiel kommt (denke ich). Schon das BIOS des Notebooks hat sich beschwert, dass kein Boot Service verfügbar sei.

[Saxman]

Ich kann auch gar nicht so weit, dass grub ins Spiel kommt (denke ich). Schon das BIOS des Notebooks hat sich beschwert, dass kein Boot Service verfügbar sei.

Grub ist dein Bootmanager, wenn der auf deiner neuen nvme nicht richtig eingerichtet ist, erkennt der Rechner keine Betriebssysteme auf dem Laufwerk. Das schaut mir schon danach aus, dass Grub bei dir nicht richtig konfiguriert ist. Versuch zumindest mal den Schritt 3 aus meinem anderen Beitrag. Das Wechseln von grub-pc gegen grub-efi kannst du skippen. Die anderen musst du sowieso machen, Rsync kopiert die UUID nicht mit, da müsstest du schon dd benutzen, wenn du das möchtest. D.h die fstab Einträge müssen eh angepasst werden. Wenn du davon nichts gemacht hast scheitert der boot eh spätestens, wenn auf das root Laufwerk zugegriffen werden soll.

[hikaru]

Nur der Form halber zu den verwendeten Begriffen, weil es mir in den Augen brennt:

die SATA NVME (SanDisk Ultra NVMe 3D SSD) in meinem Notebook mit Debian 12 hat Schäden.

"SATA NVMe" ist ein Oxymoron. Eine SSD nutzt entweder das SATA-Protokoll, oder das NVMe(PCIe)-Protokoll, aber nie beide gleichzeitig.
Was hier offenbar gemeint ist, ist eine NVMe-SSD - zumindest trifft das auf die erwähnte "Samsung SSD 990 PRO" zu.

Was mich zum zweiten Punkt bringt:

Ich hab auch gerade ein System von einer SSD auf eine nvme umgezogen und dabei gleich von legacy Bios auf Uefi umgestellt.

Wie angeklungen, ist "NVMe" ein von SSDs genutztes Protokoll.
Davon zu sprechen, ein "System von einer SSD auf eine nvme" umzuziehen, ist daher etwa so sinnvoll wie zu sagen, dass man nun Hosen statt Beinkleidern trägt.

[rhHeini]

Kurze Erläuterung für den OP wo es klemmt. Damit eine UEFI-Installation bootet sind 2 Dinge nötig:
1.) Der Eintrag in der ESP, wenn Du den mitkopiert hast ist da schon mal etwas vorhanden, möglicherweise aber mit falschem Inhalt wegen falscher UUID.
2.) Ein Eintrag in einem speziellen NVRAM-Bereich des Bios was dann im Bootmenu dargestellt wird. Und das fehlt hier ganz bestimmt.

Fix: ein grub-install. Nimm Dir ein Bootmedium, eine netinstall reicht und boote dies im Rescue-Mode. Du wirst ein paar Basisdinge gefragt wie bei der Installation, dann werden die Laufwerke erkannt, und Dir wird ein chroot angeboten. Hier musst Du das richige Device aussuchen und kriegst dann eine Konsole (Netzwerk muss gehen) wo Du ein grub-install machen kannst. Dann solltest Du wie bereits angemerkt die grub- und fstab-Einträge auf die korrekten UUIDs checken, ev. die initramfs neu bauen und dann Dein Glück mit einem Reboot versuchen.

PS: es gibt Spezialisten die behaupten dass der Bootmenu-Eintrag vom Bios automatisch erstellt wird. Das habe ich jedoch in meinem privaten Umfeld bei keinem der Rechner in meinem Besitz feststellen können. Dein Problem war bei mir immer die Regel bei einer solchen Aktion.

[jochen02]

Danke erstmal.

Ich glaube, ich brauche detailliertere Hilfe.

Im rescue-Modus des Debian-Sticks:

Die Platte hat eine VFAT-Partition, die ich mit gparted angelegt habe (da war die neue Platte noch per USB angeschlossen).
die Daten sehen so aus (fdisk -l):

/dev/nvme0n1p1 EFI 512MB System
/dev/nvme0n1p2 1,8TB Linux filesystem (root)
/dev/nvme0n1p2 20GB swap

/dev/nvme0n1p2 habe ich als root-Dateisystem ausgewählt.
Dann habe ich in der shell chroot /target gewählt, das wiederhergestellte System aus der Sicherung ist jetzt /.

Mit ls -l /dev/disk/by-uuid habe ich mir die uuids ermittelt. Die bisherigen uuids habe ich in /etc/fstab gegen diese ausgetauscht.

Und jetzt komme ich nicht mehr weiter...

[rhHeini]

Die P1 ist FAT32, hat die Flags boot und ESP?

Ist die P1 eingehängt auf /target/boot/efi?

Wenn ja, im chroot ein grub-install ausführen (ohne weitere Parameter).

[jochen02]

Nun...

parted im chroot sagt:

partition table: gpt

Disk Flags:

Code: Alles auswählen

Number	(...)	Size	File System	Name	Flags
1		537MB	fat32		boot,esp
2		1978GB	ext4			
3		21,5GB	swap		swap

Sollte also passen.

mount gibt aus:

Code: Alles auswählen

/dev/nvme0n1p2 on / type ext4 (rw,relatime)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /run type tmpfs (rw,nosuid,relatime,size=1614932,mode=775)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

grub-install sagt:

Code: Alles auswählen

Installing for x86_64-efi platform.
grub-install: warning: EFI variables cannot be set on this system.
grub-install: warning: You will have to complete the GRUB setup manually.
Installation finished. No errors reported.

Gerade die 2. Warnung beunruhigt mich.

System booted nicht von der Platte.
EDIT: Es ist eine "Verwirrung", die der Hersteller des Notebooks mitverursacht hat. Mit einem Lösungshinweis von ihm kam ich jetzt *teilweise* zum Ziel:

Im BIOS wählen Sie bitte "Boot From File" aus und navigieren dann ins EFI-Bootverzeichnis, es müsste eine Art "GRUB... .efi" geben, diese müssen Sie auswählen.
Im Betriebsystem wieder angekommen, bitte
sudo update-grub

update-grub meldet dann:

Code: Alles auswählen

Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.8.12-amd64
Found initrd image: /boot/initrd.img-6.8.12-amd64
Found linux image: /boot/vmlinuz-6.6.15-amd64
Found initrd image: /boot/initrd.img-6.6.15-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Found memtest86+ 32bit EFI image: /boot/memtest86+ia32.efi
Found memtest86+ 64bit image: /boot/memtest86+x64.bin
Found memtest86+ 32bit image: /boot/memtest86+ia32.bin
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

Sieht für mich unauffällig aus, oder?
Wenn ich das so mache, booted die Kiste zwar, aber beim nächsten reboot ist das wieder notwendig. Die Datei, die ich auswählen soll, ist <EFI>/Debian/grubx64.efi.
Es stehen noch andere Dateien zur Auswahl: shimx64.efi, mmx64.efi, fbx64.efi. Nach dieser Aktion steht die Platte trotzdem nicht im BIOS-Bootmanager als Option zur Verfügung.

[rhHeini]

Du startest den Stick auch im efi-Modus? Also mit dem Prefix EFI oder UEFI vor dem Sticknamen?

Also grub-install meldet "grub-install: warning: EFI variables cannot be set on this system." Diese Meldung zeigt ein Scheitern.

Ich denke wenn Du da probierst

Code: Alles auswählen

# efibootmgr -v

kommt eine ähnliche Meldung. Da müssten wohl noch die efi-Variablen gemountet werden. Das Directory /sys/firmware/efi ist leer.

Bitte nochmal in den chroot, und mach dort ein

Code: Alles auswählen

# mount -t efivarfs -o remount,rw none /sys/firmware/efi/efivarfs 

Und dann noch ein grub-install.

[cosinus]

2.) Ein Eintrag in einem speziellen NVRAM-Bereich des Bios was dann im Bootmenu dargestellt wird. Und das fehlt hier ganz bestimmt.

Ist der wirklich zwingend notwendig? Hab wie in einem anderen Thread beschrieben mal ein HAOS auf eine SSD mit pv geschrieben, nachdem die SSD im Zielrechner eingebaut wurde, bootete er sofort davon im UEFI-Modus.

[rhHeini]

2.) Ein Eintrag in einem speziellen NVRAM-Bereich des Bios was dann im Bootmenu dargestellt wird. Und das fehlt hier ganz bestimmt.

Ist der wirklich zwingend notwendig? Hab wie in einem anderen Thread beschrieben mal ein HAOS auf eine SSD mit pv geschrieben, nachdem die SSD im Zielrechner eingebaut wurde, bootete er sofort davon im UEFI-Modus.

PS: es gibt Spezialisten die behaupten dass der Bootmenu-Eintrag vom Bios automatisch erstellt wird. Das habe ich jedoch in meinem privaten Umfeld bei keinem der Rechner in meinem Besitz feststellen können. Dein Problem war bei mir immer die Regel bei einer solchen Aktion.

[cosinus]

PS: es gibt Spezialisten die behaupten dass der Bootmenu-Eintrag vom Bios automatisch erstellt wird. Das habe ich jedoch in meinem privaten Umfeld bei keinem der Rechner in meinem Besitz feststellen können. Dein Problem war bei mir immer die Regel bei einer solchen Aktion.

Was soll denn diese unnötige provokative Bezeichnung über Spezialisten? Ich kann dir nur sagen was ich beobachtet habe, ich unterstelle dir doch auch nicht, dass du dir alles aus den Fingern saugst

[wanne]

und mit rsync wiederhergestellt.

Kannst du den/die genauen Befehl(e) geben. Irgend wie kommt mir das sehr obskur vor.
Wenn du nur die EFI-Partition angelegt hast, kannst du ja auch nur die kopieren. Oder hast du die ganze Platte drüber kopiert.
Prinzipiell sieht dein fdisk aber gut aus. Ich will nur auf nummer sicher gehen.

mount gibt aus:

Code: Alles auswählen

/dev/nvme0n1p2 on / type ext4 (rw,relatime)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /run type tmpfs (rw,nosuid,relatime,size=1614932,mode=775)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

Dann fehlt noch ein

Code: Alles auswählen

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Debian2" --loader '\EFI\debian\shimx64.efi'

Oder halt ein chroot und ein grub install. Aber chrooting ist IMHO nicht mehr so einfach seit systemd. Deswegen würde ich eher zum efibootmgr-befehl greifen.
Achtung: Das funktioniert nur, wenn der rettungs-stick im EFI-Modus gebooted ist, was im Moment nicht der Fall ist! Ich würde um das sicher zu stellen mal CSM/Legacy boot im EFI abschalten.

Ist der wirklich zwingend notwendig? Hab wie in einem anderen Thread beschrieben mal ein HAOS auf eine SSD mit pv geschrieben, nachdem die SSD im Zielrechner eingebaut wurde, bootete er sofort davon im UEFI-Modus.

Ja. Wie schon im passenden Thread beschrieben verhält sich HAOS wie ein Bootbare CD oder ein anderes Wechselmedium. Das macht das Feature von EFI kaputt mehrere Betriebsysteme auf die gleiche Platte installieren zu können aber dafür die Installation ein bisschen einfacher. Auch Debian bietet diesen Hack im expert-Installer an. Wo er mit an Sicherheit grenzender Wahrscheinlichkeit nicht ausgewählt wurde. grub-mkconfig kennt die --removable Option, die auch da nicht default ist, weil ne feste Installation einfach zuverlässiger funktioniert.

[jochen02]

Hallo,

und mit rsync wiederhergestellt.

Kannst du den/die genauen Befehl(e) geben. Irgend wie kommt mir das sehr obskur vor.
Wenn du nur die EFI-Partition angelegt hast, kannst du ja auch nur die kopieren. Oder hast du die ganze Platte drüber kopiert.
Prinzipiell sieht dein fdisk aber gut aus. Ich will nur auf nummer sicher gehen.

ich glaube, das ist ein Missverständnis.
Der ursprüngliche Datenträger war defekt. Deshalb musste ich einen neuen Datenträger beschaffen, auf den ich die letzte Vollsicherung zurücklesen kann.
Die Sicherungen mache ich mit rsnapshot, unter der Haube also mit rsync. rsync habe ich deshalb auch zum restore verwendet. Dazu habe ich den neuen Datenträger per USB an einen funktionierenden PC gehängt, von dem ich dann den restore machen konnte.
So in etwa:

Code: Alles auswählen

rsync -av <quelle/> <ziel>

Anschließend habe ich die EFI-Partition mit dem Inhalt der EFI-Partition auf der alten Platte (war auch gesichert) gefüllt.
Dabei fällt mir ein: Wie bekomme ich den Inhalt der EFI-Partition, wenn ich sie nicht vorher gesichert habe?

Dann fehlt noch ein

Code: Alles auswählen

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Debian2" --loader '\EFI\debian\shimx64.efi'

Ha! Das scheint der Fehler gewesen zu sein. Das Notebook booted [doof, eigentlich müsste es "boots" heißen...] jetzt ohne weitere Nachfragen und die neue Platte ist im boot manager eingetragen. Ich bin aber vorsichtig...

Die nächsten Tage werde ich das erst mal noch beobachten und die hier gewonnenen Erkenntnisse für mich dokumentieren.

Ich danke dir und allen anderen hier, die mir mit Rat und Hilfe zur Seite gestanden haben.
Meine Entschuldigung dafür, dass ich nicht alles immer vollständig klar beschrieben habe.

[wanne]

Code: Alles auswählen

rsync -av <quelle/> <ziel>

Wie man rsync benutzt, weiß ich. Ich war eigentlich an den vorhergehenden mount befehlen und <quelle> und <ziel> interessiert, um sicher zu gehen, dass du die richtigen Teile auf die richtige Partition kopiert hast. Aber wie gesagt: Sieht ja alles gut aus.

Dabei fällt mir ein: Wie bekomme ich den Inhalt der EFI-Partition, wenn ich sie nicht vorher gesichert habe?

Grub2 legt die Einzelteile alle doppelt und dreifach ab. /EFI/debian/shimx64.efi liegt z.B. unter /usr/lib/shim/shimx64.efi.signed. Einiges wird dynamisch update-grub generiert. grub-install kopiert das ganze zeug zusammen und führt am Ende den efibootmgr Befehl aus. Da muss dann aber eben alles an der richtigen Stelle liegen. Wofür man heute doch einige mount befehle vorm chroot braucht. Sollte da IMHO ähnlich wie update-grub mal ein kurz-befehl geben der alles passend mounted und dann chroot ausführt.

[cosinus]

Ja. Wie schon im passenden Thread beschrieben...

Guit das mit HAOS war nur ein Beispiel, denn meine anderen Images erfordern auch kein Herumgefummel mit efibootmgr. Entweder hab ich wohl ganz besondere Hardware oder ich mach einen Schritt nach dem Recovern zusätzlich im Unterbewusstsein.

[wanne]

denn meine anderen Images erfordern auch kein Herumgefummel mit efibootmgr.

Oder du verstehst den Unterschied zwischen einer LiveCD und eienem Installierten System nicht. (wie im vorherigen Thread!) Oder du benutzt gar keine Hardware sonden eine VM. Oder du nutzt eine Partition, die zuvor schon im EFI eingetragen war.
Du merkst schon, dass es hier mindestens 5 Leute (Ich, Rico81, MSfree, jochen02, rhHeini) gib die passende Erklärungen abgegeben haben, dass das (zumindest im Normafall) nicht so funktioniert?! Bist du dir sicher, dass du das weiter in jedem Thread weiter verbreiten willst?

Hier: Wenn du es wirklich verstehen willst:
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html
https://uefi.org/specs/UEFI/2.10/13_Pro ... ccess.html

[cosinus]

Oder du nutzt eine Partition, die zuvor schon im EFI eingetragen war.

Gut möglich. Ich versuch das mal in meinem Urlaub nachzuvollziehen.
Ich bin mir aber ziemlich sicher, dass ich auch schon auf nackte Notebooks (Werkszustand nackt!) mittels GRML ein Abbild mit pv und ntfsclone für Windows 11 wiederhergestellt habe und nichts mit efibootmgr oder dergleichen machen musste.

[wanne]

Ich bin mir aber ziemlich sicher, dass ich auch schon auf nackte Notebooks (Werkszustand nackt!) mittels GRML ein Abbild mit pv und ntfsclone für Windows 11 wiederhergestellt habe und nichts mit efibootmgr oder dergleichen machen musste.

Jetzt wird es noch lustiger: Das packt ja üblicherweise sogar die Lizenzschlüssel ins EFI... Sicher dass du da nicht vergessen hast ein mal mit einer Windows-iso (https://www.microsoft.com/en-us/softwar ... /windows11) gebootet hast? Ähnlich wie supergrubdisk/Rescatux für Grub2 kann das mal alles was so rumliegt und nach Windows aussieht ins EFI eintragen. Sonst gibt es da natürlich beliebig obsukre OEM-Varianten, deren Boot wenig mit dem Standard zu tun hat.

[cosinus]

Jetzt wird es noch lustiger: Das packt ja üblicherweise sogar die Lizenzschlüssel ins EFI... Sicher dass du da nicht vergessen hast ein mal mit einer Windows-iso (https://www.microsoft.com/en-us/softwar ... /windows11) gebootet hast?

Nein, direkt GRML gebootet. Nach dem Restore des Image bootet Windows 11 direkt und meckert dann herum, dass es aktiviert werden will. So jedenfalls bei einem Notebook mit Werkszustand nackt, auch keine Windows-Lizenz dabei. (davon hatten wir mal 5 Exemplare gekauft)

[jochen02]

Code: Alles auswählen

rsync -av <quelle/> <ziel>

Wie man rsync benutzt, weiß ich.

Ich war eigentlich an den vorhergehenden mount befehlen und <quelle> und <ziel> interessiert, um sicher zu gehen, dass du die richtigen Teile auf die richtige Partition kopiert hast. Aber wie gesagt: Sieht ja alles gut aus.

Ja, sieht gut aus. Quelle und Ziel waren in meinem Fall die externe USP-Festplatte mit der Sicherung und root der root-Partition auf der neuen SSD (deshalb auch der "/" am Ende des Ziels). An sich wird das Backup mit https://rsnapshot.org erstellt. Mache ich -- getestet -- seit vielen Jahren so. Das boot-Problem muss man dann aber anders lösen.

Grub2 legt die Einzelteile alle doppelt und dreifach ab. /EFI/debian/shimx64.efi liegt z.B. unter /usr/lib/shim/shimx64.efi.signed. Einiges wird dynamisch update-grub generiert. grub-install kopiert das ganze zeug zusammen und führt am Ende den efibootmgr Befehl aus. Da muss dann aber eben alles an der richtigen Stelle liegen. Wofür man heute doch einige mount befehle vorm chroot braucht.

Danke, das muss ich mir dann mal zusammenschreiben.