Thanks, I will do it.

Hats off.

One more question, I found the following sentence from the Slackware 15.0 Release Note:

But `file geninitrd` returned nothing as well as command `which` or `man`, is it a replacement of command `mkinitrd`?

It's just a helper script located at /usr/sbin/geninitrd so you need to be root to run it.
Here it is (minus the licence part):

1 members found this post helpful.

Thank you Loomx and your dwm Howto and tools are awesome, I will take a try.

Regarding this geninitrd I believe that's a bad thing to use it. And here's WHY:

If you have read all my posts from this thread of yours, you have noticed probably that I say that I am adept of doing certain repetitive tasks in an automatic way, but I am against the auto-magic. And this geninitrd discussion is probably the best way to explain the difference between those 2 terms.

I believe that there is no glory in "manually generating initrds" each time after I will upgrade the kernel packages, because I do basically a job which could be done as well by a script and myself as a human, sometimes I may forget to do this particular task, putting the system in a damaged state, next failing gloriously to boot.

Yeah, it's an user error, but I think it's rather "the monkey missed to hit the green button when was shown the banana"

So, if we arrive at "automatically generating initrds" we have 2 ways to follow:

1. to make the system to execute certain repetitive tasks, as instructed by user, for generating a proper initrd. This could be done very simply, by putting this line in an install/doinst.sh template and sed it with the proper kernel version at build time.
Please note that there is no guessing, all parameters are certainly know - and please note the condition: the presence of /etc/mkinitrd.conf config file, which controls every parameter usable with mkinitrd.

Basically, the script executes an mundane task, being controlled by known parameters put in the package (the kernel version) a convenient named initrd image file and the parameters put in a config file. Once properly tuned the /etc/mkinitrd.conf config file, the install script from the kernel package will generate a certain kind of initrd.

Like can be noted, the system makes no decisions - it just execute certain repetitive tasks at certain times, in a certain configured ways. This is what I call "automation", and in this case is "automatically generating initrds"

However, many times the Slackers when talking about "automation" in fact they understand "auto-magic" and pursue it or rise against it. And there we arrive at the second way of handling automatically the initrds.

2. to make the system to execute certain repetitive tasks, automatically computing the requirements specific to the system. In other words, it's about delegating the decision management to system.

This delegation of decisions to automated scripts is what I call "auto-magic" and a good example of it this "geninitrd"

In fact, this script is a wrapper script to a wrapper script to a script named "mkinitrd_command_generator.sh"

In the end, the acuracy of "geninitrd" depends on how well do its job the "mkinitrd_command_generator.sh" .

Now, what's "mkinitrd_command_generator.sh" ? It's a very useful script for generating various commands related to initrds generation, or even a personalized template for /etc/mkinitrd.conf

BUT, the issue of all "auto-magic" solutions are that they are not smart enough to proper do their job without user intervention. And this "geninitrd" is an practical example for this claim - meanwhile showing you also what /etc/mkinitrd.conf contains.

So, executing "geninitrd" in this system will generate an initrd using a "config" as guessed by this command:
As well, I can do this:
Then, to generate an initrd I just have to call "mkinitrd"
So, some fancy automation, yes?

BUT, as with any auto-magic solution, which makes decisions on behalf of users, there are some big issues with this kind of initrd generation.

First of all, the generated initrd is put always in the path: /boot/initrd.gz and this is very very very bad. Because it will override any previous initrd, presumable made for another kernel version. So, even IF the user like a smart guy, install parallel the new kernel, instead of a ridiculous upgrade, the initrd for this old kernel will be overridden.

I do not know others, but I for one, I believe that it's a very very bad design decision. The initrd names should be ALWAYS properly versioned, as discovered 20 years ago by the other major Linux distributions.

Secondly, do you see in the list of kernel modules the VFAT module? NOPE? This means very bad news, because IF I will use this "geninitrd" command and I will forgot to properly update the EFI files before reboot on a future kernel upgrade, I will end exactly in the issue described by this very thread: impossible to mount /boot/efi.

Yet, even when I have generated that config, the VFAT module was loaded and in use:
I for one, I can't understand how is possible someone to think that it's OK to cut the users support for accessing the FAT partitions, hence to make impossibile to mounting the EFI partitions, considering that it's still promoted the requirement to copy files to it, even on a system damaged by a failed update.

Long story short, I believe that automating the repetitive tasks is good, while leaving the tools to make decisions is very bad, and that "auto-magic" is bad, being a drive to system damages.

And I believe sincerely that the management of kernel packages and bootloaders on Slackware is plagued by so many huge design issues (and errors prone logics) that makes me wonder how the heck it still boot...

Or maybe @elcore is right, and this ridiculous bad management of system boot is used as a "filter" against "help vampires" - who boots Slackware for 10 kernel upgrades gets the badge of Slacker?

2 members found this post helpful.

Let me just note I didn't personally call anyone a "help vampire", and I don't have and didn't have any problems at all with kernel upgrades.
My only problem, and only reason to complain about your proposed solutions becoming Slackware solutions, is condescending software which tries to tell me what to do.
With this noted, I think it'd be best if kernel upgrades simply moved files around, and not enforce a complicated infrastructure like GRUB2 just to work around a FAT32 limitation.

2 members found this post helpful.

Agreed, but I think it is up to the user to implement the solution that works locally.

I do question the suggested approach.
That will always return false here. I do not have one. How do you expect a naive user to be aware of, and able to, prepare a "properly tuned the /etc/mkinitrd.conf config file"?

Yes, mkinitrd_command_generator.sh is a very useful script, but it does suggest suggest a number of modules that I do not need. Yes. they are mostly hid* modules that do no harm and ensure that a wide range of hardware is supported, but they are not necessary.
Then there is the use case of transferring a Slackware install to a USB stick, that will likely require additional modules to successfully boot.
Any solution must allow for the user to be able to manually create an initrd.

For a naive user making a new initrd after doing an upgrade, this is very very good. It means the initrd matches the current state of the system, there is no build up of stale files and no configuration changes required. The "user like a smart guy" knows how to handle this.

If the user booted the system prior to update, then the running kernel is capable of handling the FAT file system. Yes, kernel upgrades make significant changes, but while the system is running then all necessary functionality is present to successfully complete the upgrade.
If a user fails to complete all the steps in an upgrade, then the recovery procedures are well documented. Yes, it is a hard lesson, but we all seem to get through it. I still do not see a satisfactory alternative.

1 members found this post helpful.

But surely it wouldn't cost anything to put the vfat module automatically into the mkinitrd generation script now that most computers have an EFI system partition that is required for successful booting.

3 members found this post helpful.

Excuse me? It's UP TO THE USER to implement a fundamental logic of booting Slackware Linux? Seriously?

So, you believe that the Slackware is ONLY for GURUS? If that's the truth, is no wonder that you can count the Slackers like the penguins at the North Pole.

No, Sir! That should and must be a task done by Mr. Volkerding and his Slackware, not by the user!

And how the heck can the user automatize the initrd generation when upgrading the stock kernel packages with "upgradepkg kernel-*.t?z" ? The user have no way, because he has no hook where to plug in his custom scripting. NOTHING. And let's do not talk about the fact that the kernel and its modulues are in different packages.

So, what you say is admirable, yet your words are just some slogan, because it's not possible to do this unless the user tamper with the kernel packages.

Unfortunately, you are right. There is no "/etc/mkinitrd.conf" in a fresh installation of Slackware, and this I consider another BIG design issue of Slackware.

Honestly, I believe that an initial config file like this should be generated by the Slackware installer, after all it uses mkinitrd_command_generator.sh to generate an (initial) initrd, so as well it could generate the config file too.

However, like I said already, what I want is to automatize tasks, not to make the system to take decisions on my behalf (what I call auto-magic) and that's why unfortunately this "/etc/mkinitrd.conf" is a requirement, because it contains the custom/personalized parameters/configuration passed to mkinitrd.

In a Perfect World, where our BDFL will not threat the initrd generation with superficiality, I guess that the rookies will learn fast how to tune this "/etc/mkinitrd.conf" which they will find on system after installation. Until then, we should teach them to do initially:
I do not contest that a "/etc/mkinitrd.conf" generated by "mkinitrd_command_generator.sh" may need to be tuned. However, not including by default the VFAT modules was demonstrated by many users adventures to be a BIG design error, because the user can arrive to situation to be impossible to mount the EFI partition.

I do not see what I say is in contradiction with manual generation of an initrd. Always the user can call mkinitrd with what parameters he likes.

About what matching the current state of the system you talk? Using always the name "/boot/initrd.gz" for the incoming initrd may just replace the currently working initrd and putting the system in a damaged state.

I believe that's the part that the Slackware GURUS does NOT understand (or refuse to) : DO NOT DESTROY THE WORKING BOOT SETUP WHEN UPGRADING THE KERNEL. All your "solutions" do this, and the result is what could be seen easily: the people arrive to failed boots.

NO, Sir! The initrd names should be versioned, as no files to be overridden IF we care to preserve a consistency of system boot.

In fact, the practice says that IF you do not mount the /boot/efi partition (which is FAT32 or FAT16) before a kernel upgrade, even the current kernel has a functional support for VFAT, you can NOT mount anymore AFTER the kernel upgrade, because the current kernel modules was removed by upgrade - including the VFAT and FAT modules.

This removal of modules of current running kernel when doing an upgrade of kernel packages, it's what I believe that's another BIG design error. Because again, the system relies on "the monkey to hit the green button when sees the banana"

No offense intended to anyone, BUT seems like these user failures are often generated by the design issues from Slackware.

I for one, I believe that's better to fix them instead of continuing to wasting people time.

1 members found this post helpful.

Exactly, Mrs. Hazel!

Or at least to put on what mkinitrd_command_generator.sh generates as output.

But, they do NOT do this obvious thing, leaving "at user consideration" probably - what user usually discovers that he needs the VFAT modules after hitting an issue like described by this very thread.

2 members found this post helpful.

@LuckyCyborg - regarding your post #64: thank you for this! I think you have highlighted an important distinction between automation and, as you say, "auto-magic". You have managed to make me think about some of this stuff in a different way, so well done :-)

Regarding the naming of /boot/initrd.gz: I agree that when creating a new initrd it should have a versioned name, but that is only in the /boot directory. The actual initrd that gets used by the UEFI is the one copied to the EFI partition. If this one gets renamed, then the elilo.conf file needs to be edited to refer to it, which adds another point of failure if the user forgets.

I believe an improvement would be to keep one set of kernel/modules/initrd as a backup (probably the original install ones for that Slackware version) and then install updated kernels/modules/initrds over each other as happens currently. This way elilo.conf can always refer to vmlinuz{,.backup} and initrd{,backup}.gz

Seriously, it's UP TO THE USER to implement a fundamental logic of automatically generating a new initrd.

This thread started with the user using 'slackpkg'. 'upgradepkg' is a different tool. As i do not use "/etc/mkinitrd.conf", then all I need to do is update the kernel version in the command stored in "/boot/initrd-tree/command_line" and run it. That file becomes available to a user who switches to the generic kernel with an initrd after a Slackware install.

Properly handled, using slackpkg to upgrade a kernel will never destroy a working boot. If you get a message:
you are expected to take notice. Ignoring it is akin to turning off your computer when Windows is telling you not to do so.

2 members found this post helpful.

That's amazing! I had no idea a file like that existed. I have been running Patrick's help script by hand each time I had to make an initrd, when actually all I needed to do was edit a stored line.

It's new as of Slackware 15.0, I think--a welcome addition I say.

No, I used in 14.2 on a laptop that the mkinitrd_generator wouldn’t get right. There is a thread somewhere on here with how to set it so the correct kernel will be used with updates. If I can find it I’ll post it. Maybe the one that came up with the edit will chime in.

This thread & the embedded links have lots to say about the kernel reference in "/boot/initrd-tree/command_line" when generating a initrd.

https://www.linuxquestions.org/quest...rd-4175628620/

Hope that helps.

1 members found this post helpful.