[rear-users] Help migrating Scientific Linux 7.2

James M. Pulver jmp242 at cornell.edu
Wed Aug 24 17:27:10 CEST 2016

Is there a way to skip deleting the partitions? Booting GParted later on 
shows that at least the 2 partitions are created on the disk (though I 
don't know about the LVM partitions) so just a way to then get REAR to 
copy the files back might be helpful...

James Pulver
CLASSE Computer Group
Cornell University

On 08/24/2016 05:44 AM, Johannes Meixner wrote:
> Hello,
> On Aug 23 14:39 James M. Pulver wrote (excerpt):
>> ... 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
> You need to run rear in debugscript mode and inspect its
> log file to find out what script causes this, cf.
> "Debugging issues with Relax-and-Recover (rear)" in
> https://en.opensuse.org/SDB:Disaster_Recovery
> Note that there is a special indirection (RFC 1925 6a) here:
> The diskrestore.sh script that contains the parted commands
> is generated by rear scripts - i.e. you would need to find out
> in what diskrestore.sh generating script the bug is.
> In gereral see
> https://github.com/rear/rear/blob/dev/doc/user-guide/06-layout-configuration.adoc
>> 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.
> This is a known issue that happens sometimes, see
> https://github.com/rear/rear/issues/791
> and the other issues that are mentioned therein,
> in particular see also
> https://github.com/rear/rear/issues/793
> which is about exactly your error message.
> The actual bug is not in rear but in the stack of
> lower level software pieces that create partitions
> namely parted plus udev plus kernel.
> Currently it is just a mess because those parts
> do not work well together and as a consequence
> in any system installer (like rear, YaST, Anaconda,
> Debian-Installer, Ubiquity, whatever else...)
> one needs strange workarounds that try to mitigate
> the issue but all those cannot really solve it as long as
> the lower level software stack works unreliably or more
> precisely as long as the lower level software stack works
> unpredictable. I think it works somewhat deterministic but
> for the parted user who cannot know what goes on internally
> beneath the surface the behaviour appears unpredictable.
> The basic problem is that after a command like
>  # parted /dev/sda mkpart primary ...
> has finished with zero exit code this does not mean that
> now one has the new partition /dev/sda1 available for use.
> Actually when parted has finished with zero exit code
> it only menas that parted has successfully changed some bytes
> on the raw /dev/sda harddisk device and in newer parted versions
> it may additionally mean that parted has successfully told the
> kernel that "something has changed on /dev/sda".
> But when the final result (the new partition /dev/sda1)
> will appear and be available for use happens asynchronously
> (by the kernel together with udev in concurrent offences ;-)
> so that after parted has finished with zero exit code can only
> "just wait as long as one thinks it is o.k. to wait until
>  /dev/sda1 may eventually appear or may never appear".
> Kind Regards
> Johannes Meixner

More information about the rear-users mailing list