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.
The issues I had here were with kernel-generic + initrd. To be honest, I'd like to get rid of the huge kernels. They're a hack that was developed back before we had anything like udev, and if initrd generation could be added to the installer there would be no good reason to keep the huge kernels. Either way, there's no advantage to using a huge kernel. And there are a few things that the huge kernel does not do as well - some of the modules don't load properly into a huge kernel, and having the huge kernel has forced a few things to be built into kernel-generic that really shouldn't be (in the interest in keeping the module tree mostly compatible with both kernels).
huge kernels are good only for initial installations.
Other than that, generic + initrd are perfectly fine
The current kernel development cycle is very fast, everything can not be tested at length, so I think there will always be some bugs and regressions, some users will be luckier than others depending on their hardware
Distribution: slackware, slackware from scratch, LFS, slackware [arm], linux Mint...
Posts: 1,564
Original Poster
Rep:
Sorry, but I think the problem is not solved. I upgraded both systems (32-bits and x86_64).
- x86_64 is ok
- 32-bits still has the problem, even worse, I booted three times to get it work normally. update: added two snapshots taken with smartphone
<snip>
I booted three times to get it work normally.
This is what I don't understand. The fact that for me at least after the first hang, I hard power off and then it boots normally until another kernel change (totally random, sometimes several kernel updates without the problem, then 2 in a row).
It happened most frequently on my old Core 2 quad, but has still happened once on my newer 7600K. Both of course 64 bit.
Sorry, but I think the problem is not solved. I upgraded both systems (32-bits and x86_64).
- x86_64 is ok
- 32-bits still has the problem, even worse, I booted three times to get it work normally. update:added two snapshots taken with smartphone
Your screenshots are the poster child of what happens with my Intel based mini-PC.
Sadly, I think it is because the 4.14.x kernel is too young, and it is still not matured enough. Consider that it got a massive update.
Now, not that is not worth if we find the issue.
To note that my mini-PC runs with a "state of art" Intel microcode cpio, concatenated to initrd.gz, nothing to suspect, in my case, excluding a naughty kernel.
Your screenshots are the poster child of what happens with my Intel based mini-PC.
Sadly, I think it is because the 4.14.x kernel is too young, and it is still not matured enough. Consider that it got a massive update.
Now, not that is not worth if we find the issue.
To note that my mini-PC runs with a "state of art" Intel microcode cpio, concatenated to initrd.gz, nothing to suspect, in my case, excluding a naughty kernel.
I agree, usually, Pat, waiting for some minor versions, before pushing a major version of the kernel
I'm a shoot first and ask questions later personality.
Compile amd install the newest kernel the day it is released.
It is a very simple thing to keep the old kernel in lilo or elilo as a backup.
Of course I don't do anything critical on my 'puter any more as I am long-time retired.
John
Finding issues soon in -current gives more time to solve them before the official release.
Sure. We got it: our computers crash. Now, how we solve that?
My bet is that we will have to look smiling at our computers while they crash (it will boot, or it will not boot? that's the question!), meanwhile that overlord called Linus Torvalds will do Kernel releases, and our BDFL will push them in to -current, accordingly... until the crap is fixed and the computers will crash no more.
You see another solution for?
Last edited by Darth Vader; 11-26-2017 at 08:22 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
