Bootloader not restored (when recovering image created with Clonezilla)

English Install/Boot/Login
#1

Hello
It’s years I am using OpenSuse for a set customized PC I am workin on. I started with Suse 11, and now I am trying to switch to latest version, 13.2. I’ve always installed the operating system on one PC and restored it by using Clonezilla (http://clonezilla.org/). It worked like a charm… until now.

Now, I installed OS 13.2, with default settings, and I tried to created an image from it (by the way, I followed their instruction website and I used the alternative ubuntu based version with support to UEFI secure boot, even if, from my understanding, it is not used by default on this version).

Now, I tried to restore the image. While partitions are restored correctly (I can mount them and see the files using a live image), bootloader is not getting restored.

I manually tried to recover the bootloader, but even the Rescue System keeps telling me that there is an error while installing the bootloader (yast gives no additional information).

The obvious following attempt was to install bootloader from command line, using rescue image and grub2-install.
I tried to follow this (old) guide: https://en.opensuse.org/SDB:Repair_MBR_after_Windows_install, but I am unable to figure out the correct settings. By default grub2-install considers the system i386. The installed Suse version is x86_64. The only 64 bit target I found on the system is x86_64-efi, but when I force it with the related option the installer says that it cannot find the efi partition.

Here is the result of fdisk -l from the source PC:

|**Device
|
**|**Boot
**|**Size
**|**Id
**|**Type
**|
|/dev/sda1||2G|82|Linux Swap / Solaris|
|/dev/sda2|*|20G|83|Linux|
|/dev/sda3||210.9G|83|Linux|

Maybe you have an idea of the recent changes in bootloader and partition settings that might cause this and help me to investigate in the right direction…

#2

GRUB is always built as i386 binary for legacy BIOS; it can load x86_64 kernel just fine. Please paste exact command invocation and error you receive.

#3

Thanks for your reply. I’ll try it as soon as possible and I’ll let you know. However, I can confirm you that the machine has a UEFI capable BIOS.

#4

On 2014-12-05 10:26, wof wrote:
>
> Hello
> It’s years I am using OpenSuse for a set customized PC I am workin on. I
> started with Suse 11, and now I am trying to switch to latest version,
> 13.2. I’ve always installed the operating system on one PC and restored
> it by using Clonezilla (http://clonezilla.org/). It worked like a
> charm… until now.

You restore on different machine, I assume.

Just as a guess, the new machine has different UEFI setup than the
original one.

> I tried to follow this (old) guide:
> https://en.opensuse.org/SDB:Repair_MBR_after_Windows_install, but I am
> unable to figure out the correct settings. By default grub2-install
> considers the system i386.

That’s the correct one, yes. Don’t look for a 64 bit one.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#5

Yes, I restore to a different machine, but its hardware should be the same (I guess, but I am not absolutely sure). So, maybe that BIOS is not the same (but both have a UEFI bios).

First command, to be on the safe side:

btrfs check --repair /dev/sda2

This command seems to give me no error (err is 0).

Then, I followed exactly the guide. When executing chroot I get:
BTRSF Info: (device sda2): csum failed ino 22727 off 643072 csum … (error on cksum)
BTRSF Info: (device sda2): csum failed ino 22727 off 651264 csum … (error on cksum)
Segmentation fault

Ok, that is weird. I tried to proceed anyway with

grub2-install /dev/sda

And I get:
Installing for i386-pc platform
grub2-install: error: cannot open directory ‘/mounts/mp_0001/boot/grub2/i386-pc’: No such file or directory.

The segfault error scared me. So I tried to avoid to bind dirs while mounting and I used grub2-install with additional command line:

grub2-install –boot-directory=/mnt/boot /dev/sda

And grub2 gets installed. I get a warning saying that it cannot open /dev/share/locale. But no error reported.
However, after this, I get grub in console mode with no operating system listed (just grub prompt).

Is there a reason why an imaging tool could not be able to restore the bootloader? Do you think that I have a broken sda2 partition?

Thanks for your kind interest.

#6

On 2014-12-05 19:56, wof wrote:
>
> Yes, I restore to a different machine, but its hardware should be the
> same (I guess, but I am not absolutely sure). So, maybe that BIOS is not
> the same (but both have a UEFI bios).

I’m not an expert on grub2 or efi installation, so I’ll let somebody
else answer those questions.

> Then, I followed exactly the guide. When executing chroot I get:
> BTRSF Info: (device sda2): csum failed ino 22727 off 643072 csum …
> (error on cksum)
> BTRSF Info: (device sda2): csum failed ino 22727 off 651264 csum …
> (error on cksum)
> Segmentation fault

You are installing grub2 into a btrfs partition? This is my opinion, and
several will not agree: I would use a separate /boot partition made in
ext2. I would never try to install grub on a btrfs partition.

I know there are some problems with it, and as I don’t personally know
when it works and when not, I prefer not to risk it.

As I said it is my personal opinion - maybe my age and experience (and
the many times I was bitten) pushes me on the over-careful side.

> Is there a reason why an imaging tool could not be able to restore the
> bootloader? Do you think that I have a broken sda2 partition?

This one I know: “clever” imaging tools do not image “booting”. They try
to recreate it instead (and sometimes they fail). This is documented on
their web pages. Not the failing thing, but that they try a recreationg,
running grub install etc.

A tool like “dd” would clone it properly, if properly used.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#7

On Fri 05 Dec 2014 10:45:06 PM CST, Carlos E. R. wrote:

On 2014-12-05 19:56, wof wrote:
>
> Yes, I restore to a different machine, but its hardware should be the
> same (I guess, but I am not absolutely sure). So, maybe that BIOS is
> not the same (but both have a UEFI bios).

I’m not an expert on grub2 or efi installation, so I’ll let somebody
else answer those questions.

> Then, I followed exactly the guide. When executing chroot I get:
> BTRSF Info: (device sda2): csum failed ino 22727 off 643072 csum …
> (error on cksum)
> BTRSF Info: (device sda2): csum failed ino 22727 off 651264 csum …
> (error on cksum)
> Segmentation fault

You are installing grub2 into a btrfs partition? This is my opinion, and
several will not agree: I would use a separate /boot partition made in
ext2. I would never try to install grub on a btrfs partition.

I know there are some problems with it, and as I don’t personally know
when it works and when not, I prefer not to risk it.

As I said it is my personal opinion - maybe my age and experience (and
the many times I was bitten) pushes me on the over-careful side.

> Is there a reason why an imaging tool could not be able to restore the
> bootloader? Do you think that I have a broken sda2 partition?

This one I know: “clever” imaging tools do not image “booting”. They try
to recreate it instead (and sometimes they fail). This is documented on
their web pages. Not the failing thing, but that they try a recreationg,
running grub install etc.

A tool like “dd” would clone it properly, if properly used.

Hi
I use mbr+/boot(ext4)+btrfs or uefi+/boot/efi(vfat)+btrfs

I also use sgdisk and tar for gpt partition data backup of the ESP
(UEFI partition) via a script.

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#8

Note that there are other gotchas in doing a clone. For one the disk ID is different unless you are mounting by an independent ID like labels you will have to edit the /etc/fstab

#9

Thank you for the hint. On previous OpenSuse installations, disks were mounted by ID (/dev/disk/by-id). I already noticed that disks are now mounted by GUID, so I am expecting that there is no need to change fstab any more. I used to replace /dev/disk/by-id/… with /dev/sdaX.

About the attempt to re-create the bootloader, I understood it, but I am now trying to restore it using OpenSuse Rescue Disk, and it fails too. So I have a correct partition setup but a system that is not booting and I cannot restore grub. I am guessing that this should be possible, and that I am missing something.

I agree with you about the separate boot partition, I am trying to recreate it in the existing installation. I did not think about it since I was trying to go strightforward in the installation process (and yes, I also saw also the notices about the introduction of brtfs file system for root partition). So I’ll be back once I have more information about this attempt.

#10

I would think your biggest problem is in UEFI/EFI.

See Malcolm’s post above, I think you need to pay attention especially to his second option, from what I have read so far.

#11

It is unrelated to grub, but this means filesystem corruption. Unfortunately the only solution is to find out which file(s) are affected and delete them.

And grub2 gets installed. I get a warning saying that it cannot open /dev/share/locale. But no error reported.
However, after this, I get grub in console mode with no operating system listed (just grub prompt).

Looks like you do not have grub configuration in partition that was mounted as /mnt/boot (in /grub2 directory). Assuming boot is separate partition, you can try booting manually by using

search --file --set root /vmlinuz
linux /vmlinuz
initrd /initrd
boot

If /boot is not separate partition prepend /boot to pathnames above.

#12

Actually, the main source of issues is probably the btrfs where the root file system (and /boot too) resides that got corrupted. I still have to clarify why. As you pointed out, btrfs should be able to repair itself unless the broken files cannot be recoved. I don’t know if the wrong cksum could be due to an attempt to resize the partition made by clonezilla, since the new hard drive is some MiB smaller than the original one (so I had to resize the partitions).
I tried to execute btrfs check --check-data-csum (and --repair) but it just lists a number (some hundred of inodes) of cksum failures and it does not fix anything.

It seems that this causes the system to be unable to chroot, and that’s probably the reason why grub2-install fails. Filling in the grub options --directory, --boot-directory and --target does the trick, but it still shows some cksum failures and it stops on them. I did not try to execute a manual boot then, since I started to think that the files were messed up.
I did not try dd too, since the disk seems to be slightly different, and later I have to try to install on machines with similar (but not same) hardware. I need to use a guided tool because I have to show to someone else how to clone and restore the system.

Perhaps there are some changes in OpenSuse I should have been aware of: mainly the GUID partition table and the different default file systems proposed in setup phase.

I would have preferred a complete understanding of the issue, but I have the time against myself. So the best option was to perform a clean install with a 0x00 Grub partition at the beginning, a /boot partition formatted with ext file system, and just to be sure I used ext4 for both root and home partition. I tried to recover that image and it worked. I should have room to play with grub in case of different bios architectures via live recovery system, even if the first grub partition should not be mandatory.

So, now that it works, I have to thank you all for your advices and your helpful replies. Your kind interest has been higly appreciated.

#13

On 2014-12-11 15:06, wof wrote:
>
> Actually, the main source of issues is probably the btrfs where the root
> file system (and /boot too) resides that got corrupted. I still have to
> clarify why. As you pointed out, btrfs should be able to repair itself
> unless the broken files cannot be recoved. I don’t know if the wrong
> cksum could be due to an attempt to resize the partition made by
> clonezilla, since the new hard drive is some MiB smaller than the
> original one (so I had to resize the partitions).

Ah.

> I tried to execute btrfs check --check-data-csum (and --repair) but it
> just lists a number (some hundred of inodes) of cksum failures and it
> does not fix anything.

That’s one of the things that keep me off btrfs, not being sure that
fsck works reliably. :frowning:

> It seems that this causes the system to be unable to chroot, and
> that’s probably the reason why grub2-install fails.

Could well be.

> Filling in the grub
> options --directory, --boot-directory and --target does the trick, but
> it still shows some cksum failures and it stops on them. I did not try
> to execute a manual boot then, since I started to think that the files
> were messed up.

Yep.

> I did not try dd too, since the disk seems to be slightly different, and
> later I have to try to install on machines with similar (but not same)
> hardware. I need to use a guided tool because I have to show to someone
> else how to clone and restore the system.

Understandable.

My guess is that btrfs is so new, that things fail. fsck does not work
as it should, and possibly clonezilla can’t cope. Yet, hopefully.

> I would have preferred a complete understanding of the issue, but I have
> the time against myself. So the best option was to perform a clean
> install with a 0x00 Grub partition at the beginning, a /boot partition
> formatted with ext file system, and just to be sure I used ext4 for both
> root and home partition. I tried to recover that image and it worked.

Yes, clonezilla should know how to handle that situation better.

> I
> should have room to play with grub in case of different bios
> architectures via live recovery system, even if the first grub partition
> should not be mandatory.
>
> So, now that it works, I have to thank you all for your advices and your
> helpful replies. Your kind interest has been higly appreciated.

Welcome :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#14

It looks to me like the first issue would be this: Clonezilla cannot resize partitions smaller. The target destination must be equal or larger size for Clonezilla to successfully work. Also, note that Clonezilla uses dd to clone a disk.

It also looks to me that the best option for you in the situation you outline is to stick to the ext file system for now.

Just remember, when using Clonezilla: If the destination is smaller, shrink your partitions on the source drive before running Clonezilla.

It would probably work best if you: Shrink partitions, create an image instead of direct clone, create the target partition scheme, then restore partitions individually.

#15

On 2014-12-11 20:26, Fraser Bell wrote:

> It looks to me like the first issue would be this: Clonezilla cannot
> resize partitions smaller. The target destination must be equal or
> larger size for Clonezilla to successfully work. Also, note that
> Clonezilla uses dd to clone a disk.

Well, no, it uses other tools; dd is the last resort, used for
filesystems it does not understand. On those it knows about, it only
stores the regions with data (and grub code is not “data”, it is outside).

from their site:

Based on Partclone (default), Partimage (optional), ntfsclone
(optional), or dd to image or clone a partition. However, Clonezilla,
containing some other programs, can save and restore not only
partitions, but also a whole disk.
…
The destination partition must be equal or larger than the source one.

However, they might design around this limitation. Some payware
solutions did.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#16

Yes, and Clonezilla states that it is one of their long-term goals.

But, they said that a long time ago, still show it, and I have not yet seen any progress in that direction.

I guess it is quite low on their list of priorities.:wink:

#17

On 2014-12-11 21:26, Fraser Bell wrote:

> I guess it is quite low on their list of priorities.:wink:

It is complicated, because you have to remap all the directory entries.
If there is enough empty space, you can place the files; but then you
have to recalculate all the sector tables (inodes? fat? whatever?) so
that they point to the correct new locations (as some old locations
disappear on shrink).

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#18

I came across this same issue as well. I have been using Clonezilla to make back up images of my hard disks since openSUSE 10.3. I have always used the default settings for Clonezilla (i.e. savedisk-save_local_disk_as_an-image and restoredisk-Restore_an_image_to_local_disk) and I have always restored the Clonezilla image back to the original machine that the image was created from. I never had an issue restoring a Clonezilla image. I created my 13.2 installation with the default filesystem settings (BtrFS for root partition and XFS for home partition). When I restored the Clonezilla image, my machine was unable to boot although the partitions were restored correctly ( I verified via fdisk from the Rescue System on my Installation USB drive). I had this error:

Missing operating system.
No boot device available, Press ENTER key to retry
SATA-0: Installed
SATA-1: Installed
SATA-2: None
SATA-3: None
SATA-4: None
SATA-5: None

I created a new 13.2 installation with EXT4 for root partition and XFS for home partition (I changed the mount point to /srv since this is my server) and then made a Clonezilla image. After restoring the image with Clonezilla, my machine booted without a problem.

For the sake of curiosity, I created another 13.2 installation with XFS for both root and home partitions and made another Clonezilla image. After restoring image with Clonezilla, machine would not boot. I had this error:


error: attempt to read or write outside of partition.
error: attempt to read or write outside of partition.
error: attempt to read or write outside of partition. (repeated several more times)
error: file ‘/boot/grub/i386-pc/normal.mod’ not found.
Entering rescue mode…
grub rescue>

I will be using openSUSE 13.2 for a production web server and want to continue using Clonezilla (unless anyone can recommend another free cloning utility). Should I use EXT4 for both root and /srv partitions? Or is it okay to keep EXT4 for root and XFS for /srv partition? Thanks!

#19

Old thread, but 13.2 is still current and I’m running into it now (building the latest rendition of a computer lab at a uni), so I thought I’d give another option:

Boot with Rescue System from Installer. This assumes your /boot is somewhere in /dev/sda2 and is still happy. (My partitioning is /dev/sda1 = swap, /dev/sda2 = btrfs /, /dev/sda3 = xfs /home.)


mount /dev/sda2 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
grub2-install /dev/sda
exit 
reboot
#20

On 2015-08-11 21:26, irkby wrote:

> Old thread, but 13.2 is still current and I’m running into it now
> (building the latest rendition of a computer lab at a uni), so I thought
> I’d give another option:
>
> Boot with Rescue System from Installer. This assumes your /boot is
> somewhere in /dev/sda2 and is still happy. (My partitioning is /dev/sda1
> = swap, /dev/sda2 = btrfs /, /dev/sda3 = xfs /home.)
>
>
> Code:
> --------------------
>
> mount /dev/sda2 /mnt
> mount --bind /dev /mnt/dev
> mount --bind /proc /mnt/proc
> mount --bind /sys /mnt/sys
> chroot /mnt
> grub2-install /dev/sda
> exit
> reboot
>
> --------------------

Yes.

Clonezilla does not “clone” the grub installation, but tries to install
it again. If this fails, you have to do it yourself, for instance as you
described.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)