[rear-users] Help migrating Scientific Linux 7.2

James M. Pulver jmp242 at cornell.edu
Tue Aug 23 20:39:18 CEST 2016

So if I get an error with 1.18.3 (which I upgraded to from the rpm on 
OpenSUSE - which btw is the same error as with the 1.17-2) that
device sda has size 31376707072, 256060514304 expected

And then I get issues with partition 11 again. Looking at it, it seems 
like there's a bug that's adding a 1 to the front of the partition for the
parted -s /dev/nvme0n1 set 11 boot on
should be
parted -s /dev/nvme0n1 set 1 boot on

setting 11 to 1 and 12 to 2 in the restore script lets it continue till 
it gets to partprobe. I get a message error informing the kernel about 
modifications to partition /dev/nvme0n1p1 -- device or resource busy. So 
I think I need to figure this bit out...

James Pulver
CLASSE Computer Group
Cornell University

On 08/23/2016 12:46 PM, Johannes Meixner wrote:
> Hello,
> On Aug 23 11:33 James M. Pulver wrote (excerpt):
>> I have a Lenovo S30 that I have SL7.2 installed on an SSD, sda.
>> I want to try and migrate to a Lenovo P510 that has a NVMe SSD,
>> nvme0n1 I believe. I also have a second local SSD that I just
>> plan to physically move to the P510.
> Regarding NVME see the issue
> https://github.com/rear/rear/issues/787
> which means you need at least Relax-and-Recover version 1.18
> to have support for NVME SSD disks.
> In general migrating a system onto different 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.
> Kind Regards
> Johannes Meixner

More information about the rear-users mailing list