[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
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...
CLASSE Computer Group
On 08/23/2016 12:46 PM, Johannes Meixner wrote:
> 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
> 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
> 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:
> For an example how RECOVERY_UPDATE_URL works see
> But when you use the latest rear master code see
> 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