install failed crashed with CalledProcessError

Bug #1861369 reported by Seth Arnold
60
This bug affects 13 people
Affects Status Importance Assigned to Milestone
The Ubuntu-power-systems project
Fix Released
High
Canonical Foundations Team
subiquity
Fix Released
Undecided
Unassigned
curtin (Ubuntu)
Invalid
Critical
Unassigned

Bug Description

This failed during a power9 install. Of the 29 *.crash files generated during this installation, I filed two other bug reports: bug 1861367 and bug 1861368 . Either of those other bugs may be the 'real' bug.

I selected these three to file due to the filenames:

One of the various *.*.block_probe_fail.crash files
One of the various *.*.disk_probe_fail.crash files
The only *.*.install_fail.crash file

I could file all the bugs if it would be helpful but it seemed unlikely to be useful to me.

This machine has a single nvme drive; the grub install failed because it was trying to write to a non-existant drive:

grub-install: error: cannot find a GRUB drive for /dev/nvme0n11. Check your device.map.

A related error (but not necessarily this exact run of the installer) is in the error tracker:
https://errors.ubuntu.com/oops/7a0ee974-419b-11ea-a7da-fa163ee63de6

Thanks

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: subiquity (not installed)
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-9-generic ppc64le
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu16
Architecture: ppc64el
CasperVersion: 1.438
CrashDB: {'impl': 'launchpad', 'project': 'subiquity'}
Date: Wed Jan 29 07:55:12 2020
ExecutablePath: /snap/subiquity/1435/usr/bin/subiquity
InterpreterPath: /snap/subiquity/1435/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha ppc64el (20200123)
ProcAttrCurrent: snap.subiquity.subiquity-service (complain)
ProcCmdline: /snap/subiquity/1435/usr/bin/python3 /snap/subiquity/1435/usr/bin/subiquity
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
ProcKernelCmdLine: quiet ---
Python3Details: /usr/bin/python3.7, Python 3.7.6, python3-minimal, 3.7.5-1ubuntu1
PythonDetails: N/A
SnapChannel: stable/ubuntu-20.04
SnapRevision: 1435
SnapUpdated: True
SnapVersion: 19.12.2+git45.ac40a375
SourcePackage: subiquity
Title: install failed crashed with CalledProcessError
UpgradeStatus: Upgraded to focal on 2020-01-24 (5 days ago)
UsingAnswers: False

Revision history for this message
Seth Arnold (seth-arnold) wrote :
tags: added: champagne
information type: Private → Public
Revision history for this message
Seth Arnold (seth-arnold) wrote :
Download full text (4.6 KiB)

These lines stand out to me:

https://github.com/CanonicalLtd/subiquity/blob/436ee1d76ddad5362c25843f429b4346324c0b8f/subiquity/models/filesystem.py#L1368

    def render(self):
        config = {
            'storage': {
                'version': 1,
                'config': self._render_actions(),
                },
            }
        if not self._should_add_swapfile():
            config['swap'] = {'size': 0}
        if self.grub_install_device:
            dev = self.grub_install_device
            if dev.type == "partition":
                devpath = "{}{}".format(dev.device.path, dev._number)
            else:
                devpath = dev.path
            config['grub'] = {
                'install_devices': [devpath],
                }
        return config

https://github.com/CanonicalLtd/subiquity/blob/436ee1d76ddad5362c25843f429b4346324c0b8f/subiquity/controllers/filesystem.py#L390

    def _create_boot_partition(self, disk):
        bootloader = self.model.bootloader
        if bootloader == Bootloader.UEFI:
            part_size = UEFI_GRUB_SIZE_BYTES
            if UEFI_GRUB_SIZE_BYTES*2 >= disk.size:
                part_size = disk.size // 2
            log.debug('_create_boot_partition - adding EFI partition')
            part = self.create_partition(
                disk,
                dict(size=part_size, fstype='fat32', mount='/boot/efi'),
                flag="boot")
        elif bootloader == Bootloader.PREP:
            log.debug('_create_boot_partition - adding PReP partition')
            part = self.create_partition(
                disk,
                dict(size=PREP_GRUB_SIZE_BYTES, fstype=None, mount=None),
                # must be wiped or grub-install will fail
                wipe='zero',
                flag='prep')
            self.model.grub_install_device = part
        elif bootloader == Bootloader.BIOS:
            log.debug('_create_boot_partition - adding bios_grub partition')
            part = self.create_partition(
                disk,
                dict(size=BIOS_GRUB_SIZE_BYTES, fstype=None, mount=None),
                flag='bios_grub')
            self.model.grub_install_device = disk
        return part

https://github.com/CanonicalLtd/subiquity/blob/436ee1d76ddad5362c25843f429b4346324c0b8f/subiquity/controllers/filesystem.py#L613

    def make_boot_disk(self, new_boot_disk):
        boot_partition = None
        if self.model.bootloader == Bootloader.BIOS:
            install_dev = self.model.grub_install_device
            if install_dev:
                boot_partition = install_dev._potential_boot_partition()
        elif self.model.bootloader == Bootloader.UEFI:
            mount = self.model._mount_for_path("/boot/efi")
            if mount is not None:
                boot_partition = mount.device.volume
        elif self.model.bootloader == Bootloader.PREP:
            boot_partition = self.model.grub_install_device
        if boot_partition is not None:
            if boot_partition.preserve:
                if self.model.bootloader == Bootloader.PREP:
                    boot_partition.wipe = None
                elif self.model.bootloader == Bootloader.UEFI:
              ...

Read more...

Revision history for this message
Seth Arnold (seth-arnold) wrote :

I think if my installer could go through the other branch of this if condition I'd probably have success:

            if dev.type == "partition":
                devpath = "{}{}".format(dev.device.path, dev._number)
            else:
                devpath = dev.path

Thanks

Revision history for this message
Frank Heimes (fheimes) wrote :

Iirc the latest subiquity release (20.03) incl. fixes for such kind of block prob issues.
Would you mind giving the latest ISO a try so that we know if this particular issue is still valid?
Nevertheless, there is another issue open about NVMe devices that is probably not fixed yet: LP 1861655 - but let's go steps by step ...

Changed in ubuntu-power-systems:
importance: Undecided → High
assignee: nobody → Canonical Foundations Team (canonical-foundations)
tags: added: installer
Frank Heimes (fheimes)
Changed in ubuntu-power-systems:
status: New → Incomplete
Changed in subiquity:
status: New → Incomplete
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Frank, I can't recall where exactly this failed any more, but at least now my install is failing in a different fashion:

https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1872783

Thanks

Revision history for this message
Frank Heimes (fheimes) wrote :

Closing project entry and setting it to Fix Released with todays ISO (Apr 14th).

Changed in ubuntu-power-systems:
status: Incomplete → Fix Released
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

   - {device: disk-nvme0n1, size: 8388608, wipe: zero, flag: prep, number: 1, preserve: false,
     type: partition, id: partition-0}

seems to result in curtin doing

Command: ['sh', '-c', 'exec "$0" "$@" 2>&1', 'install-grub', '--os-family=debian', '/target', '/dev/nvme0n11']

which is incorrect, because `device: disk-nvme0n1` `number: 1` is clearly /dev/nvme0n1p1, not /dev/nvme0n11

Changed in curtin (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Frank, I'm sorry to say that bug 1872783 'masked' this bug for me. I couldn't reproduce 1872783 to get logs, but at the same time, found that this one is still happening.

Thanks

tags: removed: need-duplicate-check
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Two .crash files, one trying to configure LVM, one not trying to configure LVM.

Frank Heimes (fheimes)
Changed in ubuntu-power-systems:
status: Fix Released → Triaged
Revision history for this message
Frank Heimes (fheimes) wrote :

[CanonicalLtd/subiquity] use curtin.block.partition_kname to calculate partition devpath (#706)
https://github.com/CanonicalLtd/subiquity/pull/706

Revision history for this message
Seth Arnold (seth-arnold) wrote :
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Thanks for testing, at least this was easy in the end.

Changed in subiquity:
status: Incomplete → Fix Committed
Changed in curtin (Ubuntu):
status: Triaged → Invalid
Frank Heimes (fheimes)
Changed in ubuntu-power-systems:
status: Triaged → Fix Committed
Revision history for this message
Frank Heimes (fheimes) wrote :

Seth, did I interpret it correctly that you were not able to reproduce the issue with the latest ISO/installer and that it got fixed in between?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Frank, Michael made available a private build of the installer in a separate snap channel, and it worked perfectly.

I don't know if this has made it into the 'release' channel of the installer snap, but it's very promising.

Thanks

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Yes, that fix landed. That said I'm just about to release another version which does this a different way -- testing the next image on ppc64el would be very useful!

Changed in subiquity:
status: Fix Committed → Fix Released
Changed in ubuntu-power-systems:
status: Fix Committed → Fix Released
Revision history for this message
Frank Heimes (fheimes) wrote :

This is included in the GA version of 20.04 (released last Thursday), hence closing this ticket as Fix Released.

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

Other bug subscribers

Remote bug watches

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