[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