About the ability to run custom commands from initrd's init
An idea exposed by me in another thread, which I think is worth more attention: I talk about customizing the initrd, because I think there's a huge lack on the infrastructure of initrd used by Slackware: the hooks for it.
Or at least, a way to merge a small custom script at the near end of "/boot/initrd-tree/init" The single way I found today, even on slackware-current, to make my customization to survive to a clean generation of the initrd, is to modify this "/init" script within "/usr/share/mkinitrd/initrd-tree.tar.gz" then to careful watch if an upgrade of package will overide it or not. Code:
... I think that could be resolved this by modifying the /sbin/mkinitrd to look for a script named "/boot/initrd.sh" and if it exists, its content to be merged or injected using sed or whatever, in a certain place from "/boot/initrd-tree/init" before it to be compressed. Please note that today any customization of "/boot/initrd-tree/init" is gone if the user generates cleanly another initrd. |
How does this relate to using /etc/mkinitrd.conf to customize the /sbin/mkinitrd command? There are man pages for both mkinitrd and mkinitrd.conf as well as more info can be found in the /etc/mkinitrd.conf.sample file.
|
Quote:
Code:
mount -t ext4 /dev/sda3 /mnt/usr There are many options given, but none for adding custom scripts or commands on initrd. |
Quote:
|
Quote:
Unless using "-C" option, the initrd will grown and grown, and forever grown, hosting modules for multiple kernels from the past and multiple variants of libraries. And what if the user updates the mkinitrd package itself? I would like to note that to offer the ability to run custom commands on initrd, some of the other distributions uses the concept of "hooks", like described there for Arch Linux: https://wiki.archlinux.org/index.php/Mkinitcpio#HOOKS As another random example, Fedora uses instead "modules", like we see there: https://git.kernel.org/pub/scm/boot/...tree/modules.d Also the Debian uses "hooks", like they told there: https://manpages.debian.org/jessie/i...l#HOOK_SCRIPTS Howver, what I ask is not a full implementation of those initrd "hooks" or "modules", but just the ability to define somewhere a script and/or custom commands which could be integrated in initrd, no mater if it is is clean generated or not. |
I guess that it is hard to notice the disadvantages of the monolithic setup used for initrd by Slackware, unless you need to customize it in a daily basis.
Regarding the customization of the boot script from initrd, I have an even more generic idea than the OP: the mkinird to check for the file "/etc/initrd.d/init.sh" and if it exists, to copy it on the place of "/boot/initrd-tree/init" before to generate the initrd. This way the user have the full control over his custom init script from initrd, no matter what combination of options he use, with no fear that it will be overridden in a way or other. |
Too bad then. But you can create your own solution of course.
|
edit: nevermind. I was just repeating what eric said earlier. I guess I should have read all the thread before responding.
|
So for grins and giggles I wrote the following script and txt file to address the OP's suggestion. It works on my system and creates an initrd.gz that contains a modified init file based on a separate txt file. It should be run as root and on a vanilla Slackware installation is in the standard path.
This is the script file /usr/local/bin/mkinitrd.sh to generate the initrd.gz with the modified init file. Just replace the "# [...]" lines (2 of them) with your preferred mkinitrd commands. Code:
#!/bin/sh Code:
########## Have fun! |
About the ability to run custom commands from initrd's init
Reading this I was wondering if that could be integrated upstream, with an mkinitrd.conf option...
|
This seems like a nice thread to drop in a little suggestion.
I customized my /etc/mkinitrd.conf concerning loaded modules, but I found no documented default for KERNEL_VERSION (-k on the mkinitrd command line). So I scripted it into my 64-bit desktop's mkinitrd.conf: Code:
KERNEL_VERSION="$(ls -1 /boot/vm*generic* | tail -n 1 | sed 's/.*generic-//')" Code:
# mkinitrd -F For my 32-bit netbook, it's slightly different: Code:
KERNEL_VERSION="$(ls -1 /boot/vm*generic* | tail -n 1 | sed 's/.*generic-smp//')" Side note: my sysadmin experience (i.e. how many ways can I mess up my desktop?) says "keep the working boot files until you can replace them with minimal chance of disaster." Since I use LILO to boot, I leave the old files in place until all the new files are ready. Then, just running "lilo" takes a few seconds to re-configure the file mappings for /boot/kernel-generic and /boot/initrd.gz. By keeping a previous /boot/kernel-huge around, I have that escape route to finish a proper kernel upgrade in the event of a power failure or other catastrophic system crash. |
Quote:
Code:
ls -1 /boot/vm*generic* Code:
KERNEL_VERSION="$(ls -1 /boot/vm*generic-* | sort -V | tail -n 1 | sed 's/.*generic-//')" Code:
KERNEL_VERSION="$(ls -1 /boot/vm*generic-* | sort -V | tail -n 1 | rev | cut -d- -f1 | rev)" |
Quote:
Code:
readlink -f /boot/vmlinuz-generic| sed 's/.*generic-//' |
Quote:
You're also supposed to copy your system.map and kernel config to /boot/, but I never do. I also never change my /usr/src/linux/ symlink to point to the current kernel... I used to, but it didn't break anything when I stopped doing it, so again, it is a step (or several) that I just don't worry about when compiling my own kernels. For me, it is one extra step that I just don't worry about. However, I do realize that my setup is probably not the standard setup. I wasn't posting to get gus3 to change his command, just providing a data point for them to consider when using their command. I realize that with my non-standard setup that not all scripts will work as intended (which is why I don't use eliloconfig, since it overwrites my elilo.conf file). |
Quote:
I still use one to point to my local copy of linux-stable.git. |
All times are GMT -5. The time now is 10:17 AM. |