[Bug 502563] Re: install on root lvm volume in kvm-qemu VM: ubiquity crashed with InstallStepError in configure_bootloader()
Brian Murray
brian at ubuntu.com
Fri Jul 29 21:53:04 UTC 2011
** Tags added: ubiquity-2.0.6
** Tags added: karmic
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/502563
Title:
install on root lvm volume in kvm-qemu VM: ubiquity crashed with
InstallStepError in configure_bootloader()
Status in “ubiquity” package in Ubuntu:
New
Bug description:
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:
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/502563/+subscriptions
More information about the foundations-bugs
mailing list