Grub themes?! Interesting!
Is this something relatively new?
Thanks for the information.

91.7 MB for two kernels? What kind of kernels are these?

Right now I'm using a 5.1.11 kernel which is only 2.3 MB; the modules add up to 4 MB.

Sure, I compiled my kernel myself, but I've never even heard of a distribution kernel that was larger than 8 MB.

Just saying.

According to the git log the Starfield theme shipped in the grub source archive have been provided eight years ago. So I would tend to answer that this is something relatively old.

1 members found this post helpful.

If one installs both the generic and huge kernels and all that goes with them, plus the initrd-tree, well, here you go,

Attached Thumbnails

 

The information in those tables is not correct. Eg: LILO can boot DOS. I've seen it first hand. Also, eLILO supports network booting.
Those features are great, but this begs the question: Can an EFI partition be contained within an LVM/RAID or encrypted disk? I'm happy to be corrected but everything I've read seems to indicate that it cannot.
That is excellent.
No, it does not. If anything, it does the opposite. Which stage of their business model are we at now?
Thanks. You too.

1 members found this post helpful.

I have 290MB in my /boot/ right now. 23MB in the initrd-tree and the rest in various kernels and initrds. But then I also have 19 initrds and 20 kernels (I'm lazy and don't clean them out). The largest generic kernel is 6MB (a 5.4.30 built off Pat's config slightly modified) and the largest initrd is 7.3MB.

But if someone starts adding to the initrd-tree, it could bring the size up more quickly.

1 members found this post helpful.

Wait a second! I talked about booting from USB 3.0 adapter cards or NVME drives mounted in PCI-express adapters, like the ones from the attached images.

I have news for you! Both of them have no BIOS boot support. They aren't even seen by BIOS other than some obscure enumerated PCI devices. So, your beloved GRUB will not know that they are in your box because that non-EFI BIOS itself doesn't.

BUT, that UEFI DUET, like any honorable EFI implementation, have drivers for them: XhciDxe.efi and NvmExpressDxe.efi

IF somehow you managed to convince the UEFI DUET to load those drivers, then you obtained a little EFI which is aware of both your NVME drive and your USB 3.0 adapter card, and be able to boot from them.

Then, you may use your favorite boot manager, be it rEFInd, GRUB or even ELILO, to use those devices and find whatever is bootable on them.

Of course, you may use a classic hard drive to host a boot partition for your favorite bootloader, be it GRUB, LILO or SYSLINUX, then leave the Linux kernel to handle its things. It does work - and I tried this myself, but I will not consider this really as "booting from a NVME drive"

Why? What IF in your NVME drive is not installed Slackware but Windows 10 or MAC OS/X? How you boot them?

Did you tried yourself making an USB flash for UEFI DUET/rEFInd (using probably Windows), or you talk after just looking at archives?

While rEFInd is optional (at least on the particular build used by myself), if you chose also to add rEFInd to your flash drive, it will be certainly ran.

Attached Thumbnails

   

2 members found this post helpful.

If you can correct this information, great. This will help future readers of these tables.

Maybe this article can answer (even if it says that GRUB does not support LUKS2, although a partial support has been added in January 2020)

As I am confident that neither me nor a Slint user risks to be sued for patent infringement speculation about intentions of Microsoft do not interest me.

1 members found this post helpful.

@LuckyCyborg: UEFI DUET is good for you, great. I don't have the hardware to experiment, so can't practically compare with other software.

1 members found this post helpful.

Well it depends a lot on the artist doing the grub2 theme, which Slackware doesn't seem to have.
So it's kinda like a brick wall, not painted but serves a purpose nonetheless.

While we're at it, I don't think any bootloaders are visually appealing.
As long as they don't support all resolutions, there's not much point writing themes which will all get skewed on different displays.
And since you've mentioned refind is good looking, I remember PLoP boot manager it was the best looking and had a starfield background, but was proprietary.
Too bad, because the ability to run screensavers in background is a great feature.
Arguably, there are many useful features an 'ugly' bootloader could do, like ability to run MC, ability to defragment a drive, resize partitions, etc.
But for my use case, I think legacy grub or manually configured grub2 was the most functional one, so I prefer those two.

I've been using the bitmap below with LILO for years. It had to be converted to jpeg to be uploaded here.
Sorry I can't remember the name of the individual who was kind enough to create it.
I have LILO setup so the bitmap remains on the screen until an OS or kernel is selected. The "menu" is put into the upper right hand corner.

Attached Thumbnails

 

1 members found this post helpful.

Here are some interesting test results comparing various file systems on a NVMe SSD.

https://www.phoronix.com/scan.php?pa...esystems&num=1

Interesting article. However, I would like to add that there are more requirements for a filesystem than performance alone. Of particular importance are transactional guarantees. To me, the absolute fundamental minimum is consistency and durability at all times, including system freeze and power outage situations. In those situations where consistency cannot be guaranteed (bad blocks?), I expect the most graceful degradation possible. This is the entry hurdle for a filesystem to be even considered.

1 members found this post helpful.

OK, just stumbled across the "Slackware64 Linux" image mentioned above in post #41,

https://www.pling.com/p/1114180/

This should appear in the 5.9 kernel.
https://git.kernel.org/pub/scm/linux...38f0400a794aa6