OK, as I said, I made that 4.9.65 generic kernel and I use it on my mini-PC.

Sooo, how the current Kernel is still configured in LILO, and I noticed that in the latest pull you upgraded EUDEV, I rebooted the mini-PC in the generic 4.14.2 with initrd. Surprise! It works with no crash.

I will continue the tests and report back.

Later: Nope. It crashed on the second reboot.

This time the crash was when loading the KDE (on the splash). Yeah, I have the KDE in my "router" ...

BUT, trying to remember, every time when the mini-PC crashed, it was after the EUDEV started working. Always.

And, most times the crash happened while the system was still in pure console, with no X activated. A glorious random crash.

Same here, when I was getting a crash. Pretty sure there's a guilty kernel module.

Anyway, _lots_ of patches queued up for 4.14.3 in stable-review. Whatever's causing this is going to be found sooner or later.

5 members found this post helpful.

last argument for eudev 'culpability':
- my current Dlackware system updated to kernel-4.14.2 is not affected by the initial segfault (eudev is replaced by systemd).
- In all my experiments the kernel were huge-smp kernels, and not generic ones with initrd.

Just FTR, some of us prefer to not have to use initrd. AFAIK the only truly compelling reason for initrd is encrypted file systems. Why add any complexity with little or no benefit unless absolutely required?

Along with root on lvm, early firmware loading of cpu microcode,and probably a few other more niche reasons. Like it or not, initrd's are part of the early boot landscape now.

And how you explain that the Kernel 4.9.65 works like a Labor Hero in the same mini-PC of mine, with the same operating system, updated to latest -current?

Loading all the crap in memory is not always the best way. And sometimes the drivers challenge each other.

Totally agree.

Just FTR I don't stick with a Huge kernel. It's only for initial run. ASAP I build a custom kernel and only a handful of items, mostly ext4 related, are needed "hard wired". I attain extremely low footprint along with realtime, low-latency and never have a "driver fight" once nouveau is blacklisted and nvidia driver installed. In the past I did need to blacklist HDMI sound and while I still do that, the need is diminishing with Pulseaudio improvements. I've been doing this for so long it has become absolutely routine. I will most definitely do whatever I can to avoid having initrd. I simply don't see a good cost/benefit ratio for my PCs and usage..

Anyway, with using initrd or not, the crash which is the subject of this very thread is alive and kicking...

I've always been curious, what is the benefit of using an initrd outside of the times it is absolutely required (lvm, luks, UUIDs, special requirements, etc). I understand the benefits of not having a "huge" kernel, but is there a benefit of an initrd over a purpose built kernel other than the time it takes to make that custom kernel?

This isn't directed at anyone in particular, just me trying to find general knowledge.

1 members found this post helpful.

new test:
- today I rebuilt slackware from scratch with slackware-current up to 28/11/2017 except that I replaced eudev-3.2.5 by eudev-3.2.2 (last known stable version of eudev before problems occured)
- kernel is 4.14.2
- eudev is 3.2.2
- boot in 'single user' mode: ok
- switch to 'multi user' mode: ok, no segfault

What do you think of this new test ?

Is the list of loaded kernel modules any different?

Just to note that my mini-PC succesfuly ran like a charm in the latest current and kernel 4.14.2, with SystemD as init and no EUDEV, of course.

OK, also PAM and friends, but I consider them being non essential pals for our case.

That, because I have an e-SATA port, I connected an external 160GB 2.5" e-SATA enclosure, where I made a standard installation, then replaced the init system with the one given by the friends from Dlackware. Out of curiosity.

With all respect, WTF happens there?

BTW, the modules loaded are the same. Verified right now.

PS. Could be that that the EUDEV bite in a sensible point of the 4.14.x kernels?

I just checked the listed modules for the last test (see enclosed file),and didn't do it for the others.
The kernel is huge-smp (4.12.2).

Attached Files

list_modules.txt (4.2 KB, 27 views)