hda is not a block device¶

Labels: support / question, fixed / solved / done

jandoe88 opened issue at 2016-09-16 08:58:¶

rear version (/usr/sbin/rear -V): Relax-and-Recover 1.18 / Git
OS version (cat /etc/rear/os.conf or lsb_release -a): Debian GNU/Linux 5.0 \n \l
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://192.168.77.31/srv/nfs/"
AUTOEXCLUDE_PATH=( /data )
Brief description of the issue:
I try p2v of a physical machine with debian 5, software raid and lvm. Mkbackup works without problems. Restore on kvm (also tested restore on real hardware) is not working. I get the following error:
ERROR: BUG BUG BUG! Disk /dev/hda is not a block device
Any ideas?

Recovery logfile:

jsmeix commented at 2016-09-16 11:38:¶

Do what the log file recommends:

HINT: If you can reproduce the issue, try using the -d or -D option !

In general see the section
"Debugging issues with Relax-and-Recover (rear)" at
https://en.opensuse.org/SDB:Disaster_Recovery

I think the "Disk /dev/hda is not a block device." message
comes from the create_disk() function in
usr/share/rear/layout/prepare/GNU/Linux/10_include_partition_code.sh
therein the code

    [[ -b "$disk" ]]
    BugIfError "Disk $disk is not a block device."

I.e. in your target system /dev/hda is not a block device.

When you are in the recovery system before you run
"rear recover" inspect your target system and verify that
the contens of your var/lib/rear/layout/disklayout.conf
are appropriate for what there actually is in your
target system.

In general regarding migration:

In general migrating a system onto different hardware
(or from physical to virtual hardware) does not "just work".

In sufficiently simple cases it may "just work" but in general
do not expect too much built-in intelligence from a program
(written in plain bash which is not a programming language
that is primarily meant for artificial intelligence ;-)
that would do the annoying legwork for you.

To migrate a system onto different hardware you usually
have to adapt your disklayout.conf from the "old" system
to make it appropriate for the "new" system.

For an example you may have a look at the
"P2V HP microserver to VmWare" issue
https://github.com/rear/rear/issues/943

To mitigate the annoying migrating legwork a bit,
I recommend the newest rear GitHub master code that provides
some first steps for RECOVERY_UPDATE_URL support.

See default.conf how RECOVERY_UPDATE_URL is meant to work:
https://raw.githubusercontent.com/rear/rear/dev/usr/share/rear/conf/default.conf

For an example how RECOVERY_UPDATE_URL works see
https://github.com/rear/rear/issues/943#issuecomment-236547810

But when you use the latest rear master code see
https://github.com/rear/rear/issues/943#issuecomment-237544630
what is special about the disklayout.conf file location
in the recovery system that you must consider
to make RECOVERY_UPDATE_URL work.

gdha commented at 2016-09-21 08:17:¶

@jandoe88 I guess your missing the right kernel module for the disk devices on the target system (due to the p2v move). If you know which kernel module it is, you have to make sure it is copied on the source system (via LOAD_MODULES) during the creation of the rear ISO image.

jsmeix commented at 2016-09-21 08:30:¶

Or /dev/hda may not at all exist on the new system.

On virtual machines the device node for a virtual harddisk
could be something like "/dev/vda", cf. the section
"First steps with Relax-and-Recover (rear)" in
https://en.opensuse.org/SDB:Disaster_Recovery

E.g. on my SLES12-SP2-RC2 virtual KVM/QEMU machine:

# test -b /dev/hda || echo no block device
no block device
# ls -l /dev/hda
ls: cannot access '/dev/hda': No such file or directory

jandoe88 commented at 2016-09-21 08:30:¶

Hi. Thanks for your help jsmeix and gdha.
I figured it out, it works now. There were different problems:

The hard disk was shown in dmesg but not in fdisk.
Solution: Device in /dev was missing, create it manually
mknod /dev/sda b 8 0
mknod /dev/sda1 b 8 1
mknod /dev/sda2 b 8 2
[...]
Kernel module for software raid had to be loaded manually:
modprobe md
diskrestore.sh had to be changed during recovery:
echo "Y" | mdadm --create /dev/md0 --force --metadata=00.90
to
echo "Y" | mdadm --create /dev/md0 --force --metadata=0.90

After that, the recovery worked as expected :)

Best regards,
Jan

jsmeix commented at 2016-09-21 08:31:¶

@jandoe88
many thanks for your feedback what the actual issue was
in your particular case and how you got it working!

jsmeix commented at 2016-09-21 08:37:¶

@gdha
I think in this case

BugIfError "Disk $disk is not a block device."

is not the right kind of error.
In migration mode it should be

StopIfError "Disk $disk is not a block device."

because in migration mode that issue is
(with probability one) not a bug in rear.

[Export of Github issue for rear/rear.]

#1000 Issue closed: Error at rear recover: Disk /dev/hda is not a block device¶