On Tue, Jul 15, 2014 at 09:01:47AM +0100, Richard W.M. Jones wrote:
The answer is I don't know. But there are a few things you can
try:
(1) Most importantly, enable tracing (export LIBGUESTFS_TRACE=1) and
get a list of operations that are performed in the order they are
performed. This is vital for debugging this.
(2) When the error happens, run `lsof'. Something like this:
try
g#part_add "/dev/sdb" (mbr_part_type p) p.p_target_start p.p_target_end;
if p.p_type = ContentExtendedPartition then
List.iter (
fun p ->
g#part_add "/dev/sdb" "logical" p.p_target_start
p.p_target_end
) p.p_partitions
with
G.Error msg ->
eprintf "lsof:\n---\n%s\n---\n" (g#debug "sh" [|
"lsof" |]);
eprintf "original error:\n" msg;
exit 1
This should tell you which processes have partitions open, which
should give the reason why the kernel cannot reread the partition
table.
(3) "Rebooting the appliance" means reopening the libguestfs handle,
which virt-resize already does at least once. See the comment:
(* After copying the data over we must shut down and restart the
* appliance in order to expand the content. The reason for this may
* not be obvious, but it's because otherwise we'll have duplicate VGs
* (the old VG(s) and the new VG(s)) which breaks LVM.
*
* The restart is only required if we're going to expand something.
*)
I hope we don't have to do it again, but it might be necessary based
on the full analysis of (1) & (2).
Rich.
Thanks, your suggestions are helpful, I'll have a try.
Regards,
Hu