Libguestfs - Oct 2017 - [PATCH] builder: templates: For RHEL, CentOS >= 7 and all Fedora, default to GPT.

I didn't test this one fully yet, but I'm building Fedora 26 ppc64/le
test images now.  However it seems like it could be a good idea.  I
wonder if anyone depends on the images we supply being MBR-based?

Rich.

The immediate issue is with Fedora/ppc64 and /ppc64le which currently
use extended partitions, breaking the virt-builder ‘--size’ parameter,
eg:

  $ virt-builder --arch ppc64le fedora-26 --size 20G
  ...
  [  21.6] Resizing (using virt-resize) to expand the disk to 20.0G
  virt-resize: error: /dev/sda5: partition not found in the source disk image
  (this error came from '--expand' option on the command line).  Try
running
  this command: virt-filesystems --partitions --long -a /var/tmp/vbf67b8c.img

However more generally MBR is broken and should die.  GPT is supported
by all modern virtual bootloaders, so just default to it.

Notes:

* This is different from mandating a UEFI bootloader.

* I am not planning to rebuild any existing images except the
  F26 ppc64 & ppc64le ones.
---
 builder/templates/make-template.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builder/templates/make-template.ml
b/builder/templates/make-template.ml
index 8667bfa3e..38c7a36e3 100755
--- a/builder/templates/make-template.ml
+++ b/builder/templates/make-template.ml
@@ -486,7 +486,7 @@ part /     --fstype=%s   --size=1024 --grow --asprimary
    | CentOS _ | RHEL _ | Fedora _ ->
       bpf "\
 zerombr
-clearpart --all --initlabel
+clearpart --all --initlabel --disklabel=gpt
 autopart --type=plain
 ";
    | _ -> assert false (* cannot happen, see caller *)
-- 
2.13.2

On Tue, Oct 17, 2017 at 04:35:51PM +0100, Richard W.M. Jones
wrote:
> The immediate issue is with Fedora/ppc64 and /ppc64le which currently
> use extended partitions, breaking the virt-builder ‘--size’ parameter,
> eg:
> 
>   $ virt-builder --arch ppc64le fedora-26 --size 20G
>   ...
>   [  21.6] Resizing (using virt-resize) to expand the disk to 20.0G
>   virt-resize: error: /dev/sda5: partition not found in the source disk
image
>   (this error came from '--expand' option on the command line). 
Try running
>   this command: virt-filesystems --partitions --long -a
/var/tmp/vbf67b8c.img
Before this change, the fedora-26-ppc64 template looks like:

  Name       Type        VFS      Label  MBR  Size  Parent
  /dev/sda1  filesystem  unknown  -      -    4.0M  -
  /dev/sda2  filesystem  ext4     -      -    1.0G  -
  /dev/sda3  filesystem  swap     -      -    615M  -
  /dev/sda4  filesystem  unknown  -      -    1.0K  -
  /dev/sda5  filesystem  xfs      -      -    4.4G  -
  /dev/sda1  partition   -        -      41   4.0M  /dev/sda
  /dev/sda2  partition   -        -      83   1.0G  /dev/sda
  /dev/sda3  partition   -        -      82   615M  /dev/sda
  /dev/sda4  partition   -        -      05   1.0K  /dev/sda
  /dev/sda5  partition   -        -      83   4.4G  /dev/sda
  /dev/sda   device      -        -      -    6.0G  -

Note it's using MBR with an extended partition.

After this change:

  Name       Type        VFS      Label  MBR  Size  Parent
  /dev/sda1  filesystem  unknown  -      -    4.0M  -
  /dev/sda2  filesystem  ext4     -      -    1.0G  -
  /dev/sda3  filesystem  swap     -      -    615M  -
  /dev/sda4  filesystem  xfs      -      -    4.4G  -
  /dev/sda1  partition   -        -      -    4.0M  /dev/sda
  /dev/sda2  partition   -        -      -    1.0G  /dev/sda
  /dev/sda3  partition   -        -      -    615M  /dev/sda
  /dev/sda4  partition   -        -      -    4.4G  /dev/sda
  /dev/sda   device      -        -      -    6.0G  -

I didn't test virt-builder "full stack" yet, but virt-resize has
no
problem, so this does appear to fix the original bug:

  $ virt-resize fedora-26-ppc64 output --expand /dev/sda4
  $ virt-filesystems -a output --all --long -h
  Name       Type        VFS      Label  MBR  Size  Parent
  /dev/sda1  filesystem  unknown  -      -    4.0M  -
  /dev/sda2  filesystem  ext4     -      -    1.0G  -
  /dev/sda3  filesystem  swap     -      -    615M  -
  /dev/sda4  filesystem  xfs      -      -    8.4G  -
  /dev/sda1  partition   -        -      -    4.0M  /dev/sda
  /dev/sda2  partition   -        -      -    1.0G  /dev/sda
  /dev/sda3  partition   -        -      -    615M  /dev/sda
  /dev/sda4  partition   -        -      -    8.4G  /dev/sda
  /dev/sda   device      -        -      -    10G   -

The VM also boots OK.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On Tuesday, 17 October 2017 17:35:51 CET Richard W.M. Jones
wrote:
> The immediate issue is with Fedora/ppc64 and /ppc64le which currently
> use extended partitions, breaking the virt-builder ‘--size’ parameter,
> eg:
> 
>   $ virt-builder --arch ppc64le fedora-26 --size 20G
>   ...
>   [  21.6] Resizing (using virt-resize) to expand the disk to 20.0G
>   virt-resize: error: /dev/sda5: partition not found in the source disk
image
>   (this error came from '--expand' option on the command line). 
Try running
>   this command: virt-filesystems --partitions --long -a
/var/tmp/vbf67b8c.img
> 
> However more generally MBR is broken and should die.  GPT is supported
> by all modern virtual bootloaders, so just default to it.
> 
> Notes:
> 
> * This is different from mandating a UEFI bootloader.
> 
> * I am not planning to rebuild any existing images except the
>   F26 ppc64 & ppc64le ones.
> ---
The reasons above suggest me that we should switch all the distros (in the
libguestfs.org repository) to GPT, not just the ones in this patch.

-- 
Pino Toscano