lilo is so dead small mom and pop shops like Cisco and Juniper have a few appliances, Linux based, that relies on this dead horse to fire up products sold and supported as fresh as May 2024.

Lilo is more likely a case of "it works so well and is so simple to use there is no need to reinvent the wheel". Maybe for bare metal users where the UEFI vendor delivers half-baked solutions one might need a few options within lilo or something altogether to fix someone else's problem, but as a boot loader, it is far away from a dead horse.

Since WHEN the LILO is used by the ARM or RISC-V devices?

No offense, but I thought that's x86 only...

Well, Lilo is not maintained anymore and this by itself can cause problems, like this problem with RAID-1 on NVME. Found a workaround, but still, I wish I had the skills to fix it, or Lilo was still maintained.

Both companies have shifted away from custom silicon and embraced ye ole x86_64, for mass availability and simplicity with physical hardware and cloud support. So yes, it is x86 only. Also, as a VM, the boot loader is oblivious to the hardware - that’s a function of the hypervisor. On bare metal, they have the ability and luxury to cherry pick the hardware they want that supports the software and vice versa.

Nice to see you are sticking it out. One strong contender for being the cause of your problems is also the "nouveau" graphics driver you've been using. I've seen a few of your threads and know you've mentioned using it before.

I just did a fresh install to dual boot slackware64-current on my desktop not long ago. This machine has a different card than yours, but it is nvidia (GeForce GTX 1660 SUPER). I tried using the system as-is for around a week and it started hanging at random times. Sometimes it was good for a day, others it wouldn't wake from suspend (had hung I guess, couldn't ping or ssh it either), other times I would do something like close firefox, the desktop re-draws, and then just hangs. Only way to get it out of this state is a hard reset. I switched the setup to use the latest nvidia drivers for the card and its working fine again.

I had this exact same problem in 2021, when I tried using nouveau drivers the last time. Looks like things haven't gotten better in the last 3 years.

I like to try to support the open source drivers, but having my machine hang daily with unclean shutdowns on my disks is just not acceptable. There's nothing to really go on for bug reports either since I have to power-cycle to get anywhere. If it can do that to my machine, it's possibly a problem for you too.

If you want to run the official drivers, there's a number of ways to do it. Easiest way is probably using the .RUN script that Nvidia supplies for their linux/unix drivers: https://www.nvidia.com/en-us/drivers/unix/

Your Nvidia GTX 1060 card came up as supported by the 550.90.07 drivers.

Note that to run the .RUN script to install those drivers you should install the xf86-video-nouveau-blacklist package you find under extra/ in the slackware tree. Reboot and then run the nvidia script from 'init 3' runlevel (you might have to set the nvidia RUN script executable first). You also need to have the kernel-source package installed to build the nvidia kernel modules. After satisfying those conditions the .RUN installer is basically point and click the buttons for a couple options like adding 32 bit drivers and an Xorg config file. You just have to remember to rerun the script after any kernel updates to rebuild the modules for that kernel.

1 members found this post helpful.

It depends...did they use a tester or a multimeter on it? It is rare, but PSU's do fail. (I think I've only had one go bad, thankfully, in the 20 years I've been using/building computers.)

If your computer's working with a clean install, then that would probably be the culprit, though.

Another thing to try...replace the cord to your monitor. A bad monitor cord can mimic all sorts of video card problems.

however (not addressing the OP (yet ) )

I think the takeaway could be the decades old -current conundrum:

So many times I've heard the seasoned Linux user to So much so there should be some sort of fencing for accessing current IMHO (not that i'm asked about anything here):

And a long list hosted somewhere with all the participants listed there so everyone can see and this text on top of the list.

Many a tear (and 2c's) shed could be spared had I been granted this wisdom and knowledge decades back...

Whacha Y'all think?

2 members found this post helpful.

I apologize for not taking part in the thread; I have had a close family loss and emotions as well as stress has being the highest.

I agree with you as my 'most-likely' suspect (the motherboard) seems to be fine.

Anyhow, since the discovery that the hardware "seems to be ok" and cince I reinstalled everything bringing the system to its previous state, I am running in to another issue but I guess I will start another thread explaining it. The thread is titled - mount/umount, back to basics -

A little touch up on this LILO/UEFI (in my opinion) silly argument, I have been installing slackware launching with LILO and it has been flawless. May I add, the matter of UEFI-no-UEFi seem related to newer HDD technology so, since I don't change my hard-drives every 3mnths, I am thankful that LILO is still on-board.

That's interesting and I will keep it in mind as it has also been a 'distant' suspect.

Thanks all for the inputs.

4 members found this post helpful.

Very sorry for your loss. No apology needed. A family loss is very stressful indeed. Take care of yourself and your family. Be well. We'll be here when you want to tackle this issue.

2 members found this post helpful.

@however:
So sorry, condolences and take care.

1 members found this post helpful.