#897 Issue closed: parted fails with "... unable to inform the kernel of the change ..."¶
Labels: won't fix / can't fix / obsolete
jsmeix opened issue at 2016-06-29 09:15:¶
Currenr rear master.
Basically same issue as https://github.com/rear/rear/issues/793
Now it happened for the very first time to me:
RESCUE e229:~ # rear -d -D recover Relax-and-Recover 1.18 / Git Using log file: /var/log/rear/rear-e229.log Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available. Started RPC portmapper 'rpcbind'. RPC portmapper 'rpcbind' available. RPC status rpc.statd available. NOTICE: Will do driver migration Calculating backup archive size Backup archive size is 787M /tmp/rear.NbvLlCLGb4hCGBR/outputfs/e229/backup.tar.gz (compressed) Comparing disks. Disk configuration is identical, proceeding with restore. Start system layout restoration. Creating partitions for disk /dev/sda (msdos) An error occurred during layout recreation.
and in /var/log/rear/rear-e229.log theer is
+++ echo -e 'Creating partitions for disk /dev/sda (msdos)' +++ my_udevsettle +++ has_binary udevadm +++ for bin in '$@' +++ type udevadm +++ return 0 +++ udevadm settle +++ parted -s /dev/sda mklabel msdos Error: Partition(s) 2 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) w ill remain in use. You should reboot now before making further changes. ++ (( 1 == 0 )) ++ LogPrint 'An error occurred during layout recreation.'
I can even reproduce it in that particular running
rear recovery system.
Therefore I will now play around with it
and try to change some rear script(s)
so that the issue is avoided.
jsmeix commented at 2016-06-29 09:36:¶
False alarm.
This is not https://github.com/rear/rear/issues/793
In my case parted is fully right to state
Error: Partition(s) 2 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.
because I had /mnt/local still mounted from a previos
intentionally by me interrupted "rear recover" run
in that same recovery system.
After I did "umount /mnt/local" another "rear recover" run
just works.
Therefore this issue here is invalid.
[Export of Github issue for rear/rear.]