failed creating GPT entries on raid device

Bug #1783374 reported by Joshua Powers
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
subiquity
Fix Released
Critical
Unassigned

Bug Description

Summary:
Install fails when setting up RAID 6 device

Expected Behavior:
Install completes successfully

Actual Behavior:
        Stdout: Creating new GPT entries.

        Stderr: Could not create partition 1 from 2048 to 62859263
                Could not change partition 1's type code to 8300!
                Error encountered; not saving changes.

Steps to Reproduce:
1. Use Bionic live-server dated 20180724
2. Launch an instance with 6 virtio disks in addition to the boot device.
3. Create a RAID 6 software raid with the virtio disks
4. Mark the boot device bootable
5. Create / partition on boot device
6. Create /home partition on software raid device
7. Start install and get Unexpected error while running sgdisk command on /dev/md0

Logs:
Curtin Log: https://paste.ubuntu.com/p/yXyXNQFJtk/
Subiquity Debug Log: https://paste.ubuntu.com/p/YwbwRDYv5z/
Subiquity Curtin Install Log: https://paste.ubuntu.com/p/cgpZzd8zmZ/

Tags: iso-testing
Revision history for this message
Joshua Powers (powersj) wrote :
Revision history for this message
Joshua Powers (powersj) wrote :

Similar error occurred with:

5 disk RAID5 array mounted at /raid5 with xfs
4 disk RAID5 array mounted at /home with ext4

The following worked:

3 disk RAID5 array mounted at /raid5 with xfs
3 disk RAID5 array mounted at /home with ext4

Is the number of disks causing issues?

Revision history for this message
Ryan Harper (raharper) wrote :

I believe the error here is the size calculation of the first partition on the raid device.
Curtin always aligns the first partition on a 1MB boundary, so that needs to be accounted for in the suggested MAX_SIZE of the partition.

If you try again with a 1MB smaller partition does it work?

Changed in subiquity:
status: New → Incomplete
Revision history for this message
Joshua Powers (powersj) wrote :

> If you try again with a 1MB smaller partition does it work?

Yes it does. I entered in a larger size, like 40Gb, subiquity changed it to 39.372 and I then changed that to 39.371 and it worked. (These are not exact values)

Changed in subiquity:
status: Incomplete → New
Revision history for this message
Ryan Harper (raharper) wrote :

Can you peek into the subiquity-storage-config yaml and see what the 'size' value of the first partition in raid-0 is?

In your original scenario,

- {id: part-2, type: partition, device: raid-0, size: 32182894592, flag: '', preserve: false}

The max size in Gigabytes is:

32182894592 / (1024 * 1024 * 1024)
29.97265625

One MB smaller

32182894592 - (1 * 1024 * 1024)
32181846016

# convert to gigabytes
32181846016.0 / (1024 * 1024 * 1024)
29.9716796875

29.972Gb
vs
29.971Gb (one MB smaller)

Revision history for this message
Joshua Powers (powersj) wrote :

In the UI it says (max 29.972G), I change the suggested max value from that, 29.972, to 29.971G.

In the /var/log/installer/subiquity-curtin-install.conf size is now set to 32181846016:
http://paste.ubuntu.com/p/SW9ZHTYw3k/

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1783374

tags: added: iso-testing
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote : Re: [Bug 1783374] Re: failed creating GPT entries on raid device

I ran into the same error and made the "free for partitions" calculation
even more pessimistic yesterday. It's not curtin's 1MB alignment BTW,
subiquity rounds partition sizes to megabytes anyway.

On Wed, 25 Jul 2018, 08:22 Joshua Powers, <email address hidden> wrote:

> In the UI it says (max 29.972G), I change the suggested max value from
> that, 29.972, to 29.971G.
>
> In the /var/log/installer/subiquity-curtin-install.conf size is now set to
> 32181846016:
> http://paste.ubuntu.com/p/SW9ZHTYw3k/
>
> --
> You received this bug notification because you are subscribed to
> subiquity.
> https://bugs.launchpad.net/bugs/1783374
>
> Title:
> failed creating GPT entries on raid device
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/1783374/+subscriptions
>

Changed in subiquity:
importance: Undecided → Critical
status: New → Fix Committed
Revision history for this message
Joshua Powers (powersj) wrote :

Running subiquity 0+git.952787e this still occurs

1. Download Bionic live-server ISO from July 25, 2018 (20180725) md5sum: ec66672828f2cf7a7f42aa1842964cdf
2. Launch VM with 1 boot disk and 5 additional virtio 10Gb disks
3. Create boot volume on the boot disk mounted as / with ext4
4. Create a raid6 md0 with the 5 virtio disks
5. Create a partition on the md0 device and use the max space available as /home with ext4
6. Start the install and observe the curtin failure during "Creating new GPT entries."

Joshua Powers (powersj)
Changed in subiquity:
status: Fix Committed → Confirmed
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Well great.

Changed in subiquity:
status: Confirmed → Fix Released
Revision history for this message
Patrik Wenger (paddor) wrote :

This bug seems to persist in Ubuntu 18.04.2 live server amd64.

I have 2 SSDs of 32GB each and am trying to create a SW-RAID 1 (mirrored) for the root partition. (This is not for increased availability, but for securing production data in case of an SSD failure.) The mountpoints /boot/efi and /boot are on separate partitions on the first SSD (2 * 512MB). To end up with a symmetric partition table, I created two unformatted partitions of equal size on the second SSD.

This command fails: `sgdisk --new 1:2048:60407807 --typecode=1:8300 /dev/md0`

```
Stdout: Creating new GPT entries.

Stderr: Could not create partition 1 from 2048 to 60407807
        Could not change partition 1's type code to 8300!
        Error encountered; not saving changes.
```

Revision history for this message
Patrik Wenger (paddor) wrote :

The same bug appears if I don't create the two placeholder partitions on the second SSD.

It went through when I put / on a bare partition and put /var and /opt on partitions in the RAID volume.

When I tried again with / on a bare partition and /home, /usr, /var, and /opt on partitions in the RAID, it failed again.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.