[rear-users] Help migrating Scientific Linux 7.2

Johannes Meixner jsmeix at suse.de
Wed Aug 24 11:44:50 CEST 2016


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
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)



More information about the rear-users mailing list