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.map
fü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 found
keine 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 /home
mit 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-grub
weitergefahrengrub-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