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.
Hmmm. I think I'd prefer an old-school jumper. I suppose a jumper could still fail, but I think it's less likely.
If the dictionary had an entry for "safe bet" it would have your post after it I've worked on surplus electronics with old school jumpers that were almost 50 years old and had severe running environments and routine changes and exactly zero have ever failed. The surface area and tension in contact is extremely robust, and easily re-tensioned if one ever did temporarily get hinky.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,119
Original Poster
Rep:
It would be nice to see this backported,
Quote:
Linus Torvalds Just Made A Big Optimization To Help Code Compilation Times On Big CPUs
Written by Michael Larabel in Linux Kernel on 8 February 2020 at 06:38 PM EST.
.......In a simplified test case written by Linus Torvalds, this patch caused the number of context switches on the test program to drop from 11 million to just 1.2 million. The consumed system time was also a tiny fraction of the original time. Reducing the number of context switches is also welcome simply for the fact of how much slower context switching performance has become on the Intel side as a result of the countless security mitigations........
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,119
Original Poster
Rep:
Year 2020, Round 12
Another batch of kernel updates has been scheduled for release Saturday afternoon, 15 February 2020, at approximately 15:00, GMT.
If no problems are found while testing the release candidates, they might be available late Friday or early Saturday (depending on your time zone).
There will be 120 patches in the 5.5.4 update, 96 in 5.4.20, 52 in 4.19.104, 173 in 4.14.171, 116 in 4.9.214 and, finally, 91 patches in the 4.4.214 update.
That's a bummer about 5.5 missing the intel patches. I had read somewhere that this might happen. Hopefully 5.6 will sort out things on my laptop with it's intel GPU.
Hopefully since it was missing critical patches that will hopefully get incorporated into 5.5, hopefully they'll then be backported to 5.4 so Intel users can function properly again.
I just updated to 5.4.20, nothing to write home about...
Then i reminded my self of that helper script i wrote a while back ago for exactly that, updating the rest of the system following an kernel update...
here goes: kernel-update.sh
Code:
#!/bin/sh
V="0.1-alpha"
echo -ne ".\n.\n.\n."
echo " BOOT UPDATER-"$V
echo "========================================"
echo "adjusting boot to upgraded kernel"
echo "NOTE: this is just a helper, ensure that all the files are"
echo "properly configured beforehand!"
echo "========================================"
for X in /usr/sbin/grub-mkconfig /sbin/mkinitrd
do
if [[ -x $X ]]
then
echo "found [$X]"
else
echo "[$X] not found, make sure it is installed."
echo "-Fatal error, exiting."
exit 2
fi
done
rk=$(uname -r)
echo "And we seem to be running on $rk kernel"
echo "========================================"
#loop over the symlinks in /boot/
for k in /boot/vmlinuz*
do
#echo $k; file -b $k
if file -b $k | grep -q "symbolic link"
then echo "we have detected an symlink, skippin the symlink"
fi
if file -b $k | grep -q "Linux kernel"
then echo "we have detected an kernel:"
s=${k#*-}
v=${s#*-}
t=${s%-*}
echo "it is an " $t "version" $v
if [ "X"$t == "Xgeneric" ]
then
echo "does the -generic we're just detected need some maintainence:"
#check if initrd is needed!
for i in /boot/initrd-$v*
do
if ( file -b $i | grep -q "data" )
then
echo "found apparently matching initrd, skipping further action!"
else
#check if mkinitrd has our kernel entry
for kv in $(grep "KERNEL_VERSION=" /etc/mkinitrd.conf | grep -v "uname" | sed "s/KERNEL_VERSION=//" | sed 's/"//g')
do
if [ "X"$kv == "X"$v ] && [ "X"$kv != "X" ]
then
echo "initrd seems to be configured already"
else
echo "editing /etc/mkinitrd.conf!"
#do it!
oldline='KERNEL_VERSION="'$kv'"'
newline='KERNEL_VERSION="'$v'"'
echo "["$oldline"]-->["$newline"]"
sed -i'.backup' "s/$oldline/$newline/" /etc/mkinitrd.conf
grep $newline /etc/mkinitrd.conf
fi
done
#we have appropriate mkintrd.conf now on
#proceed to make a initrd for the orphan -generic kernel
/sbin/mkinitrd -F
fi
done
fi
#not an -generic, no further action needed
fi
#not a krenel, but a symlink, no action needed
done
#letting grup ovedo the config file now:
/usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
what to note:
this is for grub users who use an generic kernel and have the /etc/mkinitrd script already edited and set up to the liking
example /etc/initrd.conf:
Code:
# mkinitrd.conf.sample
# See "man mkinitrd.conf" for details on the syntax of this file
#
SOURCE_TREE="/boot/initrd-tree"
CLEAR_TREE="1"
#KERNEL_VERSION="$(uname -r)"
KERNEL_VERSION="5.4.20"
OUTPUT_IMAGE="/boot/initrd-${KERNEL_VERSION}.gz"
#KEYMAP="us"
MODULE_LIST="ext4:usbhid:hid_generic:xhci-hcd"
#LUKSDEV="/dev/sda2"
#LUKSTRIM="/dev/sda2" # verify support with 'hdparm -I $dev | grep TRIM'
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/sda3"
ROOTFS="ext4"
#RESUMEDEV="/dev/sda2"
#RAID="0"
#LVM="0"
UDEV="1"
MODCONF="1"
#MICROCODE_ARCH="/boot/intel-ucode.cpio"
#WAIT="1"
this script could potentially take care of further stuff - like checking of the proper modules loaded for the used root but that would really push the line of an initial ALPHA release
Use with caution; i'd like feedback if this goes any further in your (anyone's) hands, okay?
(i set mine in /usr/local/sbin/)
Last edited by SCerovec; 02-17-2020 at 04:15 AM.
Reason: added my initrd.conf
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.