Sorry for the vague title - but there's no clear error messages coming back from Ubiquity, and I'm stumped, hopefully a human can better parse this than my attempts at searching the web:

- Trying to install Ubuntu 20.04.2 LTS on a machine that was previously running Xubuntu with no issues.
- Installer consistently fails and crashes (hardlock system or 'unexpected error now exiting' with no error code, log entries, etc) after setting partition options (with/without encryption makes no difference but selecting encryption creates 'unexpected error with encryption').

I've tried swapping disks, tried setting SATA to IDE and AHCI in the UEFI, tried swapping RAM, created clean install image from fresh download, erasing disks (via wipefs and cfdisk), disabling/enabling IOMMU in BIOS, manually creating partitions, etc consistently it still always fails with no real explanation (but at least its always at the same point).

It will live boot with no problems, will run programs, mount the disks, do whatever, it just consistently fails with no explanation when attempting to actually install. I've never encountered this in 3+ years of working with Ubuntu, and it's got me stumped. Searching online for this non-error message of course returns nothing (or inchoate results).

In the installer itself I'm always un-checking 'install updates' and 'install third party' and going for 'minimal install' as well, FWIW (and I've never seen this be an issue before, either with this machine or others).

Any help would be appreciated - like I said I can boot into a live environment just fine, so I can 'do things' with the system, I'm just not sure what else to try or do to move this along.

Did you check the download, after burning? https://askubuntu.com/questions/1315...ial-ubuntu-iso
https://releases.ubuntu.com/20.04.2.0/

Yes. I've also since tried 21.04 and Xubuntu 20.04 and it consistently trips at the same point. I'm suspecting an issue with Ubiquity at this point, or some interaction between Ubiqiuty and the system. I can boot into a live environment and mount, format, and read/write to (either) disk without any trouble, but the installer keeps hitching when faced with the same task.

Some more information:
I figured I'd try to play my hunch, and grabbed the Oracle EL installer (which uses Anaconda) and gave it shot - it got much further (and spit out some useful errors when it failed) - it seems the issue is that the underlying disk has a partition table/LVM on it that isn't being properly erased, and so the installer only sees around 400MB of free space. I tried the 'reclaim space' option in Anaconda but it still ended up erroring out (out of space) once it started trying to commit writes and then threw an 'unable to unlock disk'. Any ideas on how to more fully 'nuke' this disk? It previously had Ubuntu installed on it in an encrypted (LUKS) LVM, but I've never had issues with over-writing such a thing in the past...

Things I've tried:
- wipefs -a against it (completes with no errors)
- using dd to write ~8GB of /dev/zero to the front (?) of the disk
- reformatting it in cfdisk and writing data (also /dev/zero) to the partition and then formatting over that again

If looked at in lsblk the drive looks 'empty' - it has no partitions, no mounts, no lvm, etc. When cfdisk runs it asks to initialize, etc. So what's going on?

Update 2:
I found this guide (https://grok.lsu.edu/Article.aspx?articleid=16716) on erasing SSDs, which I tried against one of the two drives, and Ubiquity still hardlocks when attempting to setup the partition table (exactly as above). At this point I think I'm just going to write this machine off as impossible to use for unknown reasons and try the disks in another system to verify their state. Sharing the guide here because the process was pretty quick, and as the author points out, SSDs may not arrange data in a predictable way so relying on conventional 'erase' methods may not be comprehensive (and this is a lot faster than writing zeros to the entire drive).

So the issue persists?
Have you tried another installer (say, Debian's) on that particular setup? Does it fully succeed?
Have you tried actually completely wiping the disk from one end to the other?

I solved similar issues (long since past now) by nuking/preparing the disk with dd/(g)parted etc. in a live environment before starting the installer.

I don't use LVM but if the problem is with the partition table, you might try creating a new partition table with GParted or a similar tool. This, of course will wipe any data from the drive.

Didn't see there were more replies to this thread until yancek's reply -

Yes the issue persists - I actually ended up trying a complete erasure of one of the test drives (both were SSDs, one supported 'Enhanced Secure Erase' which 0'd it out apparently (see the link in my 'Update 2' - I followed their direction to dd out the first few MB of the drive and after 'enhanced secure erase' runs it just outputs nothing), and it still persists. I tried Oracle Linux (Anaconda instead of Ubiquity) and it insists the drive is out of space (I figured Anaconda would have more verbose output than Ubiquity is why I tried this, and it indeed does), and that's with or without LVM options. I then took that drive and hooked it up to a different motherboard/system and used the same Ubuntu install media I've been trying, and it went no problems - so I think there's something 'wrong' with the motherboard or (???) that's getting in the way here (but what makes no sense is this system had Xubuntu 20.04 installed and working on it). FWIW the 'trouble system' has an AMD970 chipset and FX CPU, and the 'working system' has an Intel H97 chipset and Core i5 CPU. I've made no further progress on this however, but again thanks to folks for suggesting ideas - this is easily one of the oddest things I've encountered with a computer in a while. I will probably try a third drive to confirm the original disk isn't somehow at fault, but otherwise I'm not sure what else to attempt to get this system back to work. And for the record it doesn't appear to have stability issues: I can boot it into the Ubuntu live environment and run CPU intensive tests on it and everything runs just fine, it only has issues trying to actually install to disk.

1 members found this post helpful.

Have you also tried to erase the disk completely, i.e. dd it with zeros from the first block to the last?
I seem to remember such caes where the first few MB weren't enough.

In any case it's weird that the same disk would work OK in another machine. Maybe it isn't (only) the installer that is confused, but some feature of the motherboard that sees the disk as something it isn't?

On one disk I used the 'enhanced erase' which did seem to 0 out all blocks with data, on the other one I wrote around 20GB of zeroes to the 'beginning' (which is more than enough for another machine to see it as 'blank') and indeed the installer saw it as blank, but the second you hit 'go' it still errors out as above.

This is what I'm wondering too, but I can't come with any way to test this - I've tried setting the UEFI to 'SATA' and 'AHCI' and changing IOMMU/VT settings (this is *not* running in a VM, but I've seen those settings impact disk controllers in the past), and none has improved the situation.