1
0
Fork 0
mirror of git://slackware.nl/current.git synced 2025-02-07 20:46:40 +01:00
slackware-current/testing/source/mkinitrd/README.initrd

113 lines
4.1 KiB
Text
Raw Normal View History

Thu Jul 25 02:39:18 UTC 2024 Well folks, we have some more interesting stuff in /testing now. Our good friend LuckyCyborg posted a while back about our trials with GRUB2, and that we were banging our heads against a wall for no reason trying to bend GRUB2 with our 09_slackware_linux grub.d script instead of changing our kernel/initrd naming scheme to vmlinux-6.10.1-generic and initrd-6.10.1-generic.img. And, as is often the case, our friend is exactly correct. Once we stopped trying to swim against the current, GRUB2 started behaving as it should. The updates in /testing change the kernel naming scheme thusly, and modify the geninitrd script in the mkinitrd package to also use this naming scheme. And, of course, 09_slackware_linux is removed from GRUB2, and the 10_linux script is only lightly modified. Because lilo and elilo work with the symlinks to the kernel and initrd, they shouldn't care anout this change. We've probably got 6.9.11 coming tomorrow. Unless I hear that I should stop the presses on this change, it's likely that those kernels will be updated using the new naming scheme and the mkinitrd and grub updates will be moved into the main tree from /testing. We'll stick with 6.9 in the main tree for now because I'm still encountering suspend failure with the 6.10 kernel here. Enjoy! :-) a/kernel-firmware-20240723_b37d247-noarch-1.txz: Upgraded. ap/mpg123-1.32.6-x86_64-2.txz: Rebuilt. l/libxml2-2.13.3-x86_64-1.txz: Upgraded. This update fixes a security issue: Fix XXE protection in downstream code. For more information, see: https://www.cve.org/CVERecord?id=CVE-2024-40896 (* Security fix *) l/mozilla-nss-3.102.1-x86_64-1.txz: Upgraded. l/nodejs-20.16.0-x86_64-1.txz: Upgraded. l/python-importlib_metadata-8.2.0-x86_64-1.txz: Upgraded. l/v4l-utils-1.28.1-x86_64-1.txz: Upgraded. n/c-ares-1.32.3-x86_64-1.txz: Upgraded. n/curl-8.9.0-x86_64-1.txz: Upgraded. n/htdig-3.2.0b6-x86_64-10.txz: Rebuilt. Patch XSS vulnerability. Thanks to jayjwa. Get this out of cgi-bin. Thanks to LuckyCyborg. For more information, see: https://www.cve.org/CVERecord?id=CVE-2007-6110 (* Security fix *) n/libtirpc-1.3.5-x86_64-1.txz: Upgraded. extra/fltk/fltk-1.3.9-x86_64-2.txz: Rebuilt. extra/tigervnc/tigervnc-1.13.1-x86_64-6.txz: Rebuilt. Not sure why 1.14.0 isn't compiling, but we'll rebuild this for now. testing/packages/grub-2.12-x86_64-12.txz: Upgraded. Remove 09_slackware_linux. 10_linux: don't rename Slackware ;-) This should configure the renamed kernel/initrd perfectly. Perhaps 10_linux should no longer accept initrd.gz as a valid name? For now it is accepted to avoid disrupting existing workflows. testing/packages/kernel-generic-6.10.1-x86_64-1.txz: Upgraded. testing/packages/kernel-headers-6.10.1-x86-1.txz: Upgraded. testing/packages/kernel-huge-6.10.1-x86_64-1.txz: Upgraded. testing/packages/kernel-modules-6.10.1-x86_64-1.txz: Upgraded. testing/packages/kernel-source-6.10.1-noarch-1.txz: Upgraded. testing/packages/mkinitrd-1.4.11-x86_64-35.txz: Upgraded. geninitrd: create initrd with initrd-version-name.img filename. Make compat symlinks by default. Always add LVM (I've seen it mistakenly skipped... if we can get to the bottom of that then we'll stop always adding it) Add /etc/default/geninitrd for configuration.
2024-07-25 02:39:18 +00:00
Slackware initrd mini HOWTO
by Patrick Volkerding, volkerdi@slackware.com
@DATE@
This document describes how to create and install an initrd, which may be
required to use some features of the kernel. Also see "man mkinitrd".
1. What is an initrd?
2. Why do I need an initrd?
3. How do I build the initrd?
4. Now that I've built an initrd, how do I use it?
1. What is an initrd?
Initrd stands for "initial ramdisk". An initial ramdisk is a very small
Linux filesystem that is loaded into RAM and mounted as the kernel boots,
and before the main root filesystem is mounted.
2. Why do I need an initrd?
The usual reason to use an initrd is because you need to load kernel
modules before mounting the root partition. Usually these modules are
required to support the filesystem used by the root partition (ext3,
reiserfs, xfs), or perhaps the controller that the hard drive is attached
to (SCSI, RAID, etc). Essentially, there are so many different options
available in modern Linux kernels that it isn't practical to try to ship
many different kernels to try to cover everyone's needs. It's a lot more
flexible to ship a generic kernel and a set of kernel modules for it.
3. How do I build the initrd?
The easiest way to make the initrd is to use the mkinitrd script included
in Slackware's mkinitrd package. We'll walk through the process of
upgrading to the generic @KERNEL_VERSION@ Linux kernel using the packages
found in Slackware's slackware/a/ directory.
First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):
installpkg kernel-generic-@KERNEL_VERSION@-@ARCH@-@BUILD@.tgz
installpkg kernel-modules-@KERNEL_VERSION@-@ARCH@-@BUILD@.tgz
installpkg mkinitrd-@MKINITRD_VERSION@-@ARCH@-@BUILD@.tgz
Change into the /boot directory:
cd /boot
Now you'll want to run "mkinitrd". I'm using ext4 for my root
filesystem, and since mkinitrd should figure out any other modules
it requires, I shouldn't need to specify any others:
mkinitrd -c -k @KERNEL_VERSION@ -m ext4
This should do two things. First, it will create a directory
/boot/initrd-tree containing the initrd's filesystem. Then it will
create an initrd (/boot/initrd.gz) from this tree. If you wanted to,
you could make some additional changes in /boot/initrd-tree/ and
then run mkinitrd again without options to rebuild the image. That's
optional, though, and only advanced users will need to think about that.
Here's another example: Build an initrd image using Linux @KERNEL_VERSION@
kernel modules for a system with an ext3 root partition on /dev/sdb3:
mkinitrd -c -k @KERNEL_VERSION@ -m ext3 -f ext3 -r /dev/sdb3
4. Now that I've built an initrd, how do I use it?
Now that you've got an initrd (/boot/initrd.gz), you'll want to load
it along with the kernel at boot time. If you use LILO for your boot
loader you'll need to edit /etc/lilo.conf and add a line to load the
initrd. Here's an example section of lilo.conf showing how this is
done:
# Linux bootable partition config begins
image = /boot/vmlinuz-@KERNEL_VERSION@-generic
initrd = /boot/initrd.gz
root = /dev/sda6
label = @LILO_KERNEL_NAME@
read-only
# Linux bootable partition config ends
The initrd is loaded by the "initrd = /boot/initrd.gz" line.
Just add the line right below the line for the kernel image you use.
Save the file, and then run LILO again ('lilo' at the command line).
You'll need to run lilo every time you edit lilo.conf or rebuild the
initrd.
Other bootloaders such as syslinux also support the use of an initrd.
See the documentation for those programs for details on using an
initrd with them.
Some, such as GRUB, require the initrd to be named similarly to the
kernel. So, for this kernel:
/boot/vmlinuz-@KERNEL_VERSION@-generic
You would want to rename your initrd to this:
/boot/initrd-@KERNEL_VERSION@-generic.img
In fact, if you use the geninitrd script to make your initrd (which it
will pretty much do automatically for the generic kernel) it will name
it this way, and will make a compatibilty symlink initrd.gz.
---------
Have fun!