rkelsen's post reminds me of the apparent fact that, as so often when it comes to installs and setups, UEFI vs. BIOS / elilo vs. lilo is a matter of your personal needs and preferences.

"MBR partitioning doesn't work with disks larger than 2TB" - Well, I'm a dedicated laptop user and I'm not sure that I'm still alive when standard laptops come with those disks. With MBR you're also limited to four partitions, but I only need three. Besides, as I understand it, nothing prevents you to use gpt partitioning and still boot with lilo?

"elilo is easier, safer and more flexible" - I've never had any safety issues with lilo over the years. Flexible - I trust rkelsen that this is true if you like to experiment with different kernels and distributions. But I don't. My main concern is that my laptop runs as it should, so I stick to the official slackware kernels. I sometimes (but rarely) try out another distro but then from a USB or DVD. Hitherto I've never found anything that beats my current install. Easier - not sure about that. Everything is easy when you'r used to it, but there's always a learning curve, and I suspect that it would take me more than "a few minutes" to master UEFI. Having read the manual I agree that it "is simply about having the right files in the right place". But I have to put them there, meaning that a kernel upgrade is slightly more time-consuming than when using lilo, requiring a few more operations. With lilo, I just have to remember to run 'lilo -v' after upgrading. I'm so lazy that I even boot from the huge kernel. The generic kernel was, as I understand it, once developed to cirmcumvent problems with limited RAM size, but with 8GB RAM there's plenty of space for the huge kernel. Booting may be slightly faster with a generic kernel, and even faster with UEFI, but it's fast enough for me.

With Linux/Slackware there's rarely the best option for all, only the best option for me. Some people prefer KDE over xfce, some don't. Some people prefer Firefox over Chromium, some don't. Some people will stick to GRUB, others to LILO and others to UEFI. And, of course, now and then some of us will be forced to change our habits due to hardware changes, security issues, and software no longer maintained. It might well be that I have to give up lilo in the future, but I can't come up with a single reason to do it now.

2 members found this post helpful.

You've gotta do whatever works for you... But your current use-case is very narrow and you will need to adapt sooner than you think.

Slackware ain't dead. It is alive and well. Slackware -current is my daily driver and I experience few problems. I generally upgrade my main machine regularly. I have some other boxes that I dont upgrade often and really that teaches me to prefer the upgraded versions of -current. My work and activities require me to keep a copy of Windows 10 on my machine to manage some stuff that I get from other people and run a few odd utilities that require a Windows system, such as speech recognition. Using windows 10 helps me to appreciate the power, flexibility, convenience, and freedom of Linux. Microsoft is getting more aggressive and oppressive every day. I do pity the hoi polloi living under Microsoft's thumb (or should I say "boot"), but I consider my own situation as well. I also occasionally need some utilities that require systemd or some sort of systemd emulation platform. I have dabbled with Arch, Mint, various flavors of Ubuntu and Kubuntu. Kubuntu is still a buggy mess. Mint 19 nauseated me. Arch is a pain to set up and offered me nothing in particular for my efforts, although I have gotten some Linux help from reading Arch's documentations. I finally have settled on a 16.04 Ubuntu and a 18.x Ubuntu for systemd. The 18.x runs better than the 16.04 Ubuntu but is heavily laden with bugs and various inadequacies. Some software still doesnt run properly on Ubuntu 18. Ubuntu is irritating and like Windows, frequently "phones home" and has way too many nanny-functions. Using Ubuntu helps me to understand the stability and simplicity and the "it just works" of Slackware and the Slackware model. My luggable machine is multiboot and by invoking the UEFI boot manager I can choose from ReFind, elilo, lilo, and grub. Refind is quick and is worth learning and there is nice documentation that can get one past some of the nonsense problems that messing with Microsoft creates.

It's not GPT that's the problem, it's UEFI. If you boot a GPT disk with a BIOS or a UEFI in legacy mode, you can use LILO in the traditional way. That's because GPT disks use their first sector as a "dummy MBR" into which LILO can be installed in the usual way. But there are two caveats:

1) If you want to dual-boot with Windows, that has to be booted in UEFI native mode. And if you keep switching modes, sooner or later you are going to use the wrong one and maybe brick your computer. So in those cases, you really need to boot Linux in native mode too.

2) The legacy mode of UEFI was enforced on the manufacturers and will probably not last forever.

A UEFI running in its native mode doesn't even look in the dummy MBR, so it can't find LILO.

In a cost/benefit analysis whether steps are hard or easy is one concern (and yes I know it isn't hard) but another is the number of steps, the time to deploy. Legacy BIOS simply has fewer steps and takes less time.

Future-proofing is very often just what the masses prefer as default which also very often is convenience at the expense of power and control. If that influenced me I'd be driving an automobile with power steering and an automatic transmission and still running Windows on my computers.

I don't get this at all. I don't see flexibility I see restriction and it isn't easier if I have to create a partition just to accommodate it... a step that is an option with BIOS but not required. My lilo.conf files routinely have 6-10 entries for multiple systems and kernel options. The only problems I have ever had were created by UEFI and GPT along with LILO's limitations at handling GPT. It is a tad picky.

Once again you are assuming things about me. In this case you are assuming I am ignorant of UEFI's requirements and abilities. I am not. What's worse is you assume that I would state a cost/benefit case while knowing next to nothing of either. That is not the case.

That said, it is entirely possible you know something I don't yet know. So could you explain how and why UEFI is both "easier, safer and more flexible" for you? Exactly what does BIOS prevent you from doing?

BTW GPT does not require UEFI and is a totally separate issue so please don't use GPT to justify UEFI. It would be better if LILO had fewer difficulties with GPT but UEFI as a solution seems to me akin to putting a plaster cast on your right hand for a hangnail on a finger of your left hand. It seems to me the greatest benefit of UEFI is almost totally Windows-centric. The stock Windows bootloaders have changed with most new releases and not a little of that is to make it a PITA to keep using older systems and not upgrade. By contrast Linux has been able to employ the same bootloaders for decades which is suitable (and a benefit) for FOSS but anathema to Proprietary Paid services.

Thank you for responding.

I use nVidia GPUs w/ nvidia proprietary drivers so I know next to nothing of adriconf, but I'll take your word that it is problematic in 14.2

I have dxvk built on 14.2 so I don't see a problem there.

I am not a common user of Office apps so I have little knowledge of what v 6.3.0.4 offers that is so compelling to wish for a hurry-up schedule for releases. I have far more interest in the sanctity and solidity of the base system than a single app version issue. That seems trivial af to me by comparison.

I would actually be interested in seeing your extended list.

RE: the MBR limits on 2TB

While this claim is (partially) true, it refers to the "classic format" of hard drives, with sectors of size: 512 bytes.

However, apparently almost all hard drives with big capacity available today uses the "advanced format", with sectors of size: 4096 bytes.

And the collateral effect of using the classic MBR on "advanced format" hard drives is that that MBR supports up to 16TB on their case.

I seen this with my own eyes, for my stupefaction, as one of my friends uses well the MBR on a 4TB hard drive.

True, the used operating system wasn't Slackware but OpenSUSE, but I do not think that matters, and my friend explained me the backgrounds of this little but obvious trick, which apparently is not known by many.

So, we still have to hit in future the MBR limits, at least for the home users...

4 members found this post helpful.

Wow! Lucky Cyborg... just Wow! Extremely interesting!

One of extended list member probably GIMP-2.10.x
https://www.gimp.org/release-notes/gimp-2.10.html

It requires to bump 14.2 system libraries versions and blacklist them from downgrade:
lcms2
fontconfig
glib2
gtk+2
poppler
babl
exiv2
automake
gegl

Initially. But once it is set up, there are actually less steps involved in deploying a new Linux kernel or Slackware installation using EFI.
So you never intend to buy a hard disk bigger than 2Tb? It is quite common to see computers with disks that are at least 4Tb these days. The computer shop near my house has 10Tb disks for ~ USD$350. Give it a year or two and they'll be half that price.
You seem upset. Don't be. You can do whatever you like.

With that said:

Flexibility - One example: I no longer use any external installation media to install or upgrade to the latest version of Slackware on my machine. This is because I copy the contents of the EFI directory from the Slackware tree onto the EFI partition of my machine. There is an entry in my eLILO.conf which allows me to boot straight into the installer. Slackware is installed directly from my local mirror of the Slackware tree. Time to deploy a new Slackware installation = greatly reduced, and even better when you factor in the time (& cost!) savings of not needing to create an installation DVD or USB stick.

Easier - There are less steps involved once it is set up.

Safer - There is no need to over-write the MBR of the disk. While I never had any issues using straight LILO, it can render your system unbootable if, say for instance, the power went out while that operation was being performed. I held my breath every time I ran that particular command.
I haven't owned a computer with a BIOS since 2012, and to be honest, I haven't looked back.
No, but the reverse is not true... and this was in response to your statement that EFI requires you to "jump through several additional hoops including special partitioning" in post #169.
That is not true. See my comment under "Flexibility" above.
That is not true either. Windows 10 can and will use an MBR and chainloader if the hardware requires it.
Yes, and eLILO has worked for me for the past 7 years without issue... eLILO, GRUB and rEFInd are all FOSS projects. None are proprietary.
Hmmm.

2 members found this post helpful.

Try building it with winegcc on 14.2...since SBo does not have mingw it can't be added to SBo since the compiler that build winegcc are too old and do not have C++17 support.

There are 5 CVEs that are reportedly fixed by newer versions than what is at SBo (6.2.5.2).

https://www.libreoffice.org/about-us...cve-2019-9852/
https://www.libreoffice.org/about-us...cve-2019-9851/
https://www.libreoffice.org/about-us...cve-2019-9850/
https://www.libreoffice.org/about-us...cve-2019-9855/
https://www.libreoffice.org/about-us...cve-2019-9854/

https://www.libreoffice.org/about-us...ty/advisories/

The point was not that these are such important programs, but that situations where the 14.2 base system is too old to proceed are becoming increasingly common.

I’ll give you that—it really isn’t that hard. In any case, I’m ready for UEFI booting once the need arises. Until then, my Legacy BIOS setup continues to work just fine for me. Old-fashioned, perhaps, but that’s why it’s such a great match with me…

That’s irrelevant. Legacy BIOS can handle GPT just fine. Surely, the boot partition will have to sit below the 2-TiB limit, but otherwise, booting off a GPT disk is no problem whatsoever under Legacy BIOS (unless you want to run Windows, but that, too, is irrelevant—at least to me.)

“Easier”… “Safer”… “More flexible”… If that’s how you feel about it, then, well… All the more power to you. I, for one, get all the “Ease of use”… “Safety”… “Flexibility”… that I need from my Legacy BIOS setup with GPT disks.

On the other hand:
Well, if, like me, you use GRUB to boot off a GPT disk under Legacy BIOS, you will also have to create a specific partition “just to accomodate it”—namely the “BIOS Boot Partition”. No big deal…

With 16-bit ways, even… The Master Boot Loader runs in 16-bit mode. (Though that's a CPU property. Even UEFI must start in 16-bit mode on a traditional x86-family CPU, although I guess it probably switches to 64-bit mode long before any boot loader comes along.) Even so, this is just about the boot sequence, anyway. Nothing that any operating system that eventually gets loaded, will care about.

That’s absolutely right… I spent the time to learn GPT, including booting off GPT under Legacy BIOS, as well as UEFI. I’m still sticking with Legacy BIOS for now.

My boot loader is a custom-built copy of GRUB, with a manually maintained configuration. (I built it under Slackware-current, by the way… So, no, Slackware isn’t dying… Just to stay on-topic.) I never have to touch its configuration, though, unless I add an operating system to my setup, or remove one. I don't even write any new menu entries manually, since I simply run a script that will generate them for me. All the ease of use, safety, and flexibility that I need.

Moral of the story: Just use whatever it is that you prefer. It really, really, really doesn’t matter to anyone anyway, … except to yourself.

Unfortunately, UEFI will not use a mirrored software raid device for the vfat partition.

2 members found this post helpful.

I honestly don't remember if I even referenced one. I might've glanced at the UEFI README on the installation media, but my understanding of it was pretty simple from reading other posts on the forum (I first did this at least 2+ years ago... might've been even longer, so my memory of it isn't great).

1. Create an EFI partition.
2. Format EFI partition as FAT.
3. Install Slackware.
4. When prompted to skip lilo, do that.
5. Let elilo install itself.

I think the most difficult thing was realizing that my motherboard presented two options for booting the Slackware installation media. One for legacy and one for UEFI. I initially booted the legacy without realizing it and found it wouldn't install elilo, which confused me.

I've ran into many problems with lilo over the years that eventually I dug in and became really knowledgeable with lilo and how to properly use it for my uses. I haven't had enough problems with elilo to dig that deep into it, but a lot of the syntax is similar between lilo.conf and elilo.conf, so it was a pretty simple switch.

1 members found this post helpful.

That actually makes some sense. Thanks

Evidently you missed a previous post about how Legacy can handle up to 16TB.

Not even a little. I'm just not that excitable at age 72 and I enjoy gentlemanly debate. You seem reasonably astute and gentle


This seems quite cool and I'm interested in checking it out. Again, thanks.


OTOH this seems rather silly and grasping at straws. I've employed a UPS for over a decade that will keep my PC up for almost 30 minutes but even before that it just was never an issue. Maybe you live where power outages are more common and if so, I strongly recommend a UPS. There are far worse possible problems from sudden shutoffs than having to boot from a rescue disc to re-establish the bootloader.

Anyway thank you for explaining how you've learned to make UEFI beneficial for you. I still think Windows is the major beneficiary but then it needs all the help it can get. I despise working with BCD. At least now I see that when the time actually does come that CSM is left behind, it won't be so much like mere "busy work".