coreos-install: backup gpt table is not at the end of the disk && partitions?

[Hans Donner]

I followed https://coreos.com/docs/running-coreos/bare-metal/booting-with-pxe/ to PXE boot coreos, followed by ssh into the box.

after installing I get

- Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.

When looking at the partition info with parted, I get an additional:

- Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space

I notice two partitions with ROOT-B, having different sizes (1 equal to ROOT-A)

 3      135MB   1209MB  1074MB  ext2         ROOT-A

 2      1209MB  1276MB  67.1MB               BOOT-B

 4      1276MB  2350MB  1074MB               ROOT-B

Is that correct?

Below I've included the full output.

Hans

PS: for a future release: make smaller images to boot with pxe and fetch remainder via faster method.

$ sudo coreos-install -d /dev/sda

Downloading and verifying coreos_production_image.bin.bz2...

gpg: Signature made Tue Jan 14 07:23:12 2014 UTC using RSA key ID 74E7E361

gpg: key 93D2DCB4 marked as ultimately trusted

gpg: checking the trustdb

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u

gpg: Good signature from "CoreOS Buildbot (Offical Builds) <buil...@coreos.com>"

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  136M  100  136M    0     0   9.9M      0  0:00:13  0:00:13 --:--:-- 10.4M

coreos_production_image.bin.bz2: OK

coreos_production_image.bin.bz2: OK

Writing coreos_production_image.bin.bz2 to /dev/sda...

Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by mo

ving the backup to the end (and removing the old backup)?

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 482378914 blocks) or continue with the

 current setting?

Success! CoreOS 197.0.0 is installed on /dev/sda

$ sudo parted -a optimal /dev/sda

GNU Parted 3.1

Using /dev/sda

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) print

Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by

moving the backup to the end (and removing the old backup)?

Fix/Ignore/Cancel? ignore

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 482378914 blocks) or continue with the

current setting?

Fix/Ignore? ignore

Model: ATA ST3250318AS (scsi)

Disk /dev/sda: 250GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number  Start   End     Size    File system  Name        Flags

 1      1049kB  135MB   134MB   fat16        EFI-SYSTEM  boot

 3      135MB   1209MB  1074MB  ext2         ROOT-A

 2      1209MB  1276MB  67.1MB               BOOT-B

 4      1276MB  2350MB  1074MB               ROOT-B

 6      2350MB  2484MB  134MB   ext4         OEM

 9      2484MB  3021MB  537MB   ext4         STATE

[Michael Marineau]

On Sat, Feb 8, 2014 at 10:08 AM, Hans Donner <ha...@hansdonner.nl> wrote:
> I followed
> https://coreos.com/docs/running-coreos/bare-metal/booting-with-pxe/ to PXE
> boot coreos, followed by ssh into the box.
>
> after installing I get
> - Error: The backup GPT table is not at the end of the disk, as it should
> be. This might mean that another operating system believes the disk is
> smaller.
>
> When looking at the partition info with parted, I get an additional:
> - Not all of the space available to /dev/sda appears to be used, you can fix
> the GPT to use all of the space

This is intentional, the install script doesn't bother with resizing
because that is built into the CoreOS boot process itself. On first
boot the GPT will be repaired and the STATE partition will be expanded
to fill the full disk. (unless a bug prevents that from working right
of course...) It used to be that the resize would only happen if the
secondary GPT was invalid so just inspecting the disk with parted
would prevent the auto-resize from kicking in. Recently that was
changed to trigger a resize if there is more than 2MB of unallocated
space so that won't be an issue any more.

>
> I notice two partitions with ROOT-B, having different sizes (1 equal to
> ROOT-A)
> 3 135MB 1209MB 1074MB ext2 ROOT-A
> 2 1209MB 1276MB 67.1MB BOOT-B
> 4 1276MB 2350MB 1074MB ROOT-B
> Is that correct?

Yes, because the small one is BOOT-B (not ROOT-B) but it is actually
unused right now.

> Below I've included the full output.
>
> Hans
>
> PS: for a future release: make smaller images to boot with pxe and fetch
> remainder via faster method.

Yeah... PXE/tftp implementations probably tend to not be written with
performance above a slow crawl (or reliability!) in mind but that also
adds complexity by requiring us to bring networking up in the initrd.
Perhaps worth a look once we start using systemd-networkd.

[Hans Donner]

On Saturday, February 8, 2014 9:47:16 PM UTC+1, Michael Marineau wrote:

On Sat, Feb 8, 2014 at 10:08 AM, Hans Donner <ha...@hansdonner.nl> wrote:
> after installing I get
> - Error: The backup GPT table is not at the end of the disk, as it should
> be.  This might mean that another operating system believes the disk is
> smaller.
>
> When looking at the partition info with parted, I get an additional:
> - Not all of the space available to /dev/sda appears to be used, you can fix
> the GPT to use all of the space

This is intentional, the install script doesn't bother with resizing
because that is built into the CoreOS boot process itself. On first
boot the GPT will be repaired and the STATE partition will be expanded
to fill the full disk. (unless a bug prevents that from working right
of course...) It used to be that the resize would only happen if the
secondary GPT was invalid so just inspecting the disk with parted
would prevent the auto-resize from kicking in. Recently that was
changed to trigger a resize if there is more than 2MB of unallocated
space so that won't be an issue any more.

Otherwise some explanation in the install script should be added that the warning should be expected...

 

>
> I notice two partitions with ROOT-B, having different sizes (1 equal to
> ROOT-A)
>  3      135MB   1209MB  1074MB  ext2         ROOT-A
>  2      1209MB  1276MB  67.1MB               BOOT-B
>  4      1276MB  2350MB  1074MB               ROOT-B
> Is that correct?

Yes, because the small one is BOOT-B (not ROOT-B) but it is actually
unused right now.

Ahh. The bonus of a small screen :-) 

> PS: for a future release: make smaller images to boot with pxe and fetch
> remainder via faster method.

Yeah... PXE/tftp implementations probably tend to not be written with
performance above a slow crawl (or reliability!) in mind but that also
adds complexity by requiring us to bring networking up in the initrd.
Perhaps worth a look once we start using systemd-networkd.

Once the functionality of coreos is more or less finished, this might be nice target.