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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Until I seen that one of my computers successfully boot just one time from two.

So, please explain me, what sense has to adopt a x.y.0 kernel, when you are aware that most likely it will contains bugs, which cannot be fixed in other way than rolling up later up to a x.y.7 or x.y.10?

OK. I will give you a reason: a little innocent (and a bit sadistic) pleasure to know that the users has crashes on their computers. You see another reason for?

Of course, I do not expect the -current to be rock stable. BUT, pushing a thing which you have to suspected from starts that will create problems, is a bit overhand.

And to be honest, when I seen that that unusual move to so early 4.14.0, I imagined that there will be problems somehow, and I am not a world-wide know developer like our BDFL...

Finally, bear in mind that there was the habit to wait until a x.y.7 or x.y.10 was released, before to switch to that Kernel series.

And I appreciated that, because we are NOT the Redhat or SuSE, to test things implemented by US in the kernels, together with some of our brave users.

Nope, we are Slackware, we have no Kernel developers and we are at mercy of Linus Torvalds.

I am on the latest 4.14.2 and zero problems... just thought I would toss that out there. Perhaps it has something to do with running a fairly new laptop? No idea.

edit: Also, just my 2 cents. I don't think the developers ever do anything without significant thought. If they went to 4.14.x I can tell you it wasn't on a whim.. careful thought went into it and decision was made. I have complete faith in these guys, especially compared to other distros.

Has someone registered a bug on lkml concerning the subject of this thread?

I had a fair number of failures with .0, only a few with .1, and none so far with .2. All of them on 32-bit... x86_64 has been stable for all of the kernels (which partly explains how some fairly unstable kernels slipped into -current; I wasn't spending a lot of time running 32-bit).

Considering the rapid improvement in the 4.14 series, I think they're doing a good job killing bugs. But if anyone has the time to properly bisect an issue, I'm sure they'd welcome that kind of report.

And if evidence was not what it seemed? And if the kernel, the ideal culprit was not the faulty component?

For that I tested two hypothesis:

1/ I upgraded a mini slackware-current system (up to 25/11/2017) to kernel-4.14.2, and rebooted the first time in 'single user' mode. Everything was ok. Then I switched to 'multi user' mode and typed : 'telinit 5' and the system segfaulted immediatly.

2/ On my slackware-14.2, I built my own kernel-4.14.2 with the files from slackware-current, and upgraded the system to kernel-4.14.2.As for the first test, I rebooted in 'single user'. Everything was ok. Then I switched to 'multi user' mode and typed : 'telinit 5' and this time everything was ok, and is still ok.

Couldn't it be another component that make segfault the system?
Which package is involved when switching from 'single user' mode to 'multi user' mode?

'eudev' was upgraded nearly as kernel-4.14.0 came in slackware-current.

1/ I upgraded a mini slackware-current system (up to 25/11/2017) to kernel-4.14.2, and rebooted the first time in 'single user' mode. Everything was ok. Then I switched to 'multi user' mode and typed : 'telinit 5' and the system segfaulted immediatly.

If you're using a huge kernel, all bets are off.

Quote:

2/ On my slackware-14.2, I built my own kernel-4.14.2 with the files from slackware-current, and upgraded the system to kernel-4.14.2.As for the first test, I rebooted in 'single user'. Everything was ok. Then I switched to 'multi user' mode and typed : 'telinit 5' and this time everything was ok, and is still ok.

Couldn't it be another component that make segfault the system?

If so, and if generic+initrd is being used, it would still be a kernel bug.