LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-28-2017, 05:12 PM   #46
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590

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.

Last edited by Darth Vader; 11-28-2017 at 05:30 PM.
 
Old 11-28-2017, 05:29 PM   #47
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,318

Rep: Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709
Quote:
Originally Posted by Darth Vader View Post
BUT, trying to remember, every time when the mini-PC crashed, it was after the EUDEV started working. Always.
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.
Old 11-29-2017, 12:43 AM   #48
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 189

Original Poster
Rep: Reputation: 146Reputation: 146
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.

Last edited by nobodino; 11-29-2017 at 01:23 AM.
 
Old 11-29-2017, 06:17 AM   #49
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware has beern Main OpSys for decades while testing others to keep up
Posts: 1,520

Rep: Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468
Quote:
Originally Posted by willysr View Post
huge kernels are good only for initial installations.
Other than that, generic + initrd are perfectly fine
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?
 
Old 11-29-2017, 06:53 AM   #50
GazL
Senior Member
 
Registered: May 2008
Posts: 4,519
Blog Entries: 9

Rep: Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003
Quote:
Originally Posted by enorbet View Post
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.
 
Old 11-29-2017, 07:43 AM   #51
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by nobodino View Post
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.
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?
 
Old 11-29-2017, 07:44 AM   #52
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Quote:
Originally Posted by enorbet View Post
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?
Loading all the crap in memory is not always the best way. And sometimes the drivers challenge each other.
 
Old 11-29-2017, 08:03 AM   #53
tazza
Member
 
Registered: Jul 2005
Distribution: Slackware64 -current
Posts: 98

Rep: Reputation: 31
Quote:
Originally Posted by enorbet View Post
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?
Totally agree.
 
Old 11-29-2017, 08:09 AM   #54
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware has beern Main OpSys for decades while testing others to keep up
Posts: 1,520

Rep: Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468Reputation: 1468
Quote:
Originally Posted by Darth Vader View Post
Loading all the crap in memory is not always the best way. And sometimes the drivers challenge each other.
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..
 
Old 11-29-2017, 08:36 AM   #55
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
Anyway, with using initrd or not, the crash which is the subject of this very thread is alive and kicking...
 
Old 11-29-2017, 12:45 PM   #56
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,544

Rep: Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494Reputation: 2494
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.
Old 11-29-2017, 01:23 PM   #57
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 189

Original Poster
Rep: Reputation: 146Reputation: 146
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 ?

Last edited by nobodino; 11-29-2017 at 02:36 PM.
 
Old 11-29-2017, 01:30 PM   #58
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,318

Rep: Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709Reputation: 3709
Quote:
Originally Posted by nobodino View Post
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 ?
Is the list of loaded kernel modules any different?
 
Old 11-29-2017, 02:27 PM   #59
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 1,647

Rep: Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590Reputation: 590
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?

Last edited by Darth Vader; 11-29-2017 at 03:00 PM.
 
Old 11-29-2017, 02:47 PM   #60
nobodino
Member
 
Registered: Jul 2010
Location: in France
Distribution: slackware, slackware from scratch, LFS, linux Mint, Niresh (MacOS)...
Posts: 189

Original Poster
Rep: Reputation: 146Reputation: 146
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
File Type: txt list_modules.txt (4.2 KB, 7 views)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Strange behavior battles Linux - Newbie 5 07-10-2014 09:59 AM
dcgui-qt's strange behavior harken Linux - Software 2 02-24-2005 03:10 PM
Very Strange Behavior raysr Mandriva 4 08-31-2004 03:06 PM
Strange Behavior andrewb758 Linux - Hardware 5 08-31-2003 03:42 PM
strange behavior abhijit Linux - General 3 07-10-2003 12:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration