search

GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
345 stars 11 forks source link

3.1 Installer Now Crashes on Both Acer C720 and Dell 3189 #591

Closed robertmaynord closed 3 years ago

robertmaynord commented 3 years ago

To me, this seems like a new issue, starting today. I have installed GalliumOS 3.1 on 20+ Acer C720s up until the day before yesterday. Today the installer consistently fails on multiple C720s, and I receive the message, "Installer Crashed". At the same time, I have previously been installing 3.1 onto Dell 3189s (this is for a school). Last week I installed onto16 Dells. Today, I consistently receive the "installer crashed" message on all attempts.

I am suspicious that something happened upstream with Ubuntu, or perhaps some other change has occurred. I use the mrchrombook firmware, and it causes no problems. The hard drive seems to format fine. Even the 3. 1installer is working fine up until about 80% completion, and then it freezes with the "installer crashed" message. Same exact behaviour on both Dells and Acers. I have re-downloaded the 3.1 installer, but it makes no difference.

Has something changed that would caused this problem?

robertmaynord commented 3 years ago

More clues: I noticed that Ubuntu did a bunch of updates to all of their distributions just this morning! 2) One of my attempted installs froze at the "installing grub2" message. 3) I also saw some error messages mentioning "ubiquity", and "python".

reynhout commented 3 years ago

@robertmaynord Thanks for the report. The most likely cause is the Ubuntu rev of grub-efi-amd64-signed, which looks like it was released to the public repo today.

Immediate workaround is to install with Wi-Fi turned OFF. (It is is not adequate to deselect "Install updates in background", because the Ubiquity installer does not follow that preference for all activity)

After installation, it should be safe to update packages. I haven't tested with this rev, but this is usually the case.

robertmaynord commented 3 years ago

Great! Makes sense - I'll try installing with WI-FI turned off tomorrow morning..... Robert

reynhout commented 3 years ago

@robertmaynord This should now be fixed for all installations. No Wi-Fi or other workarounds required. Please let us know how things go for you.

Thanks again!

robertmaynord commented 3 years ago

Yep! I'm back in business - the installation is working fine now. Thanks!!!

tinker2much commented 3 years ago

This is also happening on an Acer Chromebook 11 CB3-111. The advice to disable wifi does NOT work for me. If I downloaded the ISO again, would the issue be fixed there? If I used my existing ISO and updated it before installing it, would that work? (I'm not sure whether a live system uses its updated packages during installs or packages it started with...)

robertmaynord commented 3 years ago

I am due to install tomorrow on another Acer C720. If the install fails, I'll let you know. It could be that Ubuntu did another revision today....

reynhout commented 3 years ago

@tinker2much If disabling WiFi does not fix the issue for you, then you must have a different issue.

By far, the most common cause of installer crashes are: bad USB drives, and bad writes to USB drives.

See the troubleshooting steps at the bottom of https://wiki.galliumos.org/Installing/Creating_Bootable_USB for the details.

If you can't find the issue there, post your syslog after a crashed install, and I'll take a look: pastebinit /var/log/syslog

tinker2much commented 3 years ago

New download, md5 matches. Burned to a new usb stick, md5 matches. Did not enable wifi, took all defaults during installation, the installer crashes. Having not set up wifi originally, can't seem to get either wifi or ethernet (via a usb ethernet dongle) to work now, so can't do the pastebinit. Ideas?

reynhout commented 3 years ago

Disabling WiFi prevents downloading potentially-incompatible package updates from Ubuntu. Your install will proceed with only the packages included in the ISO, with no new variables added.

So if the installer is still crashing with WiFi disabled, then updated packages are not the cause of the problem and you will probably get the same results with WiFi enabled.

PS: Did you verify the ISO as-written to USB? That's the most frequent failure. New USB should fix it, if you're writing properly (dd or cp, Win32DiskImager, or Rufus in DD mode). I don't trust Etcher personally, despite its prominence in the docs. :(

tinker2much commented 3 years ago

I tried it with wifi enabled. Crashed. I was able to pastebinit: sRXy5ZX84T. The ISO as written matched.

reynhout commented 3 years ago

@tinker2much Thanks for the logfile.

It looks like a postinstall script is failing. It appears to be a package that is downloaded from the net. I'm not sure if it's the same as when WiFi is disabled.

The first interesting errors are at 01:49:37:

Sep  4 01:49:37 galliumos ubiquity: Could not prepare Boot variable: No such file or directory
Sep  4 01:49:37 galliumos ubiquity: grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
Sep  4 01:49:37 galliumos ubiquity: Failed: grub-install --target=x86_64-efi

Any possibility that your internal storage is sketchy? Or has been formatted in an atypical-UNIX way?

I have a GNAWTY with UEFI firmware, so I will see if I can repro locally.

tinker2much commented 3 years ago

The internal storage was last formatted by the installer for the "Raspberry Pi Desktop on Debian Buster, so there shouldn't have been anything unusual there. I would have thought that any GNU/Linux installer, particularly if you chose "Use full disk", could handle ANY previous disk configuration - that it would just steamroll whatever was there to a null state and then partition, format, set flags, etc., just as it wanted.

reynhout commented 3 years ago

@tinker2much You would think that, but we see occasional exceptions. Usually with USB drives and NTFS/etc formatting, but it was worth asking.

reynhout commented 3 years ago

@tinker2much I seem to have a hardware issue with my UEFI GNAWTY, so I was not able to test.

@coltondrg, is your GNAWTY functional?

tinker2much commented 3 years ago

It seems that most of the install was already done successfully. If the target disk is really fine EXCEPT for grub not having worked during the install, perhaps I could do grub-install to the target drive after the fact, from another booting of the live stick. But I don't know how to attempt that.

Hurricos commented 3 years ago

My two cents: whenever I do a GalliumOS install, I

As far as grub cares, this removes any partitions and reliably prevents weird interactions when installing grub.

tinker2much commented 3 years ago

That sounded SO promising. If it isn't just that my drive is bad, then it has to be something about the current state/configuration of the drive? But I tried it and it didn't help. Grub still fails during the attempted installation. That surgical strike did seem to be enough for the partitioning to disappear. What else could be the issue? What if I cleared more?

tinker2much commented 3 years ago

I updated the MrChromebox firmware using a galliumOS live USB stick. This took me from this version:

Acer Chromebook 11 CB3-111/131 (Gnawty) Intel (R) Celeron (R) CPU N2840 @ 2.16GHz FW: MrChromebox-4.9 01/04/2019

to this version:

Acer Chromebook 11 CB3-111/131 (Gnawty) FW: MrChromebox-4.12 06/04/2020 Intel (R) Celeron (R) CPU N2840 @ 2.16GHz 2048 MB RAM

After that, I was able to install gallium to the internal emmc disk with no issues from grub. I don't know why the older firmware, which allowed installation last fall, was tripping up grub during recent installs, and I don't know why the newer firmware now allows installs, but I'll take it.

Thanks to everyone for their suggestions. I wanted to let you know that this is resolved (And that, although it seemed likely in the beginning, my trouble was in fact unrelated to the original poster's problem. So, sorry for side-tracking this thread.)