mirror of
git://slackware.nl/current.git
synced 2024-11-16 07:48:02 +01:00
d66220bda5
a/kernel-generic-5.14.8-x86_64-1.txz: Upgraded.
a/kernel-huge-5.14.8-x86_64-1.txz: Upgraded.
a/kernel-modules-5.14.8-x86_64-1.txz: Upgraded.
ap/itstool-2.0.7-x86_64-1.txz: Upgraded.
d/kernel-headers-5.14.8-x86-1.txz: Upgraded.
k/kernel-source-5.14.8-noarch-1.txz: Upgraded.
l/libmtp-1.1.19-x86_64-1.txz: Upgraded.
n/getmail-6.18.4-x86_64-1.txz: Upgraded.
n/openssh-8.8p1-x86_64-1.txz: Upgraded.
Please note "Potentially-incompatible changes" from the release notes:
This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]
For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:
Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
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
|
|
Sun Sep 26 18:35:18 UTC 2021
|
|
|
|
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 5.14.8 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-5.14.8-x86_64-1.txz
|
|
installpkg kernel-modules-5.14.8-x86_64-1.txz
|
|
installpkg mkinitrd-1.4.11-x86_64-25.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 5.14.8 -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 5.14.8
|
|
kernel modules for a system with an ext4 root partition on /dev/sdb3:
|
|
|
|
mkinitrd -c -k 5.14.8 -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!
|