About huge kernels... the question is not "are there use cases where just using a huge kernel is OK" as we all know that the answer is "yes". The question is rather "are there use cases where a huge kernel can be used but *not* a kernel and an initrd". I am still waiting for someone to provide example of the latter.

As for me, as both a distribution maintainer and an end user, the motivation of getting rid of huge kernel was:

• less kernels to build
• less maintenance
• less uselessly cluttered boot menus

As an aside, out of curiosity I had a look at os-initrd-mgr mentioned by LuckyCyborg and its associated man page as well as the associated README.txt, very interesting indeed. I hope Stuart won't mind, I attach these files to this post so that people interested but not owning hardware for SlackwareARM, as me, won't have the hassle of finding them. Caveats: consider these as a snapshot just for illustration, the sources are in slackwarearm-current, and the man page was converted using pod2man.

And indeed there's dracut.

PS the running kernel of the Slackware system of my Linode VPS has no associated initrd, and all its drivers are built-in so the output of lsmod is empty. But it has been built by Linode (with a compiler from Debian), not by me

Attached Files

	os-initrd-mgr.txt (8.2 KB, 25 views)
	os-initrd-mgr.man.txt (11.2 KB, 20 views)
	README.txt (4.4 KB, 14 views)

kdeconnect-kde-21.04.2-x86_64-1 is crashing when trying to connect to a phone. It was confirmed by at least another user at Slackware room at matrix.org.

A bug was reported here although it's Neon related. It looks that a patch is available.

Dunno if the fix above could be applied to -current, but still reporting here FYI.

UPDATE: did some investigation with the help of a fellow Neon user. It looks like pulseaudio-qt is the culprit since last update which broke ABI and may require a kdeconnect-kde bump.

UPDATE 2: it looks that a quick fix is to recompile kdeconnect-kde-21.04.2 against pulseaudio-qt-1.3 release just a few days latter.

1 members found this post helpful.

There is no need to use an initrd for a firmware update.

I just have

in my elilo.conf, with not problems whatsoever. It survives updates with no manual intervention at all.

An initrd is "one more point of failure". It needs to be used when it is useful -- when a recovery console is needed, when and when the cases mentioned above are present: lvm, mdadm, etc.

In the worst case, I seriously suggest using the "initrd built into the kernel" (actually, appended) option, which I created as a proof of concept and presented right on this forum. It didn't work as expected, but there is _no_ problem of making it properly, with udev and such.

But _a single file_ is quadratically less likely to fail than two files.

On grub package, files in /etc/grub.d/ has no .new suffixes. As such pkgtools will just override these files including any custom settings.

For instance, I use a password protected prompt for any non-default option in grub. This is achieved by adding '--unrestricted' to CLASS env in /etc/grub.d/10_linux as follow:

as well as including a specially crafted /etc/grub.d/01_password.

Whenever grub is updated, I need to manually edit CLASS as it is reverted back to its original state by the update.

It would be nice to have these files upgraded as .new assets when running 'slackpkg new-config'.

1 members found this post helpful.

Oh, the initrd usage increase 4 times the risk of failures, because it's a second file? Not bad! Then, we apply the servers politics as they are today - any supplementary file is a supplementary risk of failure?

BUT, what we do with that one trillion or so of files which the Slackware and its community insists that everybody shall install, no matter they will be ever used, because that Holly Full Install?

Following your logic, then the Holly Full Install increases the risk of failure with some trillions of trillions of trillions times. It's quadratically, right?

I found that KDE bug searching for this issue; which I also have. Actually it was crashing constantly when trying to load too. Could be it was trying to connect to the two phones I have paired with KDE Connect.

According to ChangeLog.txt package pulseaudio-qt-1.3 was upgraded on June 14, package kdeconnect-kde-21.04.2 was upgraded on June 10.

I can confirm that rebuilding kdeconnect-kde-21.04.2 against pulseaudio-qt-1.3 fixes my issues.

2 members found this post helpful.

Can you read that again slowly?
The fact that your initrd only contains a microcode update doesn't mean that you are not using an initrd.

2 members found this post helpful.

If your kernel has enough built-in modules to boot, then an initrd doesn't have to be updated each time even when you use luks/lvm. I only rebuild mine when cryptsetup, lvm/devmapper, or the processor firmware blob need to be updated, and sometimes even that is not strictly necessary.

I think people are focussing on the wrong aspect of this discussion: it's not whether or not one needs an initrd that's significant, the argument is whether there's a valid reason to ship two different kernel configs, when a single config somewhere between the two extremes would, for the vast majority, support both cases.

PC hardware is much more uniform than back in the old days when the decision to have both a 'huge' and 'generic' kernel was made. Time to reconsider, IMO.

2 members found this post helpful.

Quick note to Pat:
I had posted this over on the "SBo's not building on current" thread but Matteo and I are in agreement that this is the better place.
the packages xfce/mousepad and l/libgtop still have straggling .la files in usr/lib(64). No biggie, they can probably be zapped the next time they are updated.

First thing that I did (last install of Slackware 3yrs ago), was to build custom kernel withoud initrd: hibernation works fine.
luks reqire initrd if boot is encrypted. Same with lvm: if boot is non-lvm, initrd is not needed (I don't have any experience with lvm, so I am not sure if such setup works).
In some cases one can use PARTUID instead of UUID.

So, as I said in my post, there's obviously reasons some might need an initrd. I've never disputed that. My question is for those that don't *need* an initrd, what benefits are seen by using an initrd? Are there any? It seems to add complexity for no benefit.

LuckyCyborg seemed to imply that Slackware was being held back by defaulting to a huge kernel and requiring users to set up their own initrd *if* they wanted/needed to and now that we use a generic kernel and the installer generates an initrd automatically, Slackware can "progress". I'm trying to find out if there's truth to that statement.

(I do understand Didier's comment about one less kernel to build/support, but it seems that is not a motivating factor by Pat since he still provides both.)

2 members found this post helpful.

OMG! What a huge complexity added!

With all respect, YOU and other Gurus here advocates an ancient method of boot, which make users to miss a very important recovery console, if you ignore anything else, while giving vague and questionable benefits of easiness.

I do not care what you do with your custom kernels, BUT advocating the avoiding of initrd is just wrong, and there's WHY:

As preamble, on my boxes fleet I have two HP Elite 8200 USDT, bought at price of one, basically because the seller was not aware that this type of PC needs an (external) power supply of 180W when there's a discrete video card in its MXM slots, BUT usually them being shipped with a 130W power pack. So, the guy thought that second box is dead, and buying the first, I received the second one gratis (as spare pieces) with a 130W power supply - at home I have just removed the MXM video card and it started to work. However, they are nothing spectacular: Intel i3-2120T SandyBridge CPU, 4GB RAM (for laptops) and 160GB 5400 RPM SATA drives (for laptops).

So, with those two identical boxes I did today an experiment: with and without initrd, what happen when I will miss to update the bootloader, after kernel upgrade? Yeah, they both haven't yet applied the update Wed Jun 16 18:32:47 UTC 2021, being still on kernel 5.12.10 and the rule was to not relly on any other computer or USB live systems for recovery - only the smartphone being eventually allowed.

Before updating them from their local/internal rsync mirrors, I prepared BOX ONE to boot the HUGE kernel and I removed any trace of initrd from system. The BOX TWO, I kept as usual, with the initrd usage, prepared with the script shown several posts before - with no FAT32 modules as usual.

Then, I did the updates (including upgrading the kernel packages to 5.12.11) on both of them, BUT without updating the files from the EFI partition(s) and rebooted.

The BOX ONE, booted the 5.12.10 HUGE kernel and sent me on the Linux console, with no functional keyboard and mouse. As expected, as my keyboard and mouse are USB, and there aren't anymore here the 5.12.10 modules. Essentially, failing to update the bootloader, the HUGE kernel locked me out of this box.

The BOX TWO, booted the 5.12.10 GENERIC kernel and the associated initrd and sent me in the Linux console, with FUNCTIONAL mouse and keyboard. I was able to login as root, BUT not to mount the EFI partition. And of course I had no Internet, and no more the modules package for 5.12.10 because the mirror update.

So, using my smartphone I downloaded this package from the slackware.uk's cumulative mirror, then switching the phone's USB connection to USB MASS STORAGE, I was able to connect the phone with an USB 2.0 cable to computer, to mount it like any USB stick and to retrieve the package.

Next, I extracted the 5.12.10 modules on their place, then I was able to mount the EFI partition, then after generating the proper initrd for 5.12.11 and after copying the kernel and it to the EFI partition, I did a reboot.

Guess WHAT? The BOX TWO behaved as was properly repaired and booted fine to the Plasma5 desktop as usual. FULL RECOVERY!

The conclusion of my experiment is obviously that the usage of initrd results on a much more robust system.

Compared with the no keyboard/mouse/network (aka human owner locked out) given by the HUGE kernel alone on BOX ONE, this is a huge progress.

YOU Sir, and the other Gurus advocating the HUGE kernel usage with no initrd, for a questionable easiness, you are guilty of half of threads showing in this forum, regarding "I did slackpkg and now I am locked out of my box. What I can do?"

And of course, many of those run away saying to who want to hear them that Slackware is VERY DIFFICULT.

And that's sad, because Slackware itself is NOT difficult, YOU make it difficult with your myths.

PS. I know, I know, I could have added the VFAT modules to initrd, then I would have been able to directly mount the EFI partition and there could have been avoided the smartphone download of kernel modules.

PS2. Please do no lecture me about live systems - in fact I have several USB hard drives, hosting and capable to boot full installations of Slackware -current with rsync mirrors. Heck, I have even a Win-To-Go (live system) on Windows 10 Pro. BUT, not everybody have and/or uses them, before to hit issues.

WILL YOU STOP PUTTING WORDS IN MY MOUTH? You've been doing this a lot lately and I really don't appreciate it. I did NOT and never have advocated for no initrd on Slackware. Seriously, learn to read my posts. I'm trying to learn here and I don't appreciate you ignoring my post and pretending that I'm saying you're wrong.

I am asking why you think Slackware was being held back by not automatically generating an initrd and what "progress" can be accomplished since it is doing it now? I already provided several examples of when initrds are *needed* and you have now showed me one example of being able to recover a system that was poorly updated by having an initrd. But I can recover just as easy if I keep my old kernel and entry in the bootloader or if I have a usb boot setup. Having an initrd in the case you provided is one of many ways to recover the system I don't really see how this is the big "progress" you're preaching.

I'll quote your line again that I was asking the original question about:

What progress was made by automatically generating an initrd with the installer? Why do you believe that defaulting to huge was holding back Slackware?

1 members found this post helpful.

The job of the initrd is to do the bare minimum needed to mount the rootfs, nothing more. The only advantage to using one that I can see is it allows a little extra flexibility about what can be passed as root=, i.e. you can use LABEL= or UUID=, or one of the /dev/disk/by-* symlinks

I favour having a separate dedicated recovery environment rather than trying to shoe-horn that functionality into the normal day to day initrd, so I disagree with LC on that point.


As I said above, for me, whether there's an initrd or not is not significant to the question: "two kernels, or just one?"

BTW, if we want to continue to discuss this, its probably best to do it in its own thread rather than in this one.

1 members found this post helpful.

Hi , here have a official patch to restore yubikey compatibility on new gnupg package.

https://git.gnupg.org/cgi-bin/gitweb...0e183d8f0b1a57

1 members found this post helpful.