SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Re mkinitrd, as evidenced by the patches and such here, you see that it's not as trivial as you'd like :-) The patch has to be transparent to the user, i.e. if the user doesn't intentionally tell mkinitrd to add the kernel version string, then it has to output /boot/initrd.gz. The patch has to take into account that KERNEL_VERSION isn't actually set /sbin/mkinitrd is running, hence editing /etc/mkinitrd.conf isn't sufficient (and no, adding the VERSION string to /etc/mkinitrd.conf isn't a solution). If I have to edit something every time I run mkinitrd, then it isn't a solution. In other words, I want to continue my usage of "mkinitrd -c -k $version -F" and get out "/boot/initrd-$version.gz"
As I said, I gave up on it whenever I last looked at it and moved on to other problems. I'd love to see someone come up with a simple solution (I'd not be surprised if I overlooked it - it happens more than I'd like to admit)... After thinking a bit more about it (and without looking back at the mkinitrd script), I'd like to think that the most elegant solution is another variable in /etc/mkinitrd.conf, e.g. "APPEND_KVER" that /sbin/mkinitrd checks for and writes out /boot/initrd-${KERNEL_VERSION}.gz if APPEND_KVER=1 -- it seems really simple now, but maybe not; either way, if someone wants some ChangeLog mention (assuming Pat accepts the idea), then have a go at it.
Even if that did work, it still wouldn't be ideal - there's no expectation (nor should there be) that I name my custom kernels as /boot/vmlinuz-generic-$version or create a symlink to /boot/vmlinuz-generic. Never mind that there would be another issue on 32bit :-)
Even if that did work, it still wouldn't be ideal - there's no expectation (nor should there be) that I name my custom kernels as /boot/vmlinuz-generic-$version or create a symlink to /boot/vmlinuz-generic. Never mind that there would be another issue on 32bit :-)
Just an idea. The patch at the end of this post allows you to specify a template (on the command line or in mkinitrd.conf) for the output initrd name. This template can contains tags which are resolved at runtime. Currently, the tags %KVER% and %SLACKVER% are supported.
Example :
Code:
$ mkinitrd -o /tmp/initrd-%KVER%.gz
33751 blocks
/tmp/initrd-4.4.75.gz created.
Be sure to run lilo again if you use it.
$ mkinitrd -o /tmp/initrd-%KVER%_%SLACKVER%.gz
33751 blocks
/tmp/initrd-4.4.75_14.2.gz created.
Be sure to run lilo again if you use it.
$ cat /etc/mkinitrd.conf | grep OUTPUT_IMAGE
OUTPUT_IMAGE=/boot/%KVER%-initrd-generic-%SLACKVER%.gz
$ mkinitrd -k 4.4.75-custom -F
33751 blocks
/boot/4.4.75-custom-initrd-generic-14.2.gz created.
Be sure to run lilo again if you use it.
$ OUTPUT_IMAGE=/tmp/my-initrd-for-%KVER%-on-slackware-%SLACKVER%.gz ./mkinitrd -k 4.4.75
33751 blocks
/tmp/my-initrd-for-4.4.75-on-slackware-14.2.gz created.
Be sure to run lilo again if you use it.
Here is the patch:
Code:
--- mkinitrd.orig 2017-07-11 10:24:41.580285638 +0200
+++ mkinitrd 2017-07-11 11:26:00.768449804 +0200
@@ -261,7 +261,19 @@
cp -a /etc/modprobe.d $SOURCE_TREE/etc
cp -a /lib/modprobe.d $SOURCE_TREE/lib/
}
-
+
+# Normalize the string $1 by replacing occurences of
+# recognized tags by their current values.
+#
+# this version take the following tags into account:
+# %KVER% (kernel version)
+# %SLACKVER% (slackware version)
+#
+function normalize_string() {
+ echo "$1" | sed -e "s?%KVER%?${KERNEL_VERSION}?g" \
+ -e "s?%SLACKVER%?$(cat /etc/slackware-version|cut -f2 -d" ")?g"
+}
+
# If --help is given, print_usage and exit:
if echo $* | grep -wq '\--help' ; then
print_usage
@@ -285,7 +297,7 @@
# Default actions without options:
if [ -z "$1" ]; then
# We need a sensible default for this special case:
- OUTPUT_IMAGE=${OUTPUT_IMAGE:-/boot/initrd.gz}
+ OUTPUT_IMAGE=$(normalize_string ${OUTPUT_IMAGE:-/boot/initrd.gz})
# If the output tree doesn't exist, create it and then exit:
if [ ! -d $SOURCE_TREE ]; then
echo "Nothing found at location $SOURCE_TREE, so we will create an"
@@ -349,7 +361,7 @@
;;
-o)
# canonicalize filename:
- OUTPUT_IMAGE="$(readlink -m $2)"
+ OUTPUT_IMAGE="$(readlink -m $(normalize_string $2))"
shift 2
;;
-r)
@@ -465,7 +477,7 @@
fi
# If no OUTPUT_IMAGE was specified, read it from the SOURCE_TREE if possible:
-OUTPUT_IMAGE=${OUTPUT_IMAGE:-"$(cat $SOURCE_TREE/initrd-name)"}
+OUTPUT_IMAGE=$(normalize_string ${OUTPUT_IMAGE:-"$(cat $SOURCE_TREE/initrd-name)"})
# If we still have no value, apply the default:
OUTPUT_IMAGE=${OUTPUT_IMAGE:-"/boot/initrd.gz"}
# Finally, write the image name into the SOURCE_TREE:
--
SeB
Last edited by phenixia2003; 07-11-2017 at 07:44 AM.
Reason: typo
RE: mkinitrd
Please keep in mind that 32-bit Slackware normal generic kernel has x.x.x-smp version and kernel without -smp is not SMP kernel (only one core).
Its harmless, just hit 'n'. Or if it really bugs you edit your local slackpkg to not print that.
It is NOT harmless. This thing can create to a rookie the false impression that he updated the bootloader, when he wasn't. See this thread, for example:
And NO, does not bother me, rest assured. I do never used slackpkg, in fact.
BUT, instead I suggest to treat the same all bootloaders used by Slackware.
Then, let's say: or we remove that troubling thing, or we should do a shiny auto-detection of bootloader type and do the same for: LILO, ELILO, SYSLINUX, EXTLINUX, GRUB and GRUB2.
Be my guest to find out which bootloader was used for real.
Because it might touch files that are directly related to booting.
--
Best regards,
Andrzej Telszewski
Look, we are NOT the RHEL, where they stuck with their shiny GRUB(2), instead we are Slackware and we use tons of bootloaders.
IF you believe that we can handle all of them, and their particular usage, "after touching files related to booting", be my guest!
BUT, again: a package updater messing with the bootloader is a thing which is not on Slackware way, at least in my opinion, as life-long Slackware user.
Maybe you use this LILO (me too), maybe you are skilled to know when it ask a true question (me too), but NOT all Slackware users are skilled like us, and NOT all of them use LILO, specially those who build a relatively modern box. The UEFI is all the way and they go ELILO or GRUB.
I do not talk here about those who try to boot Slackware from a write protected SDCARD...
Last edited by Darth Vader; 07-11-2017 at 01:54 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.