install on root lvm volume in kvm-qemu VM: ubiquity crashed with InstallStepError in configure_bootloader()

[John Hall]

Binary package hint: ubiquity

Ubiquity was given a virtual machine with 2 drives -hda was an lvm volume (incidentally on a raid array but this should be invisible in the vm) and the second as -hdb a regular disk device (/dev/sdb). The first partition of the second device was defined as mounted to /boot. grub-install was executed on the first device (lvm volume) and fails ungracefully. As a result any installation steps following grub-install are not executed and must be done manually.

I may have missed an option or feature and may be able to simply pass the two disks in the other order for success. User errors are exceptional use cases. If recovery is possible then why not do so?

Ubiquity has at least 2 categories of problems installing in kvm qemu

1 Failing to recognize and use different types of data volumes (Disks)
2 ACPI problems ( not this bug and solved with noacpi)

1 Data volume / Disk problems such

If ubiquity handled disks in the virtual environment gracefully then it would be more useful. it is also very easy to test the installation on a virtual environment while doing other things. Virtual machine installation features could be triggered ***without being visible to ordinary users*** so it would be a total win with no usability losses for other use cases!
Many different things can be passed as disk parameters to be used by the VM. Individual partitions passed to the virtual environment are not recognized by ubiquity even with pre-existing files systems present. Even on a regular system one use case should be that the user has already set up desired partitions.
Many different things can be passed as disk parameters to be used by the VM. Individual partitions passed to the virtual environment are not recognized by ubiquity even with pre-existing files systems present.

A LVM volumes are accepted but if an lvm volume is the first volume (passed to kvm as -hda ) then grub-install fails and the installation is aborted.

B Single disk partitions ( id /dev/sda2) pasted to kvm-qemu are rejected for mapping to a mount point even if a file system exists. The whole disk must instead be mapped risking other parts of the device. Handling single partitions would allow the user to protect the partition table and other partitions that the installation should not be accessing! In this case a large partition of the drive is part of a raid configuration.

2 The ACPI problem could be fixed by adding a special environments detection step in the boot script of the CD. If there is not a more direct way the machine configuration of virtual devices is an easy signature to detect! Nearly no other system would have an old ensoniq audio card, a generic video interface and an old lan card! This could also trigger checks and points for disk / data volume issue described in this bug. Alternatively a boot flags could be added that lead the user. You have to know the problem is ACPI. Another option could be added to the F6 menu "KVM" that would not require this knowledge.

** * * Failure Recovery * * ** pa rum pa pum pum
Failure recovery does not complicate the experience of other users. Druids triggered by exceptions to assists the user automatically will reduce resources needed to support the installation process and make the installation useful even in unforeseen circumstances.
To test this idea options could be added as boot flags
An option at the begining to allow recovery from a problem
An option to allow partial installations then at the end steps suceeded and what is left to be completed manually to repair missed steps.

For example in this case Ubiquity could display a dialog along theses lines "Grub-install failed on disk 1. Should grub-install be attempted for another partition or drive?
( present list of drives to use)
Display further information about the selected drive. (this selection would show partition tables, labels, suspected type.fs uuid)
Install grub to boot sector of the selected drive.
Skip this step
abandon this installation attempt."

ProblemType: Crash
Architecture: amd64
Date: Sat Jan 2 17:31:26 2010
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InterpreterPath: /usr/bin/python2.6
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
Package: ubiquity 2.0.6
ProcCmdline: /usr/bin/python /usr/lib/ubiquity/bin/ubiquity --only
ProcEnviron:
 LANGUAGE=
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
PythonArgs: ['/usr/lib/ubiquity/bin/ubiquity', '--only']
SourcePackage: ubiquity
Title: ubiquity crashed with InstallStepError in configure_bootloader()
Uname: Linux 2.6.31-14-generic x86_64
UserGroups:

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Phillip Susi (psusi)]

9.10 reached end of life some time ago and is no longer supported. Are you able to reproduce this problem on 14.04 or 14.10?

[John Hall (johnlhall)]

Functionality related to the bug has improved overall.
I am no longer effected and I do not think carrying over this information from 9.10 would really help if the problem still exists.
If others are still effected then I am willing to research the related issues on the forums and see if it's still a problem and if so reproduce it. Otherwise you can just close it.