Hello:

Hmmm ...
Don't think so.

I distinctly remember doing update-initramfs -u as root after using jed to write the .conf file to /etc/modprobe.d/.
When I saw it had not stuck, I decided to go for the /etc/rc.local solution.

Maybe it was the -k all part?

And for me too ... =-)

Had to find man update-initramfs.orig.initramfs-tools as man update-initramfs for some reason brings up Live-Tools (8) - Live Systems Project.

Indeed ...
But then I have to remember that I once actually wrote the file. 8-D !!!

Yes, it's a habit I have kept from my old MS days.

Weary after so many W95/98/2000/XP reinstalls, I decided to keep a log in which I would write each thing I did.

I'd start with the plain out of the box install and make an image, then install the basic stuff I needed/wanted and made another image and so on.
Each successive image had a log of what was done using the previous one.

Thanks a lot for your input.

Best,

A.

Hello:

Good question.

Even though I started in IT ~1996 (all MS stuff, no development/coding, just TS and HW maintenance), I'm relatively new to Linux and a total novice with respect to kernels and compilations.
So I looked around in the forum, found what seemed to be what I wanted to do and followed the instructions on the page.

These are correct but make no distinction between compiling a kernel and contributing to kernel development.
Something that is quite obviously way above my head and most probably, way above the head of most of those posting here to find Devuan related answers.
In my case, a way to compile or upgrade to the latest kernel.

In fact, the title of the post indicates that it is what I was wanting to do:

So I guess that's why ...  =-)

Yes, that is exactly what I want to (try to) do.

Right.
Thanks a lot for the heads up.

I seriously doubt I can do that.
Make some suggestions, maybe.

Indeed ...
As I have found from what I have been reading on the web and the results of my countless efforts.

Indeed it has.

Maybe the admins/OP could consider adding a note to the post I've cited.

It's undoubtedly a commendable effort on behalf of the OP but a warning or caveat explaining that the instructions contained are not what is needed to *just* compile a kernel would be a plus.
Or maybe addiitonal instructions (given the complexity involved) on how to do it without a full git ie: with a tarball like you suggest   

Thanks a lot for your input. (and to the OP, of course)

Cheers,

A.

Hello:

I see ...

Sort of like the CR that's important to have in sudoers.d filers, else visudo.c will complain?

Seems a better (more reasonable) behaviour than Pluma. 

Midnight Commander?
Memories of the trusty NC under DOS come to mind. =-)

Thanks for the heads-up, I'll give it a try - didn't know it was available for Linux .

There's quite a bit of text editors for Linux out there but I find that, if you're not a programmer (my case), they (as well as hex editors) tend to be a bit too much.

Indeed ...

To try, I added a second s to the script to test.

#!/bin/sh
# Shutdown system without the use of shutdownhelper 
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:
for i in s u s o; do echo $i | sudo tee /proc/sysrq-trigger; sleep 2; done  # halt

The first time I tried it, I got the freeze+fans act for the first time using this script.
Obviously, right before/coincidentally with the shutdown ie: o:

s
u
sudo: unable to open log file: /var/log/sudo.log: read only file system
s
sudo: unable to open log file: /var/log/sudo.log: read only file system

... and the fan at full blast.

It's all right, you have been very helpful.  =-)

I used to think it was all ethernet (the problematic on board e1000e) related.
But no.

Once I managed to get WoL disabled, the reboot after shutdown was solved (it was part one of a two part shutdown problem).

WoL is disabled, gave me a hard time to get that done as there's no BIOS option for the in the Ultra 24 and the DOS utility Intel says you MUST use to disable WoL does not disable it permanently as ethtool can enable it again from within Linux, so I added a script to /etc/networks/interfaces to try to keep it disabled.

  post-up /sbin/ethtool -s eth0 wol d
  post-down /sbin/ethtool -s eth0 wol d

So why the MUST use the DOS utility if it does not disable WoL in the BIOS or the controller EEPROM? Go figure ...
In any case, Intel tech support for the e1000e was absolutely useless.

The thing is that with WoL and EEE=0 disabled the problem is still there.   8-/

Thank you very much for your help.

Best,

A.

Hello:

No, that's not it.
It seems the path is set in the environment variables.

groucho@devuan:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
groucho@devuan:~$ 

I can run the script directly from the prompt with or without sudo.
With sudo it executes directly (because sudoers) without, it asks me for the PW twice.

Seems that's it.  =-)

From https://it.toolbox.com/question/file-sy … ode-061114

So it is normal that sudo cannot write to it's log file after U is called. 

Thanks for your input.

Best,

A.

Hello:

While waiting to see if anyone here had a clue about this, I was able to find a few leads.

It seems that the problem is related to the Intel e1000e driver, WoL and the EEE settings on the e1000e on-board NIC.

My rig's BIOS has no setting to disable WoL or the on board Gbe for that matter. (!)

I am disabling WoL at boot with a line in /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#
# Disable WoL - 20181212
/sbin/ethtool -s eth0 wol d
exit 0

It survives a reboot and disconnecting/connecting the interface while logged in.
But it has not been enough as the problem subsists.

Seeing that this involved the e1000e: EEE Tx LPI Timer, I searched and found this:

https://en.wikipedia.org/wiki/Energy-Efficient_Ethernet

My guess was that if the EEE TX LPI timer was what was giving me trouble (?), turning it off would do away with the issue.

Searching around I found this on the web:

https://unix.stackexchange.com/question … n-ethernet

It seems that this EEE thing is also a source of grief to others.
So I tried seeing what the EEE setting was for my on-board NIC using ethtool:

[root@devuan groucho]# ethtool --show-eee eth0
Cannot get EEE settings: Operation not supported
[root@devuan groucho]#

Just to try and see, I attempted to turn EEE off:

[root@devuan groucho]# ethtool --set-eee eth0  eee off
Cannot get EEE settings: Operation not supported

From the last link it seems that the EEE settings can be modified with the Windows driver but not with the Linux driver, at least not using ethtool.

Which was really unexpected. 8 ^/

The ethtool version installed in Devuan is 4.8 (20161004)

[root@devuan groucho]# ethtool -h | grep version
ethtool version 4.8
[root@devuan groucho]#

The latest available version is 4.19 (20181102)

The installed e1000e driver version is 3.2.6-k and it has SmartPowerDown enabled, apparently by default. (?)

[root@devuan groucho]# modinfo e1000e
filename:       /lib/modules/4.9.0-8-amd64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        3.2.6-k
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     5EA033004005330EC3218BD
alias:          pci:v00008086d000015D6sv*sd*bc*sc*i*
---- snip ---
depends:        ptp
retpoline:      Y
intree:         Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions 
parm:           debug:Debug level (0=none,...,16=all) (int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
[root@devuan groucho]#

Any ideas as to how to get around this?
Turning off the EEE feature is the only thing I can think of now.

But how?
Maybe I need the latest version of ethtool and/or the latest version of the Intel driver but they are not available in the Devuan repo.

EDIT:

This is the specific on-board hardware in my Ultra24 rig:

[root@devuan groucho]# lspci | grep -i ethernet
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
[root@devuan groucho]# 

This is the latest version of the Intel e1000e driver:

https://downloadcenter.intel.com/downlo … duct=34459

---
For Intel® 82566DM Gigabit Ethernet PHY
Intel® Network Adapter Driver for PCIe* Intel® Gigabit Ethernet Network Connections Under Linux*
Version: 3.4.2.1 (Latest) Date: 8/26/2018
---

Can an update to this driver be requested to the maintainers?
If not, how can the download from Intel be installed in Devuan ASCII?

Thanks in advance.

A.

Hello:

Welcome.

I've been getting this forever, with any distro I've tried.
And on an older, very different rig: a Sun Ultra24 WS on Intel Q9550 w/8Gb:

groucho@devuan:~$ sudo dmesg | grep -i error
[    0.145089] ACPI Error: [SUPP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[    0.145099] ACPI Error: Method parse/execution failed [\_SB._OSC] (Node ffff9897731b8000), AE_NOT_FOUND (20160831/psparse-543)
groucho@devuan:~$ 

By now, it seems to be a standard issue warning about a kernel whatever that will not ever be fixed because it's (apparently) harmless.
See they have the same (20160831/psargs-359) and (20160831/psparse-543) tags.

Linux has quite a few of those and ACPI/crap BIOS combos are probably one of the main culprits.

Cheers,

A.

Hello:

Well ...
It all seemed to be so previsible.
But no.

Just a while I got back home and on booting up, I launched Pegasus Mail (which I run off Wine).
I was expecting the usual lag in starting up it developed some time ago (have not found the real cause) and lo/behold: no lag.

No idea how/why.

Then I launched Firefox.
I was also expecting to have to open my first page on a parallel tab so as to avoid the right-click problem this thread is about.
But no. It behaved correctly.

I exited Firefox and launched it again to check and sure enough, there is was again.

Coincidences may (as some people believe) very well exist but I do not think this is so in the realm of IT.

I'll have to boot/reboot a few times to check out if I can now reproduce this same sequence and verify a link between these two separate events.
If I can (?) maybe this odd mouse behaviour has a deeper, system based origin but at first sight I fail to see how that could be.

---
Edit:
The issue with PMail, related to a CUPS mis-configuration and the program looking for a printer when launched, has been solved.
So it was a coincidence.

There's no link between that and the odd mouse behaviour this thread is about.
---

Still, any ideas?

Thanks in advance.

A.

Hello:

It is.  =-)

OK. Note taken.

Must have slipped me.
And I was so happy with the package browser.  8^D!

Thanks.

A.

Hello:

Can't find it in http://deb.devuan.org/merged/  ascii-backports  main contrib non-free.

Is that the right repo?

Yes.
The version in the repo does not seem to have the 'selective download' feature.

Thanks in advance,

A.

Hello:

Really?
Need to ask?

Man, this is a bummer.
Bad, bad, bad news...

Indeed, we are living in interesting times.

Cheers,

A.