1

I'm unable to install on a couple of identical desktop PCs. They have identical specs, and both fail in similar ways so I believe its unlikely to be hardware failure. I've tried 19.04 and 18.04.2 LTS.

The installer fails from both Live USB boot and then install and from direct install from GRUB.

It fails due to random parts crashing at any point during the installer - the timezone picker crashes, the part which is making partitions fails, it fails with a random unknown error later in the process and tries to make an error report but crashes out completely during that phase. I can't get any debugging information out.

I've tried disabling UEFI Secure Boot from BIOS and have gone through looking for any weird looking power savingfeatures in BIOS but I'm not really sure I'm looking for? I've formatted the disks with long format i.e. writing 0s just to make sure no weird partition problems from all the failed install attempts.

I've also tried two different USB sticks.

Any advice for where to look for errors or what to try switching off? Here is the hardware spec. Again I have two identical PCs both with this issue.

Processor (CPU) Intel® CoreTM i5 Six Core Processor i5-8500 (3.0GHz) 9MB Cache

Motherboard ASUS® H310M-A R2.0: Micro-ATX, DDR4, LGA1151, USB 3.1, SATA 6GBs

Memory (RAM) 16GB Corsair VENGEANCE DDR4 2400MHz

Graphics Card 2GB NVIDIA GEFORCE GT 1030

Edit: After adding nomodeset to the boot parameters and installing with no graphics drivers it crashes and when attempting to create the installation error report. Ubiquity crashes stating the home partition has less than 0.0MB of free space. This is on an install specifying a fresh install on the entire 250GB SSD.

Is it possible some kind of error log is filling up the drive? Hard to see how you can generate 250GB of error within a few minutes though... I don't know how to read the error logs while installing. Can I drop an init level and cat the logs? I'm so lost... :(

Edit: Managed to drop an init level and see what's going on. The screen is having a lot of fun posting a LOT of errors cascading down the screen. Got a photo to read the errors: PCIe Bus Error: Secerity=Corrected type=Phsyical Layer... etc

Going to do some googling of this. Maybe this error is filling up the root partition

Edit: Added pci=nomsi to the boot parameters on grub led to a successful installation. Reference: PCIe Bus error severity=Corrected

This came about after using nomodeset parameter which let me see the logs filling up the hard drive.

I think there are still some underlying issues with either the CPU or the WiFi chip which is talked about in other discussions, leading to this error. As long as I can keep them suppressed from filling up the SSD I guess its okay...

  • I had similar problems until I used the "nomodeset" option to boot the live usb. So, on the grub screen press "E" to edit the boot command and add nomodeset after quiet splash. After successful installation, do the same until you install the proprietary nvidia drivers. After you install the drivers you will no longer need to use "nomodeset". – user3140225 Jun 4 at 7:47
  • @user3140225 Excellent thanks, not tried this yet. I'll try this as soon as I get to the office and let you know. Thank you! – Marogian Jun 4 at 7:48
  • By "For the first time in several years of using Ubuntu", do you mean that these two computers previously had Ubuntu installed on them? How did you create your USB drives? I previously used UNetbootin and I was getting weird problems sort of similar to what you're seeing. Then I gave up and I used a Windows-based program called Rufus and then things worked out. That's all I use now; I haven't tried UNetbootin in a while. (And yes, that means you will have to write the boot disk with a Windows machine.) Good luck! – Ray Jun 4 at 7:48
  • @Ray no as in I've been using Ubuntu on several other PCs and laptops over the years and never seen anything like this kind of problem during install. I use the standard Startup Disk Creator tool on another Ubuntu PC with two different USB sticks. I'll try Unetbootin. Haven't tried that yet, thanks! I don't have ready access to a Windows PC bit I can try that in a few days if nothing else works. Thanks. – Marogian Jun 4 at 7:51
  • @Marogian Sorry, just to clarify, I meant that UNetbootin was giving me problems. Rufus (on Windows) is what I now use. You can try downloading another image and check the md5 checksum to make sure you downloaded it correctly. Anything is worth a try, I guess? – Ray Jun 4 at 7:57
0

Random crashes, i.e. hardware stability problems like this (which is what I gather from what you write is the issue here) can be related to hardware timing. Try resetting your system's BIOS setup to "safe" values. Most BIOS setup programs have either "fail-safe" factory defaults or a "safe" set of pre-set values. If that doesn't work, your hardware is the most likely culprit. Some Asian hardware manufacturers cut corners in a major way, but in such a way that Windows still runs most of the time, and that's all they care about.

  • Thanks. Is this really likely with two different PCs? Also to my knowledge Asus and Corsair are fairly reputable brands... But I agree it sounds like faulty hardware – Marogian Jun 4 at 7:47
  • I don't know Corsair from experience but I agree with you on ASUS reliability. Still, the BIOS timing settings might be the issue here. If both systems have the same history (same supplier, same installation/configuration procedure, it is possible. Barring that, I share your doubts. But random failures suggest glitches which are more often related to timing than to "firm" hardware incompatibilities. Anyway, that's all I can suggest at this point. – Frank van Wensveen Jun 4 at 9:28
0

After help I discovered the underlying issue was caused by my log files being flooded with errors caused by some problems with CPU or WiFi chip architecture.

This is suppressed on install by editing the GRUB settings on install:

On the grub screen press "E" to edit the boot command and add pci=nomsi after quiet splash

After successful install I cat'd /var/log/kern.log and verified the error was still flooding in on a real install, so to add this parameter permanently to grub:

sudo nano /etc/default/grub

And add pci=nomsi parameter to the file like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi"

Save the file and then run sudo update-grub and reboot.

Not ideal but it seems to be working for now...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.