#574 Issue closed: GPT: parted unable to inform kernel about partition changes¶
Labels: waiting for info, support / question
abbbi opened issue at 2015-04-08 20:45:¶
hi,
on a recent system (ubuntu 14.04) we had troubles finishing the recovery process with rear. The log showed that parted was unable to inform the kernel about the changes (like partprobe -s does), the detailed error message was the one from libparted/arch/linux.c:
("Partition(s) %s on %s 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) will remain in use. You "
"should reboot now before making further changes."
as i understand this error is shown as parted has tried to setup the GPT
information
and fails to update the kernel tables.
So what happened on this system in detail is:
- rear recover errored out as parteds exit code changes, error message above was shown in the recovery log
- i then tried to reboot the system (even tho i didnt think it to help)
- after the reboot, rear recover managed to create the GPT tables and partitions, it then continued with the LVM volumes and errored out to setup some logical volumes as the device was still in use
I did not have any more time left to analyze issue 3, but i went on and executed the commands from diskrestore.sh by hand. In the end i was able to create all partitions and LVM volumes without problem and also formatted and mountet them to /mnt/local, without even using partprobe.
It may as well be some timing issue between creating the partitions and
running partprobe, or maybe
even a problem with the kernel verison in use.
The question is: may it be appropriate to ignore the error from libparted?
gdha commented at 2015-04-09 08:47:¶
@abbbi is it possible to paste the diskrestore.sh script? I think it
might be a timing issue (as personally I never encountered this behavior
yet)
abbbi commented at 2015-04-09 10:01:¶
Hi,
its ok with creating the partitions for /dev/sda, /dev/sbd however
allways seems to error out with that
message, no matter:
rear> parted -s /dev/sdb mklabel msdos
Error: Partition(s) 1 on /dev/sdb 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) will remain in use. You should
reboot now before making further changes.
It does not help if i add a sleep statement of 5 seconds between the
parted calls. I continued
executing the commands from the diskrestore.sh script by hand and it
seems to work, at least i got
/dev/sdb setup with the volume group and LVMS desired. Im just not sure
if they will survive an
reboot.
abbbi commented at 2015-04-09 13:50:¶
Hi again,
we were able to recover the system with manual Steps. The issue was not as simple as though: The error which was repoted from parted can be ignored, but we ran into other troubles.
The customer had a system with GPT enabled and used GRUB2. As it is my
understanding
if using GRUB2, on the boot disk there has to be a small partition with
the flag "bios_grub". This partition is then used for grub2 to install
its boot files.
This partition was not listed in disklayout or diskrestore files. From the vcfgbackup we could see that before the restpore on /dev/sda1 there was an LVM volume. I could not identify any volume with the bios_grub flag set from the files we had.
We created the needed partition for grub, switched the lvm to another
partition and could then succesfully re-install the bootloader and boot
the system. I think the system was either migrated
from MBR -> GPT at one time or there is some special setup (ubuntu
has a no_bios_grub install
option) were grub2 is used with GPT without having a seperate Grub BIOS
partition.
Still the question if is rear should ignore the error from parted or at least ask to continue despite the error.
gdha commented at 2015-04-09 15:07:¶
@abbbi Concerning your question Still the question if is rear should
ignore the error from parted or at least ask to continue despite the
error?
If we decide to continue then we should ask the customer, however, the
customer will probably always say YES, and, we should not break
automated recover processes.
@schlomo what are your thoughts on this topic?
gdha commented at 2015-08-06 12:51:¶
@abbbi is this issue still valid with the latest rear snapshot?
gdha commented at 2015-10-29 19:10:¶
no further input received, therefore, we close this issue. If needed it can be re-opened
[Export of Github issue for rear/rear.]