GRUB2 issues / not booting on VM "recovered" from a Clonzilla image backup

Hi all,

aside to regular BackInTime and rsnapshot/rsync based backups I’m also making Clonezilla backups of my Leap box (15 currently, but started to use Clonezilla at 42.1 or so).
Needed the file based backups sometimes, never needed a bare metal recovery, so to be honest: Never tested it before.

Having now after some smaller issues qemu running fine, I’ve created a Clonezilla based VM and tried to restore my Clonzilla-backed-up SSD (latest 42.3 image, but doesn’t matter) to a virtual disk (qcow2). Went well, created a new Leap 15 server only VM, can mount all recovered partitions, and access all files.

BUT, when creating another VM with the “recovered” qcow2 virtual disk as primary hdd, this VM starts the GRUB menu, and no chance for me to get any step further.
Whyever, even no (meaningful for me) error message was shown.

  • When waiting for grub2 to boot the default option, msgs are like this (translated from German):
Linux 4...... is loaded
Initial Ram Disk is loaded
Failed to boot both default and fallback entries

Got this msg first after digging into grub2 docs and stripping all graphical etc. options from /boot/grub2/grub.cfg, otherwise msgs dissappeared at once.

Tried also to grub2-boot manually from grub2’s console, but I’m not familiar with this. Didn’t work manually for me even on a fine booting system :slight_smile:

Currently I’ve no idea what else to try to get my “recovered” qcow2 file booted.

I’ve tested that qemu with uefi/ovmf can boot an OpenSuse Leap 15 VM, installed from scratch, and even with secure boot, no issues.

Also checked that the UUIDs of my SSD’s partitions have “survived” Clonezilla image to qcow2 recovery, they are still the same. (No idea if sensitive data, real uuid value in this post substituted by “correctly-recovered-uuid”)

And I’ve tested the command

search --no-floppy --fs-uuid --set=root correctly-recovered-uuid

in grub2 console, returns with no error. If I change a single character for UUID, I’m getting an error

This is my current /boot/grub2/boot.cfg, and hints highly welcome :slight_smile:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if  -f ${config_directory}/grubenv ]; then
  load_env -f ${config_directory}/grubenv
elif  -s $prefix/grubenv ]; then
  load_env
fi

if  "${env_block}" ] ; then
  load_env -f "${env_block}"
fi

if  "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   if  "${env_block}" ] ; then
     save_env -f "${env_block}" next_entry
   fi
   set boot_once=true
else
   set default="${saved_entry}"
fi

if  x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if  "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if  -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
    if  "${env_block}" ] ; then
      save_env -f "${env_block}" saved_entry
    fi

  fi
}

function load_video {
  if  x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if  x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
if  x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
else
  search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
fi
    font="/usr/share/grub2/unicode.pf2"
fi

if loadfont $font ; then
echo "Please press t to show the boot menu on this console"
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
insmod part_gpt
insmod ext2
if  x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
else
  search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
fi
insmod gfxmenu
loadfont ($root)/boot/grub2/themes/openSUSE/ascii.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans10.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans12.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans-Bold14.pf2
insmod png
set theme=($root)/boot/grub2/themes/openSUSE/theme.txt
export theme
if  x${boot_once} = xtrue ]; then
  set timeout=0
elif  x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=8
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=8
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
### END /etc/grub.d/00_tuned ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE Leap 42.3'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-correctly-recovered-uuid' {
    insmod gzio
    insmod part_gpt
    insmod ext2
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
    else
      search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
    fi
    echo    'Linux 4.4.114-42-default wird geladen …'
    linux    /boot/vmlinuz-4.4.114-42-default root=UUID=correctly-recovered-uuid  showopts video=VGA-1:d vga=795
    echo    'Initiale Ramdisk wird geladen …'
    initrd    /boot/initrd-4.4.114-42-default
}
submenu 'Erweiterte Optionen für openSUSE Leap 42.3' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-correctly-recovered-uuid' {
    menuentry 'openSUSE Leap 42.3, mit Linux 4.4.114-42-default' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.114-42-default-advanced-correctly-recovered-uuid' {
        insmod gzio
        insmod part_gpt
        insmod ext2
        if  x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
        else
          search --no-floppy --fs-uuid --set=root correctly-recovered-uuid
        fi
        echo    'Linux 4.4.114-42-default wird geladen …'
        linux    /boot/vmlinuz-4.4.114-42-default root=UUID=correctly-recovered-uuid  showopts video=VGA-1:d vga=795
        echo    'Initiale Ramdisk wird geladen …'
        initrd    /boot/initrd-4.4.114-42-default
    }
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if  -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif  -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

### BEGIN /etc/grub.d/50_bootcycle ###
# created for bootcycle detection
menuentry 'halt' {
    halt
}
### END /etc/grub.d/50_bootcycle ###

### BEGIN /etc/grub.d/80_suse_btrfs_snapshot ###
### END /etc/grub.d/80_suse_btrfs_snapshot ###

### BEGIN /etc/grub.d/90_persistent ###
### END /etc/grub.d/90_persistent ###

### BEGIN /etc/grub.d/95_textmode ###

    # On EFI systems we can only have graphics *or* serial, so allow the user
    # to switch between the two
    hiddenentry 'Text mode' --hotkey 't' {
    set textmode=true
    terminal_output console
    }
### END /etc/grub.d/95_textmode ###


Is your VM using OVMF? Did you test legacy BIOS if it makes any difference?

Somehow grub fails to actually launch loaded kernel. It could be problem of “linux” loader in EFI environment (as opposed to “linuxefi”). Alternatively you may try “linuxefi” and “initrdefi” instead of “linux” and “initrd” if running under OVMF.

I think your problem may be more due to however you are creating your new VM and perhaps nothing to do with the origins of your disk (cloned using Clonezilla).

Exactly how are you creating your new machine?

And BTW -
If you’re more interested in just creating a new machine properly and less about why what you’re doing is not working,

You should use the cloning function provided by your virtualization technology.
No matter what virtualization you’re using, when you do this the following happens…

  • The virtual disk is duplicated
  • The methods your bootloader (Grub2 in your case) are preserved, pointing to your OS partition(s)
  • A new virtual machine ID is generated so that your clone is unique.
  • Typically (AFAIK Virtualbox is the only one that provides an option not to do this), a new MAC address is generated for your virtual NIC to avoid conflicts with the original vm.
  • You’ll probably need to rename the Hostname of your machine to complete the cloning.

TSU

@arvidjaar: Thank you for this hint!!
Yes, both VMs, the newly installed and the “recovered” are using OVMF.
Changing “linux” to “linuxefi” and “initrd” in “initrdefi” - which I’ve overlooked that this has been set automatically for the booting newly installed VM - now starts to boot from the “recvovered” disk.
I’m running in a new issue very soon, “A start job is running für dev-disk-by-uuid … .device …” runs forever. But it’s a new issue, on step further :slight_smile:

@tsu2: Thank you, too, for your detailed answer and valuable hints for future VMs. Currently I’m not really “interested” in the VM itself, I only want to prove once that I’m able to recover my Clonezilla image backup. Could of course also be done on an own second physical disk, which I don’t have available right now, at least not as big as needed. That’s why I’ve “recovered” the Clonezilla image file on the same external usb3 used for backups hdd to a qcow2 file, and trying to use this qcow2 file with a one-shot VM. As soon as I see that “recovery” works and that I can boot and login into Plasma, I’ll shutdown and drop the VM, and the qcow2 file.

P.S.: Sorry for being a little unpolite and answering to my own started thread delayed, both of you asnwered the next day, thanks a lot! Reason is that I’ve expected to get a notification about new answers to my thread, which was not the case. Have to look in my profile if I can find some options to be set :slight_smile:

This is worth bug report. I would expect “linux” loader to still work.

I’m running in a new issue very soon, “A start job is running für dev-disk-by-uuid … .device …” runs forever.

Does UUID match anything in your original VM?

Yes, checked very thoroughly, to be sure no typos (started booting-fine vm, with “recovered” disk used as second disk, mounted second disk’s partitions, opened boot/grub2/grub.cfg in vi, searched for all uuids “blkid” showed in a second ssh windows on this vm, all are matching).

No idea why not working. Found at first that “recovered” disk has an etc/fstab containing entries starting with “/dev/disk/by-id/…”, with physical hdd specific values like “ata-SanDisk_SDSSD…”. Changed them to valid UUID=… lines, don’t work either.
Changed finally to “traditional” “/dev/…” values:

/dev/vda2 swap                 swap       defaults              0 0                                                                  
/dev/vda3 /                    ext4       acl,user_xattr        1 1                                                                  
/dev/vda1 /boot/efi            vfat       umask=0002,utf8=true  0 0                                                                  
/dev/vda4 /home                ext4       acl,user_xattr        1 2  

–> Still getting this "“A start job is running für dev-disk-by-uuid … .device …” msg, forever.

Last succesful boot msg before is “Reached target Basic system”, afaik this is already a sytemd msg. Searched for any .device which might cause the wait-forerver. not a single one exists. Also afaik fstab should be “source-of-truth” for systemd, or?
No ideas anymore, currently. Maybe more tomorrow :slight_smile:

Not sure if this might be a reason for a separate new thread, but I would like to ask a general question:

**Do we have some HOWTO/FAQ etc. about cloning/moving an OpenSuse system from one system to another? **

I think my issues have nothing to do anymore with my tried “Clonezilla to QEMU” way, I strongly believe that I would have run into the same issue when restoring to another physical hdd, same hardware. Or another physical hdd plus other hardware.
Currently I’m able to “tweak” the “to be recovered” system by mounting the disk to a different vm and change whatever I need.

But my intention to use Clonezilla was to be able in case of a real disk failure to purchase a new ssd, install it, restore the latest Clonezilla image and be able to boot.
Far away from that point, currently, unfortunately :frowning:

Got the thankworthy hint in #SUSE that “Basic system” is in systemd phase of the boot process, and that I might want to look into the initrd file. unxz-ed and cpio-i-ed the file, but unfortunately no etc/fstab inside.

[SOLVED]

Whatever went wrong in my way, working solution to “virtualize” a Clonezilla image backup is as follows:

  • Recover image to virtual disk (e.g. qcow2)
  • Create new VM, select option “to be installed from ISO”
  • select Leap/TW ISO desired
  • start vm and select ISO’s grub boot option “RESCUE SYSTEM”
  • Follow this doc: https://www.suse.com/de-de/support/kb/doc/?id=7018126 step by step, up to “mount -a”.
  • Be sure that chrooted /etc/fstab is correct !
  • perform a “mkinitrd” at last step

That’s it, in my case.

Many thanks again here to arvidjaar and tsu2, for helping !
Special thanks to “luc14n0” in #SUSE for the URL hint above !

Would like to file this as a bug on bugzilla.opensuse.org.
But for what component? Grub(2)? dracut/mkinitrd? Qemu?
Hints welcome :slight_smile: