subiquity

subiquity crashes upon reusing existing full-disk raid member

Bug #1835087 reported by Dimitri John Ledkov on 2019-07-02

This bug affects 13 people

Affects		Status	Importance	Assigned to	Milestone
	curtin	Fix Released	Undecided	Unassigned
	subiquity	Fix Released	Undecided	Unassigned

Bug Description

subiquity crashes upon reusing existing disks

https://paste.ubuntu.com/p/qHwVY4gdrf/

get_blockdev_sector_size: (log=512, phys=512)
An error occured handling 'disk-vdb': ValueError - disk 'disk-vdb' does not have correct partition table or cannot be read, but preserve is set to true. cannot continue installation.
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: configuring disk: disk-vdb
TIMED BLOCK_META: 1.592
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: curtin command block-meta
Traceback (most recent call last):
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/commands/main.py", line 202, in main
    ret = args.func(args)
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/log.py", line 97, in wrapper
    return log_time("TIMED %s: " % msg, func, *args, **kwargs)
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/log.py", line 79, in log_time
    return func(*args, **kwargs)
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/commands/block_meta.py", line 86, in block_meta
    return meta_custom(args)
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/commands/block_meta.py", line 1677, in meta_custom
    handler(command, storage_config_dict)
  File "/snap/subiquity/1048/lib/python3.6/site-packages/curtin/commands/block_meta.py", line 546, in disk_handler
    "cannot continue installation." % info.get('id'))
ValueError: disk 'disk-vdb' does not have correct partition table or cannot be read, but preserve is set to true. cannot continue installation.
disk 'disk-vdb' does not have correct partition table or cannot be read, but preserve is set to true. cannot continue installation.

My layout is:
vda - grub partition, /boot partition, raid0 member
vdb - whole disk raid0 member

It is correct that vdb does not have a partition table. But equally we don't need to create or touch things on vdb either.

Tags:

Related branches

~mwhudson/curtin:lp-1835087

Merged into curtin:master

Ryan Harper (community): Approve on 2019-07-09

Server Team CI bot: Approve (continuous-integration) on 2019-07-09

Dan Watkins (community): Approve on 2019-07-08

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2019-07-02:

installer.tar.gz Edit (11.0 KiB, application/x-tar)

Dimitri John Ledkov (xnox) on 2019-07-02

summary:	- subiquity crashes upon reusing existing disks + subiquity crashes upon reusing existing full-disk raid member
tags:	added: reuse

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-02:

Yes; we can relax that restriction I suppose.

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-02:

Actually, if you don't plan on having a partition on the target disk, then don't include it in the disk config, no?

storage:
  config:
  - ptable: gpt
    path: /dev/vda
    preserve: true
    name: ''
    grub_device: false
    type: disk
    id: disk-vda
  - ptable: gpt
    path: /dev/vdb
    preserve: true
    name: ''
    grub_device: false
    type: disk
    id: disk-vdb

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-02:

I'm marking as invalid since you indicated that the disk *should* have a gpt partition and curtin rightly said that you told it to preserve vdb with a gpt table but no such table existed.

Changed in curtin:
status:	New → Invalid

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-02:

I think discover should have indicated that the device did *not* have a partition table; so maybe subiquity's default of gpt ptable value should be tempered by whether the target device had one or not?

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2019-07-02:

Thank you ryan!

Revision history for this message

Michael Hudson-Doyle (mwhudson) wrote on 2019-07-08:

One of the changes made in the reusing existing partitions work is that disks are now always included in the config, but have preserve: true set when there are no changes being made to this disk. Possibly this was a mistake.

*That said*, in this case I think the problem is in curtin. The probe data for vdb has no ID_PART_TABLE keys but curtin does this:

# default to gpt if not present
entry['ptable'] = blockdev_data.get('ID_PART_TABLE_TYPE', 'gpt')

This seems wrong.

Michael Hudson-Doyle (mwhudson) on 2019-07-08

Changed in curtin:
status:	Invalid → New

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-08:

I'm in agreement on the curtin fix there; however, I do think it wise in subiquity to make sure that it's not setting ptable when it wasn't if preserve is set to true.

A quick look shows that the 'add_partition()' method will set a disk.ptable attribute to 'gpt'. I've not walked through all of the flows to be certain that it won't get set.

Changed in curtin:
status:	New → In Progress

Revision history for this message

Ryan Harper (raharper) wrote on 2019-07-17: Fixed in curtin version 19.2.

This bug is believed to be fixed in curtin in version 19.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in curtin:
status:	In Progress → Fix Released

Revision history for this message

Michael Hudson-Doyle (mwhudson) wrote on 2019-07-17:

#10

I fixed subiquity to wipe disks harder, which might well have fixed this. Will check today.

Revision history for this message

Michael Hudson-Doyle (mwhudson) wrote on 2019-07-17:

#11

I tested this scenario with the latest stable subiquity and it worked (not sure if it was curtin fix or subiquity fix that mattered, don't really care either way)