Bug 684486

Just tried the same operation on an F14 machine, on an F12 guest, but with a newer version of libguestfs and the same thing happens after resizing - the guest stops during boot at "Booting from hard disk"

What is the virt-resize command line, and what is
the output of virt-resize with debugging enabled?

virt-resize --expand /dev/sda2 f12-disk0 f12-new.qcow2

also

virt-resize --resize /dev/sda1=+200M --expand /dev/sda2 balbec.qcow2 balbec-new.qcow2 --LV-expand /dev/VolGroup00/LogVol00

Created attachment 483979 [details]
debug output of virt-resize

It's not a proper solution, but did you try this?
http://libguestfs.org/virt-resize.1.html#guest_boot_stuck_at_grub

Ah - didn't think that applied.  It does fix the booting issue on one guest, though on the other it didn't work:


guestfish -i -a balbec-new.qcow2 
libguestfs: error: lvm_canonical_lv_name: lvm_canonical_lv_name_stub: /dev/mapper/vg0marcel-www1: No such file or directory
libguestfs: error: mount_options: mount_options_stub: /dev/mapper/vg0marcel-www1: No such file or directory

Is it possible to use guestfish with more than one image at a time?

(In reply to comment #6)
> Is it possible to use guestfish with more than one image at a time?

In general it's not a good idea -- this is a limitation of
LVM however, not of libguestfs.  LVM is troublesome
if two disks contain VGs with the same name, and reacts
particularly badly if two disks contain objects with
conflicting UUIDs.  This can easily happen if you clone guests
or (as in this case) you effectively duplicated a guest when
you resized it.

There is support in libguestfs itself to get around this
(see for example the virt-df code in
http://git.annexia.org/?p=libguestfs.git;a=blob;f=df/domains.c;hb=HEAD )
however it's not something that the casual user would do.

> guestfish -i -a balbec-new.qcow2 
> libguestfs: error: lvm_canonical_lv_name: lvm_canonical_lv_name_stub:
> /dev/mapper/vg0marcel-www1: No such file or directory
> libguestfs: error: mount_options: mount_options_stub:
> /dev/mapper/vg0marcel-www1: No such file or directory

I'm a bit unclear why you're getting this error though?  It
looks like you are adding just one disk.  If automatic
inspection (-i) fails, just add the disks and inspect
and mount them manually, eg:

$ guestfish -a balbec-new.qcow2
><fs> list-filesystems
><fs> mount /dev/VG/root /
><fs> mount /dev/sda1 /boot
[etc]

There's a second VG in the guest.  There's no need to resize that one, so I didn't include it in the virt-resize invocation.  vg0marcel-www1 is the single LV within that VG.

I should mention that though the link you sent fixed the booting problem on the other guest (with just 1 VG), the resizing didn't seem to have happened.

(In reply to comment #8)
> I should mention that though the link you sent fixed the booting problem on the
> other guest (with just 1 VG), the resizing didn't seem to have happened.

One at a time :-)

Re: virt-resize --expand /dev/sda2 f12-disk0 f12-new.qcow2

The trace (x 2) that you gave me for the 1 VG guest in
comment 4 shows that the PV was resized (no LV was
resized because you didn't ask for it).  Try running
'pvs' command in the guest - it should show the new size.

> There's a second VG in the guest.  There's no need to resize that one, so I
> didn't include it in the virt-resize invocation.  vg0marcel-www1 is the single
> LV within that VG.

In fact, no reason to mention any VGs at all.  PVs and LVs are
the only things that LVM can resize.  Use the --resize or
--expand options to name the PVs (== partitions) that you
want to resize.  There is no need to mention any PVs that you
don't want to resize.  And VGs don't need to be mentioned at
all because they don't have a distinct size, their size is just
the sum of their underlying PVs.

Yep, I've manually resized the LV and VG in f12 now.

Re. the error in https://bugzilla.redhat.com/show_bug.cgi?id=684486#c6 , I suppose it could be that because the LV in the second VG is mounted via /etc/fstab, guestfish is complaining because it can't find it, even though for resizing purposes it's not relevant?

(In reply to comment #10)
> Yep, I've manually resized the LV and VG in f12 now.
> 
> Re. the error in https://bugzilla.redhat.com/show_bug.cgi?id=684486#c6 , I
> suppose it could be that because the LV in the second VG is mounted via
> /etc/fstab, guestfish is complaining because it can't find it, even though for
> resizing purposes it's not relevant?

It's hard to tell without seeing the actual layout of
filesystems and /etc/fstab contents.  In any case you
don't have to use the -i option, as shown in comment 7
you can inspect and mount filesystems manually instead.

It seems the original boot problem is caused by GRUB's device.map:

(hd0)     /dev/sda

so perhaps virt-resize could check for that and change it to refer to something appropriate like /dev/vda?

It's an idea, but I'm not sure if it is completely safe to
do that.  If a guest is using legacy IDE drivers (instead of
virtio) then making this change would stop the ordinary
grub command from working inside the guest.  Of course, we
can detect whether or not the guest is using virtio drivers
(that is what we do in virt-v2v after all) but then this
becomes a rather complex process.

I would rather not break the boot loader in the first place.
Reinstalling it is an admission that we broke it.

Matt, any thoughts?

This bug has been dormant for a year, and F14 has been end of life for months. Rich, close or move to later fedora version?

Yeah let's close.  If this still happens with a recent
version of virt-resize (>= 1.16) then reopen it.