The officially official Devuan Forum!

You are not logged in.

#1301 Re: Desktop and Multimedia » keyboard behavior changed - why and how to fix it » 2021-06-14 18:08:47

Hello:

golinux wrote:

Thanks ...

You're welcome.

golinux wrote:

... BIOS issue is never good news.

Quite so.

But check the installed version anyhow.
You may already have the latest one available for that board.

golinux wrote:

... terror of having to flash a board ...

I don't like it either.

The usual lack of properly written BIOSs aside, gigabyte is a reputed brand and their hardware can be considered trustworthy.
They may also have BIOS recovery tools in case something goes wrong.
Unless the board is very old, it is quite straightforward to flash a BIOS.

golinux wrote:

... going to live with it on the old board.

You may have seen that I run a Sun MS U24 workstation, very expensive when it hit the market in 2007.
My present full monty configuration would have cost me well over $4.000 at the time.
Obviously, I got my box second hand.

Well ...
The BIOS on this box was a real POS from day one.

As it is not a laptop, does not need to run on solar panels or be up 24/7, I have disabled all the power management settings I could disable.
Processor throttling is taken care of by cpuidle but the rest is off or disabled.
Curiously enough, attempting to disable S states in BIOS put the box in an unusable state, requiring a BIOS wipe and reflash. (!)

In any case, you may want to consider if having any S states enabled (ie: standby/sleep/hibernate) is really necessary for you.

Best,

A.

#1302 Re: Desktop and Multimedia » keyboard behavior changed - why and how to fix it » 2021-06-13 21:54:47

Hello:

golinux wrote:

... ascii 2.1 i386 on my other machine an older gigabyte board ...

One of the things I have learnt with Linux is that a properly written BIOS is crucial to getting ACPI things to work properly.

All the 'S''states that relate to power control settings such as suspend, sleep, etc. depend on properly written BIOS/ACPI tables.
ie: a BIOS that is written correctly observing published ACPI guidelines.

Of all the S states, S3 (the sleep/suspend stuff) is the most difficult to get right because it involves different hardware from different OEMs doing the same thing at the same time, not just the motherboard.

Now, one would think that any and all OEMs would follow ACPI guidelines to the letter, but unfortunately that is not the case.
From the very start, OEMs have followed ACPI guidelines in the way Microsoft interprets them (not the same thing) and this is because ...

But I digress.

You may want to (first) try to get the latest BIOS version for your gigabyte board and see if the issue gets worked out.
There may also be a BIOS setting you need to change.
eg: advanced power management settings -> what 'S' state 'Sleep Mode' is set to.

Bear in mind that as kernel development has advanced, at the same time it has also revealed previously undetected BIOS problems in older hardware.

Best,

A.

#1303 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-11 13:13:02

Hello:

DevuanUser345 wrote:

... he would prefer not to ship it in debian was he is not able to debug things as he does not have sysvinit machines around.

This is where it all starts.
It's a sign of Things To Come©.    ---> 8^/

A.

#1304 Installation » Reasons to stay with Devuan » 2021-06-11 07:13:49

Altoid
Replies: 14

Hello:

In a blog post on Thursday, GitHub security researcher Kevin Backhouse recounted how he found the bug (CVE-2021-3560) in a service called polkit that is used in systemd, a common Linux system and service manager component.

Backhouse says the flaw is surprisingly easy to exploit, requiring only a few commands using standard terminal tools like bash, kill, and dbus-send.

See:
Seven-year-old make-me-root bug in Linux kernel patched. https://www.theregister.com/2021/06/11/ … olkit_bug/

So ...
Still want to know if there's a reason to stay with Devuan?

Best,

A.

#1305 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-10 14:16:08

Hello:

DevuanUser345 wrote:

As there is a desktop mode ...

Well ...
The Linux kernel has quite a few things enabled by default which (imho) are not needed, save in a server setup.
eg: apparmor, etc.

DevuanUser345 wrote:

... not sure if it should be in the repo or not ...
... not skilled enough ...

Nonsense ...
You were skilled enough to write a script to make it work, the first time around.  8^D

That's certainly not my case.
I would not have been able to use a package installed from the Devuan repository due to its (apparently) missing a vital part.

So ...
Does it make sense that it be in the repository if it is (apparently) incomplete?

DevuanUser345 wrote:

... all packages (buster, bullseye, sid) do not have a sysvinit script.

Then it is a very good thing that you discovered this, wrote and shared the necessary script.
Like I said earlier, maybe it is a slip-up on behalf of the packagers.

Best,

A.

#1306 Re: Desktop and Multimedia » [SOLVED] Package: tuned, not working » 2021-06-10 13:11:52

Hello:

DevuanUser345 wrote:

... "tuned" is directly from redhat they are banning init.d scripts ...
... so "tuned" does not provide any.
... daemon didnt start ...
... the tuned-adm daemon control tool didnt work.

This is (I suppose) mainly for a portable system, so I don't have any use for it it.
But if this is so and there isn't a good reason for this (ie: Devuan package for tuned without the proper scripts) maybe it should not be in the repository.

DevuanUser345 wrote:

... wrote the init.d script on my own.
... first init.d script i have written so far.

Good going! 8^D !
You may want to consider reporting this to those taking care of the packaging at Devuan HQ.
Maybe it was just a slip-up on their behalf, they do have a lot o their hands.

Thanks a lot for your effort.

Best,

A.

#1307 Re: Installation » UUID and drive letter assignments » 2021-06-10 00:35:54

Hello:

GlennW wrote:

... for me it's monitoring disk space.

I monitor disk space like this:

 DISKS
 ${hr 2}
 / $alignc ${fs_used /} / ${fs_size /} $alignr ${fs_used_perc /}%
 ${fs_bar /}
 /home $alignc ${fs_used /home} / ${fs_size /home} $alignr ${fs_used_perc /home}%
 ${fs_bar /home}
 /media/backups $alignc ${fs_used /media/backups} / ${fs_size /media/backups} $alignr ${fs_used_perc /media/backups}%
 ${fs_bar /media/backups}
 /var/log $alignc ${fs_used /var/log} / ${fs_size /var/log} $alignr ${fs_used_perc /var/log}%
 ${fs_bar /var/log}

Not my doing but cannot recall the source.
Thanks for your input.

Best,

A.

#1308 Re: Installation » UUID and drive letter assignments » 2021-06-10 00:32:23

Hello:

Dutch_Master wrote:

... should be able to assign letters to specific UUID's using (e)udev rules.

I think it may be easier to just assign labels instead of saying /dev/sdx.

eg:

SATA1: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-86} 

Thanks for your input.

Best,

A.

#1309 Installation » UUID and drive letter assignments » 2021-06-09 19:39:34

Altoid
Replies: 5

Hello:

My Devuan box has four SAS drive slots, an on-board USB socket and room to comfortably install an additional two or three 2.5" drives.

I use UUID to keep the installation behaving properly (so to speak) but although this works, drive letters move around between UUIDs if I add a drive.

This affects my conky output by mean of which I monitor drive temperatures.

/dev/sda: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-84}
/dev/sdb: +${execi 60 hddtemp /dev/disk/by-uuid/49d1369c-ed70-4543-b0ee-ef65327e101b | cut -c 83-86}
/dev/sdc: +${execi 60 hddtemp /dev/disk/by-uuid/bdf33361-5929-433e-ac7f-1a626aa6e844 | cut -c 78-81}
/dev/sdd: +${execi 60 hddtemp /dev/disk/by-uuid/7a33fda5-abda-451b-b6ef-c17553c78810 | cut -c 83-86}
/dev/sde: +${execi 60 hddtemp /dev/disk/by-uuid/ca8dbded-819d-4e2b-b017-0981a75ea718 | cut -c 101-104}

           

When I added an old SATA drive for testing purposes, drive letters got shuffled down, the new drive became /dev/sda and the one that was /dev/sda became /dev/sdb.
So, while I am still monitoring a specific drive's temperature, I sort of lost as to which drive it is.

It's just a labelling but it is what I use to ID the drives and their temperatures via conky.

Maybe I should skip the /dev/sdx system and just go with something like Drive N?

Comments welcome.

Thanks in advance,

A.

#1310 Re: Off-topic » What will happen to Windows? » 2021-06-06 13:06:34

Hello:

golinux wrote:

Censorship is a slippery slope.

Quite so ...
Very.
Not my intent.

golinux wrote:

... post may be stupid and irrelevant ...

Not stupid.
In another context/forum it would actually be a fitting subject.

In my opinion, I'd say it is (if anything) irrelevant.

golinux wrote:

Devuan is better ...

That was my idea.

Thanks.

Best,

A.

#1311 Re: Installation » Nvidia persistence? » 2021-06-06 00:44:09

Hello:

Spaceman Spiff wrote:

... installed the proprietary nvidia driver ...
... keep getting this message when I install a new package ...

Did you check out the thread I suggested?  ->  https://dev1galaxy.org/viewtopic.php?id=3820

See post #23, it has a step by step rendition of how I followed Hevy Devy's instructions and solved my problem.

Don't skip any steps.

Best,

A.

#1312 Re: Off-topic » What will happen to Windows? » 2021-06-05 21:54:47

golinux wrote:

Freedom is a double edged sword so actions should be chosen with care.

Indeed ...

I really fail to grasp how/why What will happen to Windows can actually be a topic, even here at the Off-topic forum.

Ah, yes ...
Forgot my pill.  8^/

A.

#1313 Re: Devuan Derivatives » Support for DevuanDog! » 2021-06-02 17:05:47

Hello:

brday wrote:

BusterDog is still available and active?

Hmm ...
No idea.
Not my dog.
Sadly, I haven't had a dog since I was 16.

brday wrote:

What is your link to download your Live iso?

I don't have a Live iso, hence I have no link to anything you can download.

brday wrote:

Since July 2020 there is no activity on your forum.

Makes sense ...
I don't have a forum.
Never had one.

brday wrote:

I don't understand how a nice system like DevuanDog has been discontinued.

Hmm ...

Ask the author?
Or carefully read what he posted here --> https://oldforum.puppylinux.com/viewtop … c#p1040932

ie:

fredx181 wrote:

Reason is that I've found a self-supporting way, which I prefer, to avoid systemd, BusterDog is based on Debian Buster with a few alterations to make possible running without systemd.

brday wrote:

Sorry ...

It's quite all right.
Every one has a bad day at some time or another.
I have one every week.
Usually on tuesdays, occasionally fridays.

brday wrote:

...  in what flavor of Devuan do you have software updated to date with firefox which is about version 89?

Sorry to dissapoint you.
I don't have any flavours of Devuan.
Just the plain Devuan Beowulf I got here.

But my all time favourite ice cream flavour is bitter chocolate with dark chocolate chips mixed in.
Yes, redundancy is a real thing for me.

Cheers,   8^P

A.

#1314 Re: Devuan Derivatives » Support for DevuanDog! » 2021-06-02 12:36:12

Hello:

brday wrote:

Why did devuandog stay in 2019? ...

It was discontinued/terminated.

See: https://oldforum.puppylinux.com/viewtop … 2#p1040932

fredx181 wrote:

Reason is that I've found a self-supporting way, which I prefer, to avoid systemd, BusterDog is based on Debian Buster with a few alterations to make possible running without systemd.

A.

#1315 Re: Other Issues » Tape drives » 2021-05-23 21:11:33

Hello:

alphalpha wrote:

that might be it
sadly ftape and zftape are not in the kernel anymore

Indeed ...

The problem was that this hardware (my opinion) was not really something solid like all the SCSI tape drives out there at the time.
The advantage was that it was much less expensive to get a QIC/Travan etc. and run it from a parallel port or IDE adaptor card.
But for most, not the real thing.

In my day, I had a QIC and a Travan under Windows but found them to be slow and unreliable.

Here's a link to old Ubuntu releases:

http://old-releases.ubuntu.com/releases/

Try Ubuntu 5.10 (Breezy Badger) or Ubuntu 6.06.2 LTS (Dapper Drake), both have 64bit DVD Live editions:

http://old-releases.ubuntu.com/releases … -amd64.iso
http://old-releases.ubuntu.com/releases … -amd64.iso

alphalpha wrote:

... any practical usecase for that tape drive ...

Quite so.

With relatively inexpensive fast HDDs to make a multiple Tb NAS with very little investment, tape ends up being cumbersome.
And no, I will not store anything in any cloud.

A cloud is just water vapour: one moment it's there, the next it's gone.

I had my last DAT DD2 drive sitting atop my box for the longest while and finally decided to move it out of the way last week.
A beautiful Sun Microsystems external box hosting a Seagate Scorpion 8000 which saw very little use.
Maybe the box, PS and SCSI board will be of use for something.

alphalpha wrote:

... still curious what might be sitting on that tape

Ahh ...
So that's it.  8^D !

alphalpha wrote:

... put it back into that old 486 where i ripped it out ...

You'll still need the application used to make the tape or download it raw and pick out the bits.

Once you find out what you can do by booting the Ubuntu DVD, you may want to make a VM see if you can access it from there.
Much better than trying anything with the 486.

Cheers,

A.

#1316 Re: Other Issues » Tape drives » 2021-05-22 17:16:32

Hello:

It seems that what is needed is to load the proper driver modules.

ie: modprobe zftape -> depends ftape

This will load zftape and ftape, creating all needed devices under /dev, so there's no MAKEDEV to run.

But this was when you could actually find ftape and zftape for your kernel.

zftape and ftape went awol quite a few years ago, so they were taken out of the kernel from 2.x something on.
I have read in one post that maybe some old Ubuntu may have it, so booting that from a CD may be a solution.

https://retrocomputing.stackexchange.co … with-ftape

Check out these posts:

http://thewunders.org/SxS/storage/ftape.html

https://tldp.org/HOWTO/Ftape-HOWTO-6.html#ss6.1

https://github.com/Godzil/ftape

https://dmitrybrant.com/2020/11/01/how- … -qic-tapes

Good luck ...  8^)

Best,

A.

#1317 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-17 18:30:18

Hello:

Camtaf wrote:

Everything not needed to run a system should remain optional ...
... don't foist these things onto ordinary desktop users ...

Evidently that's not the vision of those who are in a position to run the Debian show and decide the hows, why's and whens.

Camtaf wrote:

... a good working distro to do my daily tasks ..

I'm glad to see we're more than one.

But I'm afraid the dice have already been rolled.
And the result was not in our favour.

Hence the very existence of Devuan.

Best,

A.

#1318 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-17 15:51:26

Hello:

dice wrote:

... this sort of config should be opt in even at the kernel level.

Exactly my point.

Altoid wrote:

If and when I want/need to install a Mandatory Access Control scheme for my rig's security, I'll just apt install the required modules and configure.

Altoid wrote:

Makes no sense to call it a security feature ...

I could not care less about what it is called.

It is being made part of the kernel just because some DH decided it should be.
Why? On the basis of what?

Next thing you know you'll have to set it up/configure if you want the kernel to work.
eg: no apparmor/tomoyo/SELinux? No WAN/LAN.

This has all the colourings of one of Poettering's diktats.
Like this other one:

https://dev1galaxy.org/viewtopic.php?id=4136

Bad, bad, bad ...

A.

#1319 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 22:46:29

Hello:

You were quite right, I stand corrected.

In spite of what wiki.archlinux says, adding security=none disables tomoyo as there are no entries for it in dmesg, kern.log or syslog.

Edit: security=none not only disables tomoyo, it also makes apparmor=0 unneccesary. 8^D

Thanks for the heads up.  8^)
Best,

A.

#1320 Re: Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 22:30:18

Hello:

ralph.ronnquist wrote:

... Way Too Many.

Indeed ...

ralph.ronnquist wrote:

tomoyo-tools ...
... why that is enabled in debian's standard linux-image is unkown to me ...

Hmm ...
Maybe it's yet another one of Poettering's brillant ideas?

ralph.ronnquist wrote:

Apparently adding security=none to the boot command should disable this one.

I was wondering about that.
A bit for disabling apparmor but none for disabling tomoyo?

I think not:
https://wiki.archlinux.org/title/TOMOYO_Linux#

wiki.archlinux wrote:

TOMOYO Linux 2.x is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This chart compares the differences between each branch.

wiki.archlinux wrote:

Disabling
For kernels 5.1 and above remove tomoyo from the lsm= kernel parameter or remove lsm= entirely.  <- | x |
For kernels 3.2 to 5.0 change the kernel parameter security=tomoyo to security=none.

I'll try it out and report.

-------> I_don't_like_this.  8^|

If and when I want/need to install a Mandatory Access Control scheme for my rig's security, I'll just apt install the required modules and configure.
Why do I have to have the kernel looking to run something that is not there?

Thanks for your input.

Best,

A.

#1321 Installation » Kernel upgrade: apparmor and tomoyo » 2021-05-16 19:29:46

Altoid
Replies: 8

Hello:

My 4.19 Devuan Beowulf, unlike ascii which had it disabled by default, set up apparmor as if I had actually asked for it.

I let it stay on and after reading around a bit, decided that it was not worth keeping around.
So I uninstalled it and added apparmor=0 to my kernel command line so it would not be asking for it.

Fast forward to my upgrading the installation to the 5.10 kernel:

groucho@devuan:~$ uname -a
Linux devuan 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
groucho@devuan:~$ 

The 5.10 kernel also recommends apparmor:

groucho@devuan:~$ aptitude why apparmor
i   linux-image-5.10.0-0.bpo.3-amd64 Recommends apparmor
groucho@devuan:~$ 

So it does as the upgrade from ascii to Beowulf did and installs apparmor.

Now ...
Seeing that my kernel command line had the apparmor=0 bit, you'd think that it would leave it alone and skip installing apparmor.
After all, it left the rest of the command line stanzas as they were.

But no ...
Not only did it install apparmor but it also removed the apparmor=0 bit from the kernel command line.

No big deal: I just uninstalled it and returned the kernel command line to what I had set it.

Then while looking for clues as to what goes on in my system when I get a bad shutdown, I found this in dmesg:

In dmesg ie: at boot

[   21.906451] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.

Also at shutdown:

In kern.log and syslog:

May 16 13:57:16 devuan kernel: [14429.313238] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.

I had to look it up as I had no idea as to what tomoyo was, let alone of its existence.

What is all this about?
Is it just me or am I seeing far too many (unrequired) Mandatory Access Control instances in the Linux kernel?

Cheers,

A.

#1322 Re: Other Issues » Tape drives » 2021-05-15 15:49:31

Hello.

alphalpha wrote:

... iomega tape 250 drive along with this 3gb ditto tape ...

Nice find.  8^)

alphalpha wrote:

... how do i get it to work?

The key to this may be here:

Wiki wrote:

Technical aspects

Ditto internal drives were connected through the floppy drive channel and used MFM encoding to store data (the same method as on older floppy drives). An ISA accelerator card called the Ditto Dash, providing higher speed than a stock floppy controller, was also available.
--- snip ---

Check that the USB Floppy adapter is correctly inserted.
It should (?) have a key (like the IDE cables did) or some indication in the adapter's manual/instruction sheet.

See:

https://en.wikipedia.org/wiki/Ditto_(drive)
https://www.manualslib.com/products/Iom … 35190.html   <---- | x |
https://johnvidler.co.uk/linux-journal/LJ/022/1215.html
http://pong.tamu.edu/~baum/linux/LDP/HO … TO-28.html

Edit:
https://tldp.org/HOWTO/pdf/ZIP-Drive.pdf

Best,

A.

#1323 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-13 19:56:13

Hello:

Altoid wrote:

... and report back.

Done.

groucho@devuan:~$ uname -a
Linux devuan 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
groucho@devuan:~$ 
groucho@devuan:~$  apt policy nvidia-legacy-340xx-kernel-dkms
nvidia-legacy-340xx-kernel-dkms:
  Installed: 340.108-10~bpo10+1
  Candidate: 340.108-10~bpo10+1
  Version table:
 *** 340.108-10~bpo10+1 100
        100 http://deb.devuan.org/merged beowulf-backports/non-free amd64 Packages
        100 /var/lib/dpkg/status
     340.108-3~deb10u1 500
        500 http://deb.devuan.org/merged beowulf/non-free amd64 Packages
groucho@devuan:~$ 

Q: what does *** after Version table: mean?

With respect to e1000e-3.8.7, I guess now it's time to wait and see if there's another bad_shutdown or bad_boot and if they leave any trace
Maybe the additons to /etc/default/acpi-support have some effect?

---
Edit:
Last night I realised that the e1000e driver module now put in use by the 5.10 kernel upgrade was most probably the current one ie: e1000e-3.8.7.
But I had not applied the five patches, so that's done now.
---

Thanks for your input.

Best,

A.

#1324 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-13 17:17:36

Hello:

geki wrote:

Did you try nvidia drivers from backports / non-free?

Yes.
I do have that in my /etc/apt/sources.list.
Must be a question of package priorities.

Will have to specifically install that: apt install nvidia-legacy-340xx-kernel-dkms/stable-backports
I'll get it done and report back.

Thanks for your input.

Best,

A.

#1325 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-13 00:03:58

Hello:

Altoid wrote:

I'll apply patch 1005 and report back with whatever results I get.

Right, here we go.

groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/1005-e1000e_387_pm_freeze_sane_detach.patch
patching file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$
groucho@devuan:/usr/src/e1000e-3.8.7/src$ sudo make
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-16-common'
make[2]: Entering directory '/usr/src/linux-headers-4.19.0-16-amd64'
  CC [M]  /usr/src/e1000e-3.8.7/src/netdev.o
/usr/src/e1000e-3.8.7/src/netdev.c: In function 'e1000e_pm_freeze':
/usr/src/e1000e-3.8.7/src/netdev.c:7401:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   int count = E1000_CHECK_RESET_COUNT;
   ^~~
  LD [M]  /usr/src/e1000e-3.8.7/src/e1000e.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/e1000e-3.8.7/src/e1000e.mod.o
  LD [M]  /usr/src/e1000e-3.8.7/src/e1000e.ko
make[2]: Leaving directory '/usr/src/linux-headers-4.19.0-16-amd64'
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-16-common'
groucho@devuan:/usr/src/e1000e-3.8.7/src$
groucho@devuan:/usr/src/e1000e-3.8.7/src$ sudo modinfo /usr/src/e1000e-3.8.7/src/e1000e.ko
filename:       /usr/src/e1000e-3.8.7/src/e1000e.ko
version:        3.8.7-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     7C3F06437067F7EF077432C
alias:          pci:v00008086d00001A1Dsv*sd*bc*sc*i*
--- snip ---
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:
retpoline:      Y
name:           e1000e
vermagic:       4.19.0-16-amd64 SMP mod_unload modversions
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:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
parm:           Node:[ROUTING] Node to allocate memory on, default -1 (array of int)
parm:           debug:Debug level (0=none,...,16=all) (int)
groucho@devuan:/usr/src/e1000e-3.8.7/src$

dmesg at boot

groucho@devuan:~$ sudo dmesg | grep -i "e1000e\|00:19"
[    1.079755] pci 0000:00:19.0: [8086:10bd] type 00 class 0x020000
[    1.079770] pci 0000:00:19.0: reg 0x10: [mem 0xf5fc0000-0xf5fdffff]
[    1.079776] pci 0000:00:19.0: reg 0x14: [mem 0xf5ffe000-0xf5ffefff]
[    1.079783] pci 0000:00:19.0: reg 0x18: [io  0xac00-0xac1f]
[    1.079830] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[    2.147352] e1000e: loading out-of-tree module taints kernel.
[    2.215009] e1000e: module verification failed: signature and/or required key missing - tainting kernel
[    2.316026] e1000e: Intel(R) PRO/1000 Network Driver - 3.8.7-NAPI
[    2.333730] e1000e: Copyright(c) 1999 - 2020 Intel Corporation.
[    2.357402] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    2.368687] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[    2.390290] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[    2.412085] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[    2.897162] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[    2.897164] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.897182] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[   27.302085] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[   27.314226] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
groucho@devuan:~$

dmesg for rmmod -v e1000e

groucho@devuan:~$ sudo dmesg
--- snip ---
[10140.513586] e1000e: PCI REMOVE PTP
[10140.513590] e1000e: PCI REMOVE TIMER
[10140.513593] e1000e: PCI REMOVE CANCEL WORK SYNC
[10140.513595] e1000e: PCI REMOVE HW TIMESTAMP
[10140.513617] e1000e: NETDEV CLOSE ENTERED
[10140.513619] e1000e: NETDEV CLOSE WAIT DONE
[10140.513620] e1000e: NETDEV CLOSE DEV IS PRESENT
[10140.741067] e1000e: NETDEV CLOSE DEV IS DOWN
[10140.741081] e1000e: NETDEV CLOSE FREE IRQ
[10140.741086] e1000e 0000:00:19.0 eth0: NIC Link is Down
[10140.741087] e1000e: NETDEV CLOSE LINK DOWN MSG
[10140.741089] e1000e: NETDEV CLOSE NAPI DISABLED
[10140.741099] e1000e: NETDEV CLOSE FREE TX RES
[10140.741121] e1000e: NETDEV CLOSE FREE RX RES
[10140.741123] e1000e: NETDEV CLOSE VLAN DONE
[10140.741125] e1000e: NETDEV CLOSE HW CTRL RELEASED
[10140.741128] e1000e: NETDEV CLOSE DONE
[10140.756902] e1000e: PCI REMOVE UNREGISTER NETDEV
[10140.756908] e1000e: PCI REMOVE WAKE NO RESUME
[10140.756911] e1000e: PCI REMOVE RELEASE HW CONTROL
[10140.756951] e1000e: PCI REMOVE INT AND TX RX RING
[10140.756968] e1000e: PCI REMOVE SELECTED REGIONS
[10140.772962] e1000e: PCI REMOVE FREE NETDEV
[10140.772965] e1000e: PCI REMOVE DISABLE ERR REPORTING
[10140.773065] e1000e: PCI REMOVE DISABLE DEVICE
--- snip ---
groucho@devuan:~$

dmesg for modprobe -v e1000e

groucho@devuan:~$ sudo dmesg
--- snip ---
[10200.634814] e1000e: Intel(R) PRO/1000 Network Driver - 3.8.7-NAPI
[10200.634819] e1000e: Copyright(c) 1999 - 2020 Intel Corporation.
[10200.635004] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[10200.635007] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[10200.635008] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[10200.635010] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[10200.949099] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[10200.949104] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[10200.949129] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[10202.829745] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[10202.829854] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
groucho@devuan:~$

Seems everything is where/how it should be?

Thanks in advance,

A.

Board footer

Forum Software