#265 Unable to find target partition "sda3" (EBR-restore fails on restoreparts with -g auto & -k)

[Jan Ru]

Apparently I am facing near identical issues as reported in bug #254. If you thing that this bug should be marked as a duplicate, feel free to do so.

I previously used 'clonezilla-live-2.4.5-38-amd64' and tried to upgrade to 'clonezilla-live-2.4.7-31-amd64'. When creating a new, full disk-image using 2.4.7-31, all partitions were saved, including a (new) sda3-ebr file. The command to save the image was:

> /usr/sbin/ocs-sr -q2 -j2 -batch -z1p -i 4096 -fsck -p true savedisk DEV20160929 sda

For a later unattended batch-restore (partition-restore only!), I remotely copy the desired (older or current) image-sets directly onto sda6. As I only restore the root-partition (sda2) later on, this was never a problem before.

Now I receive idential errors to bug #254:
********.
Finding extended partition(s) in parted table /tmp/APPLY-tmp-cnvted/sda-pt.parted...
Restoring extended boot record (EBR) in extended partition /dev/sda3...
Unable to find target partition "sda3".
********.

from grub command-line to boot the unattended restore:
> ocsliverun="ocs-live-restore" ocsliveextraparam="-g auto -e1 auto -e2 -nogui -batch -j2 -cm -o0 -o1 -srel -k -p reboot -f sda2 restoreparts APPLY sda2" ocslivebatch=yes toram=filesystem.squashfs

As the image file to be restored resides on the same disk (on sda6) that will get a partition-restore (sda2, CentOS 7 root-partition with /boot as well on sda2), i HAVE to use "-k", as sda6 will be mounted during restore of sda2. BUT i also have to use "-g auto" to rewrite the MBR and reinstall grub during the restore process, as I use different image-sets where sometimes the sda2-root is installed on an XFS filesystem and at other times it uses EXT4. Without the additional "-g auto" grub does not get correctly reinstalled and the system cannot boot (due to changing EXT4 -> XFS or the other way round).

Apparently rewriting the MBR also triggers the restore of the EBR-partition, which cannot be written as I have to use "-k" as explained above. I believe this should not be the case! At least there should be an option to NOT write an EBR only because the MBR gets rewritten.

Due to this behaviour I cannot unattendedly use restoreparts, as near the end it breaks with an error and the system does not reboot without further user interaction!

---

in bug #254 you suggest that: clonezilla-live-2.4.7-28-amd64 should fix this issue. for my case though, the problem of the unrestoreable sda3-ebr remains. I tried 2.4.7-28, 2.4.7.29, 2.4.7-31 and the latest 2.4.8-10. The issue is reproduces with all of these versions identical.

In addition (e.g.) 2.4.7-31 is no longer able to use restoreparts unattendedly for older images saved with (e.g. 2.4.5-38). Those images did not yet save the sda3-ebr file (so it does not exist in those images) and in my constellation it could not rewrite the EBR anyhow.

---

Any suggestions on how to circumvent this? Or do you really need to fix this in clonezilla source to get the unattended restoreparts working again for cases that use only a single available disk in the system.

Attached are the small files from the image ... and the log-file for the broken restore process.

[Steven Shiau]

Please give Clonezilla live >=2.4.8-10 or 20160928-* a try:
http://clonezilla.org/downloads.php
There are some improvements about this.

Steven

[Steven Shiau]

Thanks, Jan.
The issue is triggered by requesting Linux kernel to re-read the partition table whlie the disk is busy. Then the extended partition will be gone from /proc/partitions. Therefore the function inform_kernel_partition_table_changed in ocs-functions should be skipped when disk is busy.
This was fixed and now the codes are in git repository.
The testing Clonezilla live released next week will include this fix.

Steven