And it works fine in my mini-PC!

I compiled it in one of much more powerful computers of mine, then installed it in my problematic mini-PC.

At least on console works like a charm, no UI/X tests because no X11 is installed now in that particular PC, being used as router.

Problem considered solved on 32-bits, but my laptop on x86_64 doesn't boot (stuck on ??).
Not what I expected with a kernel upgrade, without any notice of the need of an initrd!
I really prefered the 'old way' with a 'huge kernel' always working.

2 members found this post helpful.

On x86_64, the huge kernel isn't - it's actually generic, it seems. For now, if you're going to boot it, you'll need an initrd. Once you see how easy it is, perhaps you'll start using the initrd all the time :-)

2 members found this post helpful.

I confirm that

So, our BDFL finally decided to switch to the full initrd usage?

Yes, but using a generic kernel for a Slackware installation should be "very" interesting.

I like the huge kernel, it is simple and works on most hardware.

From a certain age, the days after new years are difficult

The usage of a generic kernel in installer would be rather "boring", as the kernel itself and the associated initrd are loaded in memory by bootloader.

Then, after the kernel boots, it have UDEV in initrd, then will be able to load the drivers as it needs.

So, permit me to dare to say that a generic kernel in installer would rather work in most hardware.

With an advantage: the static loaded drivers will not challenge each one in the kernel space.

-----------------------------------------
The real question is rather if we perfected already a method to generate a proper initrd for the installed operating system, for the first boot.

A workaround to avoid the customized initrd for the target OS, could be using initially a mega-initrd which include all the interested kernel modules, like the installer one does.

Then leaving to user the ability to customize it.

This sounds like a good topic for another thread.

I asked this earlier, but what is the benefit of using an initrd outside of the times it is absolutely required (lvm, luks, UUIDs, special requirements, etc). I understand the benefits of not having a "huge" kernel, but is there a benefit of an initrd over a purpose built kernel other than the time (and knowledge) it takes to make that custom kernel?

Believe or not, the typical Linux user suppose to use his/her Linux and not to became a Linux developer, then has no will to learn the noble art of customizing the kernel.

That is specifically why I asked it the way I did:

IF the user has the required time and knowledge to make his/her own custom kernel, there is no difference between the usage or not of a initrd, if there is no need to use some specific features, i.e. the hibernation or encryption.

At least this is my opinion.

gmgf, A reminder from the LQ Rules:

--jeremy

Obviously not, or the huge kernel package would have been missing. Instead, it was wrong.

And you think I would do this on purpose? Wow.

Anyway, fixed now in -current.

9 members found this post helpful.