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.
I don't know if this relates to your issue. The 5.4.6 kernel has been rebuilt.
Code:
Fri Dec 27 22:54:53 UTC 2019
a/kernel-generic-5.4.6-x86_64-2.txz: Rebuilt.
a/kernel-huge-5.4.6-x86_64-2.txz: Rebuilt.
a/kernel-modules-5.4.6-x86_64-2.txz: Rebuilt.
ap/vim-8.2.0050-x86_64-1.txz: Upgraded.
d/kernel-headers-5.4.6-x86-2.txz: Rebuilt.
k/kernel-source-5.4.6-noarch-2.txz: Rebuilt.
Apparently MODULE_SIG was enabled by SECURITY_LOCKDOWN_LSM. We'll turn both
of those off to avoid needlessly tainting the kernel.
-LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY n
-LOCK_DOWN_KERNEL_FORCE_INTEGRITY n
-LOCK_DOWN_KERNEL_FORCE_NONE y
-MODULE_SIG_ALL n
-MODULE_SIG_FORCE n
-MODULE_SIG_FORMAT y
-MODULE_SIG_HASH "sha256"
-MODULE_SIG_KEY "certs/signing_key.pem"
-MODULE_SIG_SHA1 n
-MODULE_SIG_SHA224 n
-MODULE_SIG_SHA256 y
-MODULE_SIG_SHA384 n
-MODULE_SIG_SHA512 n
-SECURITY_LOCKDOWN_LSM_EARLY y
MODULE_SIG y -> n
SECURITY_LOCKDOWN_LSM y -> n
l/imagemagick-7.0.9_12-x86_64-1.txz: Upgraded.
l/libcap-2.29-x86_64-1.txz: Upgraded.
xap/vim-gvim-8.2.0050-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Rebuilt.
usb-and-pxe-installers/usbboot
I'm currenly running kernel-5.4.8 and prior since 5.4.0-rc have booted in < 10s on the Ryzen 7 3800X (X570 AMD mobo) and < 30s on a old Lenovo T510 laptop. wake/suspend is ok here as well. I suspect that there is less of an issue with the kernel but rather with the hardware.
I'll be loading current onto an NVME drive on the 3+ yr old i7-6850K X99 intel box soon. I'll report if I reproduce any kernel boot slowdowns.
I suspect that there is less of an issue with the kernel but rather with the hardware.
But something has changed with the kernel, perhaps to expose a hardware issue? My fallback kernel is 5.3.18 (self compiled) with no delay in boot but my other kernel 5.4.8 (stock -current) has the 90 second delay. This delay has been seen in every version of 5.4.x since it landed in Slackware. One solution I have found is to reboot as little as possible
I have the delay as well, on 2 different computers. But, I've been too lazy to do a kernel git bisect to find the root cause. If we really want this fixed, somebody (and I'm talking to myself here, too) should do a kernel bisect and report the problem upstream.
Is this possibly another i915 issue? If so that is getting fixes in 5.5 that should soon be absorbed into 5.4.
i915 driver here with Intel HD Graphics 620, and I haven't noticed any issues on -current (kernel 5.4.8 at present). Actually I never realized it was graphics related, but I think 5.4 has fixed the intermittent hard system locks that I used to have with the 4.19 kernel series.
i915 driver here with Intel HD Graphics 620, and I haven't noticed any issues on -current (kernel 5.4.8 at present). Actually I never realized it was graphics related, but I think 5.4 has fixed the intermittent hard system locks that I used to have with the 4.19 kernel series.
In case you want to try, and use sbotools, here is what crashes my X with -current/i915 driver(don't know which card, laptop not reachable), last tried with kernel 5.4.6:
sboinstall jack DPF-Plugins
/usr/bin/Nekobi
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Rep:
4.19.93: No delay on boot
5.3.11: Here is where it gets weird. If I use a .config from a running 4.19.93 kernel to compile the 5.3.11 kernel, there is no delay on bootup. If, however, I use the .config from a 5.4.8 kernel that is displaying this delay behavior, then the 5.3.11 kernel will also have the same delay on boot.
So just for fun, I took the .config from a 4.19.93 kernel with no boot delay, and used it to compile a 5.4.8 kernel. Reboot.
NO DELAY
I have, for a couple of days now, begun to suspect something in .config causing this. Or maybe a new feature of newer kernels, disabled by default, but enabled in the .config that comes with the kernel?
I repeat - I now have a 5.4.8 kernel that boots with NO DELAY. Prior to my recompiling it using the .config from an older 4.19.93 kernel, there was a 90 second delay.
SO I then compared .config from one the has a delay boot, and one that does not, but there were too many differences, and the differences exceeds my level of expertise cause I have no idea what I'm looking at LOL.
I can post my .config here if anyone wants to see it.
Complete shot in the dark, I don't have the kernel or any idea what I'm really talking about, but the only delays on boot I've had were always after fiddling with framebuffer settings, like having those Tuxes on top and so forth.
Maybe something like that snuck in during the upgrade? Some new configuration, perhaps?
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Rep:
Quote:
Originally Posted by Geist
Complete shot in the dark, I don't have the kernel or any idea what I'm really talking about, but the only delays on boot I've had were always after fiddling with framebuffer settings, like having those Tuxes on top and so forth.
Maybe something like that snuck in during the upgrade? Some new configuration, perhaps?
I'm guessing something new in the kernel that is disabled by default, but when enabled causes the delay (or vice versa...). That would explain why the same kernel, using a different .config, will delay or not delay.
Also of interest - I tried the 5.5.x kernel, and while it also had the delay, it was 70 seconds, not 90 seconds. Again, not sure what is different.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
