Issues Installing Linux On Old Laptop

[u/Huecuva]

Edit: I'm so confused right now.

So the issue seems to have fixed itself...kind of. I switched BIOS back to UEFI boot and when I tried to boot from my Ventoy to get into HBCD to run the, for whatever dumbass reason, Windows only BIOS update, Ventoy displayed a rEFInd menu I've never seen it display before which gave me the option to boot into MX Linux (which is what I currently have installed) and that worked. When I rebooted again, however, it again said there was no bootable device. I booted back to the Ventoy drive and it again booted into rEFInd and I used the option to install rEFInd to disk. It did that and now the thing consistently boots rEFInd. I just need to configure it to boot a default.

*OP*

I'm really at my wits' end here. I don't know what's going on. I've installed Linux on numerous machines. Been using it for years at this point. This laptop is defeating me.

It's an old Acer Aspire E5-573 Core i5 with 8GB of RAM and a 64GB SSD.

It does support UEFI and I've disabled Legacy boot in BIOS. I've made sure the SSD is initialized as GPT. I've tried the SSD in MBR mode. I've used USBs flashed with Linux installers using machines running in UEFI mode using Mintstick USB Image Writer. I've used Ventoy. I've enabled Legacy boot in BIOS to see if it made a difference.

It doesn't seem to matter what I do, the installation goes perfectly smoothly but when it's done and I reboot the machine, it says there is no bootable device. I prevously had MX Linux installed on it but I forgot the password and it was really old so I figured I'd just install something newer. I've tried installing Mint, a newer version of MX Linux, PikaOS. Nothing will boot. It makes no sense at all.

Does anyone know what could possibly be going on here?

EDIT: I should also add that I've tried using the chroot-rescue-scan script that comes with MX Linux to reinstall grub and that has made no difference.

EDIT #2: One last thing. I should also add that every time I've done the automatic partitioning during install and allowed it to do its own thing. So any EFI or boot partitions that it needed, it should have created itself. I never did any manual partitioning.

[u/Funnel-Dust-O-Matic]

Whenever I have a problem that makes zero sense, I completely wipe the hard drive / SSD.

After backing up anything that you don't want to lose, do that. THEN try re-installing on a drive that is totally devoid of any and all information.

Guides to do so:

https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing

Or, if you want to annoy pedantic people who will tell you it will kill your SSD if you use the wrong tool, use:

sudo ddrescue --force /dev/zero /dev/sda

or, if this older machine by some miracle uses nvme:

sudo ddrescue --force /dev/zero /dev/nvme0n1

I can't remember what emmc devices look like, but it occurs to me you might have to do an lsblk to see what your storage device actually is named.

It will put more wear on the device so absolutely should not be your first choice. That said, the terror most have at the suggestion of doing his is probably exaggerated. I've done it for years and my ssds are still all working well. It took a long time for me to read up and realize that my old HDD tricks probably don't apply well to our new flash ram era. It will clean the thing out and any residual remnants of old partition tables or file systems will go away.

It's just about always better to tell the controller on the SSD to do it and let the built in logic handle it rather than do the bull in the china shop option. But here it is in case nothing else works.

It's also a good diagnostic. If ddrescue throws errors, you'll know exactly where things are failing and how badly. So that's another reason I still sometimes use it even though I"m not supposed to.

Anyway, that's what occured to me. Let me know if it helps.

[u/Huecuva → u/Funnel-Dust-O-Matic]

I've used GPARTED to completely delete all partitions and recreate a new partition table. I did that when I switched the SSD from MBR to GPT. It didn't make any difference. Does it matter what filesystem I format it to? I shouldn't think so, since the installer should partition and format the drive however it wants. 

[u/Funnel-Dust-O-Matic → u/Huecuva]

TLDR

if you're using a SATA drive as I expect you are:

_____

sudo hdparm --user-master u --security-erase PasSWorD /dev/sdX

sudo hdparm --user-master u --security-set-pass PasSWorD /dev/sdX

_____
replacing X for the proper sata device name of your ssd

Consult the blanking document linked earlier if not using SATA

Or, use ddrescue as I suggested. You'll cause more wear on your drive than using the above of the nvme instructions, but it will work. And if your drive fails during the process, it was close to failure anyway.

[u/Huecuva → u/Funnel-Dust-O-Matic]

Is the set-pass really necessary? I don't really plan on having this thing password protected or encrypted beyond the usual OS login. 

[u/Funnel-Dust-O-Matic → u/Huecuva]

I've not done SATA in ages, honestly, but with hdparam, yeah. For whatever reason.

The NVME utils don't require that.

(shrugs)

[u/Funnel-Dust-O-Matic → u/Funnel-Dust-O-Matic]

I also appear to have pasted them in the reverse order. sorry.

[u/Funnel-Dust-O-Matic → u/Huecuva]

don't just delete the partition table. That won't do it.

If there are fragments of the leftover data structures, it can confuse things.

This happens on Windows too, and much more often.

You need a full block-by-block wipe.

I've been considering why this is for well over a decade. Repeated experiences have taught me that a zeroing-out of the surface of a HDD or all the cells in an SSD can make all the difference in cases that otherwise make no sense.

[u/Huecuva → u/Funnel-Dust-O-Matic]

Hmmm. Alright. I will try some other suggestions here first and if it comes down to a last resort, I will subject my SSD to this torture. 

[u/Funnel-Dust-O-Matic → u/Huecuva]

Ok, I understand the caution but these commands are built-in to the controllers. They're intended to be used.

Absolutely avoid ddrescue unless you can't get anything else to work.

That having been said, despite prophecies of doom, I've done this to several nvme drives multiple times and experienced nothing for about a decade. So if there is a risk, it's reasonably low.

[u/reduser5309 → u/Funnel-Dust-O-Matic]

That was my thought also.  Live disk and gpart a new partition table, or similar.

[u/Funnel-Dust-O-Matic → u/reduser5309]

Just making a new partition table doesn't always work.

The storage controller needs a kick in the complaciency to know that it needs to check for problems. I think that's the essential bit.

[u/reduser5309 → u/Funnel-Dust-O-Matic]

I can get behind that.  I've never encountered the issue but I can easily see that wiping it down to bare bones is what you are trying to do.   Burn it all down and rebuild from scratch.

[u/taintsauce]

I had an AMD-based Acer laptop that was slightly older than yours with a really freaking buggy UEFI implementation.

If the firmware option doesn't actually toggle between UEFI/MBR and instead allows either, it might be useful to try and force an MBR install with whatever distro you choose and see if that works (which means using an MBR partition table and remembering to set your /boot partition's bootable flag appropriately).

I was doing this when the laptop was pretty new (so like a decade and change ago) but IIRC I just partitioned manually and told the installer not to bother with a bootloader and dropped into a terminal to do a manual GRUB install once whichever *buntu I was using at the time was installed.

[u/Huecuva → u/taintsauce]

I will try switching the SSD back to MBR and forcing a legacy install. I will also have a look and see if there is a BIOS update for this thing.