Weihnachtsangebot 2025! 🎄

[liv-in-sky]

hätte ein boot problem - evtl weiß jmd von euch, was zu tun wäre!

vorgeschichte: mein server lief mittlerweile auf 5 verschiedenen rechnern - es wurde also immer wieder ein duplikat der ssd auf eine neu ssd und eine neue hardware durchgeführt

am anfang musste ich refind als bootmanager installieren, weil die hardware nicht direkt mit debian boot-bar war. ich habe dann auch gleich einen extra bootvorgang, um in clonezila "rein-zu-booten" um zb ein image- backup des systems zu machen . irgendwann kam auch mal ein ubuntu zu dem existierenden debian system dazu. proxmox ist nicht über die iso installiert, sondern wurde auf debian direkt aufgesetzt

das problem: irgendwann war auf einmal das refind weg und es war das grub menu mit allen einträgen vorhanden (debian mit proxmox, ubuntu clonezilla) - ich vermute das ein proxmoy oder debian update das refind überschrieb. habe jetzt eine neue ssd eigebaut mit clonezilla kopiert und nun habe ich plötzlich grub 2 menu. clonezilla ist weg - aber er bootet den richtigen kernel für proxmox. das alte grub 1 kann ich schon auf der ssd finden, es wird aber beim booten eine andere partition genutzt und startet grub2

übersicht

/dev/nvme0n1p1      2048   1050623   1048576   512M EFI System
/dev/nvme0n1p2   1050624 429649919 428599296 204,4G Linux filesystem
/dev/nvme0n1p3 452448256 468860927  16412672   7,8G Linux swap
/dev/nvme0n1p4 429654016 452448255  22794240  10,9G Linux filesystem
/dev/nvme0n1p5 468860928 976773134 507912207 242,2G Linux filesystem

mount | grep boot
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

in partition /dev/nvme0n1p4 in /boot/grub/ liegt die grub.cfg mit den richtigen einträgen

eingehängt ist:

df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev             16G       0   16G    0% /dev
tmpfs           3,2G    5,5M  3,2G    1% /run
/dev/nvme0n1p2  201G    166G   25G   88% /
tmpfs            16G     46M   16G    1% /dev/shm
tmpfs           5,0M     12K  5,0M    1% /run/lock
efivarfs        192K    110K   78K   59% /sys/firmware/efi/efivars
/dev/nvme0n1p1  511M    340M  172M   67% /boot/efi
/dev/nvme0n1p5  238G     38G  188G   17% /mnt/pve/local2
/dev/sda1       234G    135G   87G   61% /mnt/pve/BackupNew
/dev/sdb        3,6T    2,0T  1,5T   59% /DatenNAS
/dev/fuse       128M     48K  128M    1% /etc/pve
/dev/sdd1       1,8T    311G  1,4T   18% /HARDDISK

wie schaffe ich es - ohne das system zu zerstören - wieder in /dev/nvme0n1p4 zu booten

[liv-in-sky]

@Homoran sorry und danke fürs verschieben

[Homoran]

@liv-in-sky ich hoffe dass hier schneller passende Hilfe kommt.

[Thomas Braun]

@liv-in-sky sagte in hilfe bei boot problem mit linux/proxmox:

es wurde also immer wieder ein duplikat der ssd auf eine neu ssd und eine neue hardware durchgeführt

Das ist halt schlecht, wenn z. B. Grub eigentlich mit UUIDs hantiert. Die können sich nämlich durchaus entsprechend ändern. Deswegen ja auch 'unique'. Deswegen lasse ich auch i. d. R. die Finger von clones, außer ich weiß, das das System in gleicher Konstellation auf der genau gleichen Hardware wieder aufgespielt werden soll.

wie schaffe ich es - ohne das system zu zerstören - wieder in /dev/nvme0n1p4 zu booten

In die grub.conf die richtige UUID eintragen.

[liv-in-sky]

@thomas-braun ich vermute mittlerweile der fehler liegt tiefer - wenn ich im grub bin, ist es schon zu spät - ich denke die einstellungen von clonezilla haben da reingepfuscht - oder auch die boot-partition verändert (boot-flag ?)

wahrscheinlich muss ich die alte ssd wieder nehmen und nochmal clonen - diesmal mit anderen settings - welche ich noch nicht durchschaue - aber schon der erste punkt im setting (bild) könnte da was vermurkst haben

[liv-in-sky]

war doch einfacher als gedacht - im bios konnte man sehen, das 2 einstiegspunkte auf der nvme vorhanden sind - mußte nur den richten als primär einstellen und dann war wieder alles, so wie es sein soll :-)