Clonezilla-Klon lässt sich ohne Neuinstallation von Grub2 nicht starten

Clonezilla-Klon lässt sich ohne Neuinstallation von Grub2 nicht starten

Ich habe einen Klon einer Maschine mit den folgenden Partitionen erstellt:

Device                   Type        Label
/dev/sda 
    /dev/sda1            Ext4        boot
    /dev/sda2            Linux LVM      
    /dev/system/         LV system     
    /dev/system/home     LV          home
    /dev/system/root     LV          root
    /dev/system/swap     LV          swap

Diese sind durch ein Etikett gekennzeichnet in

/etc/fstab:

LABEL=root     /        ext4
LABEL=boot     /boot    ext4
LABEL=home     /home    ext4
LABEL=swap     /swap    swap

und grub.cfg:

menuentry 'openSUSE, with linux <version>' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-<version>-simple-<UUID>' {
    insmod ext2
    set root='hd0,msdos1'
    linux /vmlinuz-<version> root=/dev/mapper/system-root resume=/dev/disk/by-label/swap <other options>
    initrd /initrd-<version>
}

Ich versuche, diesen Klon auf einem anderen identischen Rechner zu installieren. Die Installation ist erfolgreich, aber ich kann den Rechner nicht booten, ohne Folgendes in der Grub-Eingabeaufforderung zu tun, in die ich weitergeleitet werde:

grub> set root=(hd0,1)
grub> linux /boot/vmlinuz-<version> root=/dev/sda1
grub> initrd /boot/initrd.img-<version>
grub> boot

Ich würde viel lieber ein Image bekommen, das diese Schritte nicht erfordert, aber ich bin mir nicht sicher, wo das Problem liegt (Grub-Konfiguration, andere Systemdateien, Clonezilla). Dinge, die ich bisher versucht habe:

  • /etc/defaults/grub bearbeitet und ' GRUB_DISABLE_LINUX_UUID=true' auskommentiert
  • Grub-mkconfig_lib wurde bearbeitet, um die Zeilen wie folgt auszukommentieren: search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}um zu verhindern, dass sie beim Generieren von grub.cfg hinzugefügt werden.
  • (und neu generiert grub.cfg)
  • Habe die erweiterte Clonezilla-Installation ausgewählt und es angewiesen, den MBR anschließend neu zu installieren (Option -j1. Option -g auto „Grub im MBR der Client-Festplatte neu installieren“ war bereits standardmäßig ausgewählt)

Gibt es noch etwas, das ich versuchen kann?

Mir ist aufgefallen, dass /boot/grub2/device.mapfür hd0 „sda1“ aufgeführt ist, aber die Festplatte der anderen Maschine wird als sda1 erkannt, wenn ich den Klon installiere, daher glaube ich nicht, dass dies der Übeltäter ist.

(Ich war nicht sicher, ob hier oder Superuser besser auf die Frage passt. Ich bin froh, dass es entsprechend migriert wird.)

Antwort1

Letztendlich habe ich das Problem gelöst, indem ich einen Partitionsklon der Bootpartition der Originalmaschine erstellt und diesen auf den anderen Maschinen installiert habe, wobei ich in den erweiterten Optionen „-j1“ ausgewählt habe.

Dieser zusätzliche Schritt ist zwar etwas ärgerlich, aber zumindest dauert die Wiederherstellung eines Klons der Boot-Partition nur Sekunden.

Antwort2

Um dieses Problem zu beheben, müssen wir GRUB(2) nach einer fehlgeschlagenen Installation/Klonung oder einer Beschädigung des MBR manuell installieren.

Lassen Sie uns nun nach dem Neustart den Grub-Boot reparieren:

sh:grub>set pager=1 # for paging long command outputs; There must be no spaces on either side of the equals sign. 
grub> set root=(hd0,XY)
'grub> insmod /boot/grub/linux.mod # AFAIK, optional step
grub> linux /boot/vmlinuz-4.4.92-36-default root=/dev/sdaXY
grub> initrd /boot/initrd.img-4.4.92-36-default
grub> boot

Nachdem Sie Ihr Linux erfolgreich gebootet haben, machen wir die Reparatur dauerhaft:

# update-grub
# grub-install /dev/sda #or what ever your system disk is

Wenn Sie den Fehler erhaltenupdate-grub command not foundkeine Sorge, es ist einfach ein Shell-Skript, das erstellt wurde, um die Dinge einfacher zu machen. Tatsächlich macht es Folgendes:

set -e
exec grub2-mkconfig -o /boot/grub/grub.cfg "$@"

Nach dem Ausführen von grub-install ... sollte Ihr System wieder normal funktionieren. Ich habe dies mit einem geklonten OpenSuse Leap 42.2 unter Verwendung von Clonezilla 2016-02-10 gemacht (primäre Laptop-Festplatte auf eine größere SSD migriert).

Verweise:So retten Sie einen nicht bootfähigen GRUB 2 unter Linux
Reparieren eines defekten GRUB 2-Bootloaders unter Ubuntu

Hier ist ein alternativer Ansatz, der ohne Booten in Linux funktioniert:

$ sudo fdisk -l (From this you need to find the device name of your physical drive that won't boot, something like “/dev/sdxy″ - where x is the drive and y is the root partition. Since I was using a software RAID, root (/) was on md1)
$ sudo mount /dev/sdxy /mnt (Mount the root partition)
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ sudo chroot /mnt  (This will change the root of executables to your your drive that won't boot)
$ grub-mkconfig -o /boot/grub/grub.cfg (insure that there are NO error messages)
$ grub-install /dev/sdx (NOTE that this is the drive and not the partition. try grub-install --recheck /dev/sdxy if it fails)
Ctrl+D (to exit out of chroot)
$ sudo umount /mnt/dev
$ sudo umount /mnt/proc
$ sudo umount /mnt/sys
$ sudo umount /mnt

Referenz:http://redsunsoft.com/2016/06/how-to-repair-a-server-stuck-at-the-grub-prompt/

Antwort3

Kurz zusammengefasst

Verwenden Sie unter Ubuntu, das auf GPT installiert ist, BootRepair, nachdem Sie sich beim System angemeldet haben.


Hatte das gleiche Problem wie @jam, aber in meinem Fall habe ich:

  • Ubuntu 16.04, das ich klonen wollte
  • Quellfestplatte (HDD, 500 GB)
    • MBR
    • Dualboot mit Windows
  • Zielfestplatte (SSD, 256 GB)
    • GPT

Daher habe ich /homemit Clonezilla nur Linux-Partitionen (sda5 – für das System, sda6 für ) geklont, nicht die gesamte Festplatte.

Um dies zu ermöglichen, habe ich Clear Ubuntu auf der SSD installiert, Partitionen wie auf der Festplatte erstellt und auch ESP (EFI System Partition) hinzugefügt. Dann habe ich diese Partitionen mit Clonezilla überschrieben (HDD-Partitionen auf SSD). Als Ergebnis erhielt ich eine GRUB-Eingabeaufforderung.

Dann machte ich

grub> set root=(hd0,gpt2)  # NOTICE: used gptX instead of simple number
grub> linux /boot/vmlinuz-<version> root=/dev/sda1
grub> initrd /boot/initrd.img-<version>
grub> boot

wie @jam es tat und @wp78de vorschlug (und es stand auch in seinen Referenzen).

Dann habe ich es gemacht und bin mit Fehlern update-grubweitergefahrengrub-install

grub-install: error: will not proceed with blocklists

Der Grund war in GPT. Es gab einige nützliche Sachen inDasThread, aber der einfachste Ansatz war die VerwendungBootRepair. Ich weiß nicht, ob BootRepair spezielle Arbeiten ausgeführt hat, aber ich habe überprüft, ob GRUB neu installiert werden soll, und jetzt funktioniert alles einwandfrei!

Antwort4

Ich hatte genau dasselbe Problem (Centos 7) mit dem MBR-Boot, egal, was ich hinsichtlich Festplatten, Partitionen, Versionen von Clonezilla usw. probierte. Am Ende kaufte ich das PartedMagic ISO, auf das weiter oben im Thread verwiesen wurde, und obwohl es CLonezilla verwendete, vollbrachte es am Ende des Prozesses offensichtlich Wunder, da die geklonten Festplatten ohne manuelles Eingreifen booteten.

Craig

verwandte Informationen