mirror of
git://slackware.nl/current.git
synced 2024-12-27 09:59:16 +01:00
05ec45c9c9
a/kernel-firmware-20231024_4ee0175-noarch-1.txz: Upgraded.
a/kernel-generic-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-huge-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-modules-6.1.60-x86_64-1.txz: Upgraded.
a/shadow-4.14.1-x86_64-1.txz: Upgraded.
d/kernel-headers-6.1.60-x86-1.txz: Upgraded.
k/kernel-source-6.1.60-noarch-1.txz: Upgraded.
Hey folks, if you've been following LQ you know I've talked before about
dropping the huge kernel and moving the distribution to use only the generic
kernel plus an initrd. After mulling this over for a few months, I think I
was looking at the problem in the wrong way. First of all, it's clear that
some Slackware users have been using the huge kernel all along, without an
initrd, and are (to say the least) unhappy about the prospect of a new
requirement to start using one. I've been recommending the generic kernel for
some time, and a major reason is that we've been using the same set of kernel
modules with two slightly different kernels. Because of this, there have
always been a few (generally seldom used) kernel modules that won't load into
the huge kernel. These are things that aren't built into the huge kernel, but
because of a difference in some kernel module dependency, they won't load.
The conclusion that I've come to here is that rather than drop the huge
kernel, or slap a LOCALVERSION on it and provide a whole duplicate tree of
kernel modules especially for the huge kernel, it would be better to make the
generic kernel more huge, and minimize the differences between the two kernel
configs.
That's what I've done here.
Shown below are the differences between the previous generic kernel config
and the one shipping in this update. You'll notice that most of the popular
filesystems are built in. At this point the main difference it that the huge
kernel has a couple of dozen SCSI drivers built into it. The modules for those
drivers won't load into the huge kernel, but they're fully built in so that
doesn't matter. If you find any other modules that will not load into the huge
kernel, please make a note about it on LQ and I'll see what can be done.
So, tl;dr - what does this change mean?
Unless your root device is on SCSI, if you were able to use the huge kernel
without an initrd previously, you should now be able to use the generic
kernel without an initrd. The kernel is a bit bigger, but we probably have
enough RAM these days that it won't make a difference.
Enjoy! :-)
-CIFS_SMB_DIRECT n
9P_FS m -> y
9P_FSCACHE n -> y
BTRFS_FS m -> y
CIFS m -> y
CRYPTO_CMAC m -> y
CRYPTO_CRC32 m -> y
CRYPTO_XXHASH m -> y
CRYPTO_ZSTD m -> y
EFIVAR_FS m -> y
EXFAT_FS m -> y
EXT2_FS m -> y
EXT3_FS m -> y
EXT4_FS m -> y
F2FS_FS m -> y
FAILOVER m -> y
FAT_FS m -> y
FSCACHE m -> y
FS_ENCRYPTION_ALGS m -> y
FS_MBCACHE m -> y
HW_RANDOM_VIRTIO m -> y
ISO9660_FS m -> y
JBD2 m -> y
JFS_FS m -> y
LZ4HC_COMPRESS m -> y
LZ4_COMPRESS m -> y
MSDOS_FS m -> y
NETFS_SUPPORT m -> y
NET_9P m -> y
NET_9P_FD m -> y
NET_9P_VIRTIO m -> y
NET_FAILOVER m -> y
NFSD m -> y
NLS_CODEPAGE_437 m -> y
NTFS3_FS m -> y
NTFS_FS m -> y
PSTORE_LZ4_COMPRESS n -> m
PSTORE_LZO_COMPRESS n -> m
PSTORE_ZSTD_COMPRESS n -> y
QFMT_V2 m -> y
QUOTA_TREE m -> y
REISERFS_FS m -> y
RPCSEC_GSS_KRB5 m -> y
SMBFS m -> y
SQUASHFS m -> y
UDF_FS m -> y
VFAT_FS m -> y
VIRTIO_BALLOON m -> y
VIRTIO_BLK m -> y
VIRTIO_CONSOLE m -> y
VIRTIO_INPUT m -> y
VIRTIO_MMIO m -> y
VIRTIO_NET m -> y
VIRTIO_PCI m -> y
VIRTIO_PCI_LIB m -> y
VIRTIO_PCI_LIB_LEGACY m -> y
VIRTIO_PMEM m -> y
XFS_FS m -> y
ZONEFS_FS n -> m
ZSTD_COMPRESS m -> y
+NFS_FSCACHE y
+PSTORE_LZ4_COMPRESS_DEFAULT n
+PSTORE_LZO_COMPRESS_DEFAULT n
+PSTORE_ZSTD_COMPRESS_DEFAULT n
kde/plasma-workspace-5.27.9.1-x86_64-1.txz: Upgraded.
l/glib2-2.78.1-x86_64-1.txz: Upgraded.
l/netpbm-11.04.03-x86_64-1.txz: Upgraded.
l/newt-0.52.24-x86_64-1.txz: Upgraded.
n/gpgme-1.23.0-x86_64-1.txz: Upgraded.
n/p11-kit-0.25.1-x86_64-1.txz: Upgraded.
n/php-8.2.12-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.php.net/ChangeLog-8.php#8.2.12
x/xorg-server-21.1.9-x86_64-1.txz: Upgraded.
This update fixes security issues:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
Use-after-free bug in DestroyWindow.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
https://www.cve.org/CVERecord?id=CVE-2023-5380
(* Security fix *)
x/xorg-server-xephyr-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xnest-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xvfb-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xwayland-23.2.2-x86_64-1.txz: Upgraded.
This update fixes a security issue:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
(* Security fix *)
xap/mozilla-thunderbird-115.4.1-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/thunderbird/115.4.1/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2023-47/
https://www.cve.org/CVERecord?id=CVE-2023-5721
https://www.cve.org/CVERecord?id=CVE-2023-5732
https://www.cve.org/CVERecord?id=CVE-2023-5724
https://www.cve.org/CVERecord?id=CVE-2023-5725
https://www.cve.org/CVERecord?id=CVE-2023-5726
https://www.cve.org/CVERecord?id=CVE-2023-5727
https://www.cve.org/CVERecord?id=CVE-2023-5728
https://www.cve.org/CVERecord?id=CVE-2023-5730
(* Security fix *)
xfce/thunar-4.18.8-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
usb-and-pxe-installers/usbboot.img: Rebuilt.
99 lines
3.5 KiB
Text
99 lines
3.5 KiB
Text
|
|
Slackware initrd mini HOWTO
|
|
by Patrick Volkerding, volkerdi@slackware.com
|
|
Thu Oct 26 19:07:45 UTC 2023
|
|
|
|
This document describes how to create and install an initrd, which may be
|
|
required to use the 4.x kernel. Also see "man mkinitrd".
|
|
|
|
1. What is an initrd?
|
|
2. Why to 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, ext4,
|
|
btrfs, 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 6.1.60 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-6.1.60-x86_64-1.txz
|
|
installpkg kernel-modules-6.1.60-x86_64-1.txz
|
|
installpkg mkinitrd-1.4.11-x86_64-33.txz
|
|
|
|
Change into the /boot directory:
|
|
|
|
cd /boot
|
|
|
|
Now you'll want to run "mkinitrd". I'm using ext4 for my root filesystem,
|
|
and since the disk controller requires no special support the ext4 module
|
|
will be the only one I need to load:
|
|
|
|
mkinitrd -c -k 6.1.60 -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 6.1.60
|
|
kernel modules for a system with an ext4 root partition on /dev/sdb3:
|
|
|
|
mkinitrd -c -k 6.1.60 -m ext4 -f ext4 -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-generic
|
|
initrd = /boot/initrd.gz
|
|
root = /dev/sda6
|
|
label = Slackware
|
|
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.
|
|
|
|
|
|
---------
|
|
|
|
Have fun!
|