[Bug 1971061] Re: Ubuquity crash during attempted insall to SSD partition

[Paul White]

Thank you for taking the time to report this bug and helping to make
Ubuntu better. We are sorry that we do not always have the capacity to
review all reported bugs in a timely manner.

Ubiquity is now unmaintained as it has been replaced by either the
Ubuntu Desktop Installer or Calamares starting with Ubuntu 24.04 LTS.
Therefore, this bug is being closed as 'Invalid'.

If you believe this was done in error, please feel free to re-open the
bug report.

If you have any general questions about Ubuntu, please open a topic on
the Ubuntu Discourse instance: https://discourse.ubuntu.com/.


** Changed in: ubiquity (Ubuntu)
       Status: New => Invalid

-- 
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/1971061

Title:
  Ubuquity crash during attempted insall to SSD partition

Status in ubiquity package in Ubuntu:
  Invalid

Bug description:
  
  I've got a machine which incorporates and SSD, and an electromechanical drive. Grub was removed by 'boot-repair' when I used a while ago. And, it has become apparent that the Debian based software has not been updated to deal with desktop machines where such configurations have come to be. The current attempt to repatriate an in use post v19 Ubuntu (via sda) to a specified partition on the currently non-functional SSD, thus having Grub installed to another specified partition, ended with a Ubiquity crash whose message reads: "Installer crashed\n We're sorry; the installer crashed. After you close this window, we'll allow you file a bug report using the integrated bug reporting tool. This will gather info about your system and your system and your install process. The details will be sent to our bug tracker and a developer will attend to the problem as soon as possible". I captured the information in the report window which became available after the collection process, as well.

  Moreover, I have already articulated the problem (https://askubuntu.com/questions/1401563/configuring-multiboot-for-2-native-drive-computers: 'Configuring Multiboot for 2 Native Drive Computers') which I've been trying to overcome ever since 'boot-repair' wiped the data from the '/boot' directories on the SSD partions upon which I had working Ubuntu, and a Mint installs. And, then removed Grub, and the data in the EFI directory resident within another drive partition. And, so far, I haven't been able fix this with either usb flash drive install devices via Mint 20.3, or Ubuntu 20.03, or v22.05' via GUI install attempts, or manually via cmdln, either!
  Additionally, it is not presently possible to mount other external device, given the present 'chroot state', either!

  There does not appear a way to attach files to bug reports via
  'https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug/31470f98-c8ce-11ec-a1ce-d485646cd9a4'.
  And, these are too massive to include via copy/paste. I can forward
  them to you, if you provide a destination, to do so.

  
  An articulated 'Boot Info  Summary' that details the setup of this machine used to be able to be found at pastebin.ubuntu.com/p/DVtK9TvvVx. 

  After reception of the device, I was unaware of the tenets of UEFI. I
  established multi-boot configuration originally using the old MBR
  manner approach, in conjunction of a 'no longer supported' package
  name 'multiboot'. And, that approach became non-viable as of v20.04,
  as I had major problems at one point with library dependencies, and
  new install attempts on 'sda' in order to remove 'multiboot'
  involvement; until I ultimately found a solution involving the removal
  of ancient libraries, and was able to restore functional utility via
  'sda', and grub. But, please notice that the install that I am working
  from, (ie /) is via /dev/sda7. And, there are not any clauses in
  /boot/grub/grub.cfg! And, I have not been able to find the actual
  grub.cfg that grub is using during the boot process, at this point,
  as well!? Hopefully, I (and others, I expect) hope to gain instruction
  on a working manner to clear this hurdle, without wiping it's present
  content; other than that of the Ux partitions in existence. The SSD is
  presently not able to used as a boot device. There exist the original
  Windoze 10 parttiions, containing the associated content. And, I am
  trying to keep them there.

  Slainte,
  odoncaoa at yahoo.com

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: ubiquity 20.04.15.19
  ProcVersionSignature: Ubuntu 5.4.0-109.123-generic 5.4.178
  Uname: Linux 5.4.0-109-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.23
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sat Apr 30 17:37:17 2022
  InstallCmdLine: BOOT_IMAGE=(loop)/casper/vmlinuz boot=casper iso-scan/filename=/ubuntu-19.10-desktop-amd64.iso splash --
  InstallationDate: Installed on 2020-02-20 (799 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
   LC_NUMERIC=C.UTF-8
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1971061/+subscriptions