#1437 Issue closed: It seems migration mode migrates only disks but not the bootloader¶
Labels: enhancement, bug, no-issue-activity
jsmeix opened issue at 2017-08-01 12:53:¶
I am playing around with the migration mode
using current ReaR master code:
First and foremost:
Currently I have no real practical experience with using
the migration mode so that I could do "stupid things".
But even if I do "stupid things" it would be nice if ReaR
could detect that and show an information message.
What I did:
I migrated an original system on a single /dev/sda onto
a replacement system with two disks /dev/sda and /dev/sdb.
First I used the new /dev/sda for an initial "rear recover"
and the recreated system works well.
Then (using the same replacement system) I tried
to migrate the original /dev/sda onto the new /dev/sdb
(and leave the existing new /dev/sda untouched).
After reboot from /dev/sdb it is /dev/sda2 that is mounted at '/'
in the recreated system instead of the expected /dev/sdb2.
Details:
During 'rear recover' (with
https://github.com/rear/rear/pull/1434)
I get (excerpts):
RESCUE e205:~ # rear recover
...
Comparing disks.
Device sda has size 22548578304, 21474836480 expected
Switching to manual disk layout configuration.
Original disk /dev/sda does not exist (with same size) in the target system
Choose an appropriate replacement for /dev/sda
1) /dev/sda
2) /dev/sdb
3) Do not map /dev/sda
4) Use Relax-and-Recover shell and return back to here
(default 1 timeout 300 seconds)
2
Using /dev/sdb (chosen by user) for recreating /dev/sda
Current disk mapping table (source -> target):
/dev/sda /dev/sdb
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default 1 timeout 300 seconds)
1
User confirmed disk mapping
...
Start system layout restoration.
Creating partitions for disk /dev/sdb (msdos)
Creating filesystem of type ext4 with mount point / on /dev/sdb2.
/dev/sdb2: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
Mounting filesystem /
Creating swap on /dev/sdb1
Disk layout created.
Restoring from '/tmp/rear.fn8jkb8erNoB8Md/outputfs/e205/backup.tar.gz'...
...
Restored 2435 MiB in 34 seconds [avg. 73364 KiB/sec]
Restoring finished.
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader
Finished recovering your system. You can explore it under '/mnt/local'.
RESCUE e205:~ # mount | grep sd
/dev/sdb2 on /mnt/local type ext4 (rw,relatime,data=ordered)
RESCUE e205:~ # cat /mnt/local/etc/fstab
# UUID=28e43119-dac1-4426-a71a-1d70b26d33d7 swap swap defaults 0 0
# UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 / ext4 acl,user_xattr 1 1
/dev/sdb1 swap swap defaults 0 0
/dev/sdb2 / ext4 acl,user_xattr 1 1
RESCUE e205:~ # reboot
But after reboot from /dev/sdb
it is /dev/sda2 that is mounted at '/' (instead of /dev/sdb2):
g198:~ # findmnt | grep sd / /dev/sda2 ext4 rw,relatime,data=ordered g198:~ # cat /etc/fstab # UUID=28e43119-dac1-4426-a71a-1d70b26d33d7 swap swap defaults 0 0 # UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 / ext4 acl,user_xattr 1 1 /dev/sda1 swap swap defaults 0 0 /dev/sda2 / ext4 acl,user_xattr 1 1
I did not yet check the details but on first glance it looks as if
the bootloader that was installed on /dev/sdb uses /dev/sda2
as root partition and because I had initially done a recovery
onto /dev/sda that even boots but it is not what I intended.
When I grep for MIGRATION_MODE in the sources
it is found only in those files:
layout/prepare/GNU/Linux/100_include_partition_code.sh layout/prepare/GNU/Linux/110_include_lvm_code.sh layout/prepare/default/010_prepare_files.sh layout/prepare/default/250_compare_disks.sh layout/prepare/default/300_map_disks.sh layout/prepare/default/320_apply_mappings.sh layout/prepare/default/400_autoresize_disks.sh layout/prepare/default/500_confirm_layout.sh layout/prepare/default/270_overrule_migration_mode.sh layout/recreate/default/100_ask_confirmation.sh
This indicates that migration mode migrates only disks
but not the bootloader.
Because I am not aware of user reports about this issue
I consider it only as a "minor bug" that bootloader is not
migrated in compliance with a disk migration.
I assume in practice the boot disk is not changed
(only the boot disk size may change in practice)
so that I assume bootloader migration is perhaps
not really important in practice.
jsmeix commented at 2017-08-01 13:55:¶
@gozora
because this issue is related to bootloader installation:
I do not understand how $VAR_DIR/recovery/bootdisk is used.
As far as I see this file is only written in
prep/GNU/Linux/300_include_grub_tools.sh
and prep/default/320_include_uefi_env.sh
but I cannot find where that information is ever used
during "rear recover".
Do you know how $VAR_DIR/recovery/bootdisk
is meant to be used?
As far as I see in
finalize/Linux-i386/620_install_grub2.sh
it installs the bootloader based on autodetected
information what device is mounted
in the recovery system at '/mnt/local/'
i.e. what should also be mounted later
in the recreated system at '/'.
It seems things work somewhat unpredictable
(at least for my tests):
I did a second try to recover on my replacement system
onto /dev/sdb (and leave its /dev/sda untouched) using
the same existing ReaR ISO image and backup.tar.gz.
In the recovery system before I run "rear recover" I get
RESCUE e205:~ # cat /var/lib/rear/recovery/bootdisk /dev/sda2 RESCUE e205:~ # cat /var/lib/rear/recovery/bootloader GRUB2
Both are right because it is what there is on the original system.
Now I recover on a replacement system onto /dev/sdb as described
in
https://github.com/rear/rear/issues/1437#issue-247058823
but now I run "rear -d -D recover" to get full debugging.
After "rear -d -D recover" I get in the still running
recovery system in the ReaR log file:
+ source /usr/share/rear/finalize/Linux-i386/620_install_grub2.sh ... ++ bootparts=/dev/sdb2 ... ++ bootdisk=/dev/sdb ... ++ grub2-install --root-directory=/mnt/local /dev/sdb Installing for i386-pc platform. grub2-install: warning: cannot open directory `/usr/share/locale': No such file or directory. Installation finished. No error reported.
Furthermore I get in the still running recovery system:
RESCUE e205:~ # grep 'root=' /mnt/local/boot/grub2/grub.cfg
set root='hd0,msdos2'
set root='hd0,msdos2'
set root='hd0,msdos2'
linux /boot/vmlinuz-4.4.21-69-default root=UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 resume=/dev/sda1 splash=silent quiet showopts
set root='hd0,msdos2'
linux /boot/vmlinuz-4.4.21-69-default root=UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 resume=/dev/sda1 splash=silent quiet showopts
set root='hd0,msdos2'
linux /boot/vmlinuz-4.4.21-69-default root=UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94
RESCUE e205:~ # ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 9 Aug 1 13:20 2017-08-01-09-40-25-00 -> ../../sr0
lrwxrwxrwx 1 root root 10 Aug 1 13:20 28e43119-dac1-4426-a71a-1d70b26d33d7 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Aug 1 13:20 46d7e8be-7812-49d1-8d24-e25ed0589e94 -> ../../sdb2
That looks to me as if the bootloader is correctly installed
onto /dev/sdb and this time after reboot from /dev/sdb
it is actually /dev/sdb2 that is mounted at '/' as expected.
At least for me something does not work consistently here:
Two subsequent "rear recover" using same ReaR ISO image and
same backup.tar.gz should not result different recreated systems.
jsmeix commented at 2017-08-01 14:55:¶
A third retry to recover on my replacement system
onto /dev/sdb (and leave its /dev/sda untouched) using
the same existing ReaR ISO image and backup.tar.gz
results again that /dev/sda2 gets falsely mounted on '/'
in the recreated system.
Also a fourth and a fifth retry results that /dev/sda2
gets falsely mounted on '/' in the recreated system.
gozora commented at 2017-08-01 15:52:¶
@jsmeix, I've never try migration mode actually, but I'll take a look as
it seems to be interesting topic.
It will take me some time however as my new computer arrived yesterday
and I need to do some installation work first ;-).
V.
schabrolles commented at 2017-08-23 11:38:¶
@jsmeix,
could you try again, but before starting a recover, try to wipe the
disks before with dd
dd if=/dev/zero of=/dev/sda bs=1M count=1000
dd if=/dev/zero of=/dev/sdb bs=1M count=1000
if the disks are not wiped, you could have twice the same UUID created for the FS (or maybe VG/LV duplicate). OS could mount the first device it gets as /
jsmeix commented at 2017-10-20 09:49:¶
Will not be solved for the ReaR v2.3 release
but later in a ReaR future release.
jsmeix commented at 2017-11-28 15:19:¶
Because of
https://github.com/rear/rear/issues/1271#issuecomment-347555836
I think this issue here is no longer a minor bug but a normal bug.
jsmeix commented at 2018-07-06 12:41:¶
Since
https://github.com/rear/rear/pull/1843
is merged therein the commit
https://github.com/rear/rear/pull/1843/commits/0ce177d1019064ec4f74110ed003579430b99d34
migrates also the GRUB2 bootloader installation on x86 compatible
architecture
according to the disk layout mapping.
When
https://github.com/rear/rear/pull/1848
gets merged
also the GRUB2 bootloader installation on PPC64/PPC64LE
gets migrated according to the disk layout mapping.
But currently nothing is done to migrate other bootloader
installations
according to the disk layout mapping.
github-actions commented at 2020-07-01 01:33:¶
Stale issue message
[Export of Github issue for rear/rear.]