Menu

Failed to install grub

2017-10-12
2017-10-17
  • Adam Weremczuk

    Adam Weremczuk - 2017-10-12

    Hello,

    I took a full disk image of a 4TB virtual disk (RAID50+2 on ServeRAID-M5014) from IBM X3650 M3 server.
    The source system runs Debian 7.1 and uses LVM.
    For the image I used a 6TB HGST AF disk in an Anker docking station connected via USB.

    Then I attempted a restore to a 4TB virtual disk (slightly higher size than the source, it's RAID10+2 on PERC H730P Mini) on Dell PowerEdge R730.
    The restore took 2 x 16 hrs rounds (never seen 2 long runs before) and on the second run it was explicitly prompting me for restoring every single LVM volume.

    For backup and restore I used the latest Clonezilla 2.5.2-31-amd64.
    The only difference being for backup I used bootable USB and for restore a live CD as the server failed to boot of the USB for some reason.

    I didn't see any errors in the restore process until the very end: "Failed to install grub".

    A final screen shot below:

    https://drive.google.com/file/d/0B2GgcGgLUlJgWFFGVktnZWlHZDA/view?usp=sharing

    As a result the destination server fails to even start booting from the local disk.

    Does anybody know what went wrong and how to fix it?

    Is performing the same full restore to the original hardware more likely to work?

    Thanks
    Adam

     

    Last edit: Adam Weremczuk 2017-10-12
  • Adam Weremczuk

    Adam Weremczuk - 2017-10-12

    Some output generated from Debian 9 live CD running on the unbootable target Dell server:

    fdisk -l
    Disk /dev/sda: 3.8 TiB, 4196848631808 bytes, 8196969984 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Disk identifier: 30A7726B-5F2A-4A55-B2CD-4D97433914AB
    
    Device      Start        End    Sectors  Size Type
    /dev/sda1    2048       4095       2048    1M BIOS boot
    /dev/sda2    4096     249855     245760  120M Microsoft basic data
    /dev/sda3  249856 7796865023 7796615168  3.6T Linux LVM
    

    Where "Microsoft basic data" is coming from as both the source system and Clonezilla are Linux Debian based?
    Is it something Clonezilla created trying to make the disk bootable?

    (parted) print /dev/sda
    Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 400102912 blocks) or continue with the current setting?
    parted: invalid token: /dev/sda
    Fix/Ignore? I
    Model: DELL PERC H730P Mini (scsi)
    Disk /dev/sda: 4197GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags:
    
    Number  Start   End     Size    File system  Name  Flags
     1      1049kB  2097kB  1049kB               grub  bios_grub
     2      2097kB  128MB   126MB   ext3         boot  msftdata
     3      128MB   3992GB  3992GB               lvm   lvm
    

    Still not sure what the best way forward is...

    Would it be of any benefit trying to edit volumes of the LVM partition (with LVM tools as direct mounting is not possible)?

    Or maybe rather attempting grub2 install / repair?

     

    Last edit: Adam Weremczuk 2017-10-12
  • Steven Shiau

    Steven Shiau - 2017-10-12

    First, backup important data before you use Clonezilla. Just in case.
    Second, RAID is complicated, so Clonezilla does not fully support it. It might work, but might fail.
    So which version of Clonezilla live did you use? Did you try the latest stable or even testing Clonezilla live?
    http://clonezilla.org/downloads.php

    Steven

     
  • Adam Weremczuk

    Adam Weremczuk - 2017-10-13

    Hi Steven,

    I used the latest Clonezilla 2.5.2-31-amd64 live USB for backup and 2.5.2-31-amd64 live CD for restore.

    I'm not too concerned about the data at this stage yet.
    The destination server B is not needed for anything else and the source server A hasn't been overwritten yet (more details about my goals down below).

    The goal of this exercise was to verify if the whole disk image taken by Clonezilla can be restored.
    It doesn't look like it can be restored to a different RAID-ed hardware.

    The more important question to me is:
    What are my success chances of restoring back to the same (source) hardware?
    Since I can't really prove I can restore this, it will remain a gamble.

    I used Clonezilla in the past with great success for cloning single drives with physical partitions but never for RAID-ed servers with LVM.
    So another question is if Clonezilla is the best choice for what I'm trying to achieve in a fairly automated and hassle free fashion?

    Let me point out my (fairly complicated) scenario for clarity:

    1. Back up server A to a single image.

    2. Restore that image to server B (different hardware) to verify if restore works.

    3. Backup server C to a single image.
      This server has identical hardware as server A - chassis, disks, RAID card and config, firmware etc.
      It has much more memory, and much lower "milage".

    4. Restore image of server C taken in point 3 to server A.
      Data destruction occurs here, the only backup of server A is now the image taken in point 1.

    5. Restore image of A from point 1 to server C.

    The ultimate goal is to hardware swap servers A and C.
    Data of server C is much more important than A.
    All servers use RAID and LVM.

    Any advise would be appreciated.

    Thanks
    Adam

     
  • Steven Shiau

    Steven Shiau - 2017-10-15

    "What are my success chances of restoring back to the same (source) hardware?" -> As I have mentioned, RAID is complicated., and Clonezilla does not fully support it. Therefore actually I do not have any idea about the chance. You will only know after you test it.

    Steven

     
  • Adam Weremczuk

    Adam Weremczuk - 2017-10-17

    Could the filesystem on the drive used for storing images (e.g. NTFS vs EXT4) potentially make any difference?
    In my case it's NTFS.

     
  • Steven Shiau

    Steven Shiau - 2017-10-29

    That should make no difference since Linux can read and write ext4 or ntfs file system. Hence using either one of them as the image repository should be OK.

    Steven

     

Log in to post a comment.