I came across a situation where I have to specify a specific feature to “mkinitrd” to make the system boot. The scripts won’t autodetect that requirement, so calling “mkinitrd” with the “-f” flag was the way to go. But what will happen on the next kernel update, or any other package that will call “mkinitrd” in the background?
This all took place on an OpenSUSE 13.1-based server, so we’re still in pre-“dracut” times and configuring the traditional way.
While “/etc/sysconfig/kernel” has “INITRD_MODULES” to specify additional modules to include into the next initrd, no such variable is to be seen for specifying features. Well, at least not in the distributed “/etc/sysconfig/kernel” file… looking into the according script file (“/lib/mkinitrd/scripts/setp-start.sh”) reveals a variable “ADDITIONAL_FEATURES” that is not explicitly initialized, and by the sound of its name is intended for just that purpose. It’s even mentioned in “/lib/mkinitrd/scripts/setup-prepare.sh” (“including the wanted module in the configuration option ADDITIONAL_FEATURES in /etc/sysconfig/initrd”), but of course that comment is misleading with regards to the file name, “/etc/sysconfig/kernel” is the one currently used.
So like with “INITRD_MODULES”, all you have to do is set “ADDITIONAL_FEATURES” in /etc/sysconfig/kernel and any future “mkinitrd” invocation will pick that up and include the features in the generated initrd, just as if you had specified it via “-f”.
## Type: string ## Description: The name of additional features to include in initrd ## Default: "" ## Command: /sbin/mkinitrd # # This variable contains the list of names of additional features to include in # the initioal ramdisk when calling "mkinitrd" # ADDITIONAL_FEATURES=""
And just to mention it: The absolutely same holds true for SLES 11 up to SLES11SP3, where the same mechanisms are used (SLES12 has turned to “dracut”, just like OpenSUSE 13.2).
This feature is probably old and forgotten (hence the misleading comment and the inconsistent variable name, missing the “INITRD_” prefix), but it’s nice, it works, and for our use case, it is definitely required.