You are not logged in.
- Topics: Active | Unanswered
#1726 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-09-07 16:00:36
Hello:
... Coreboot needs to become the norm for more systems.
No ...
Coreboot needs to become the norm for all systems.
My Sun Microsystems Ultra24 came out with a flawed BIOS, to the extent that it reports itself as a portable system.
The last (very hard to obtain) BIOS upgrade put out by Sun in the midst of it's gobble up by Oracle was held hostage and did not address this issue which is negligible if you compare it to a severe shutdown issue it has.
groucho@devuan:~$ inxi -Fzx
System: Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit gcc: 6.3.0) Desktop: Xfce 4.12.3 (Gtk 2.24.30)
Distro: Devuan GNU/Linux ascii
Machine: Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01
Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011The people who valiantly undertake making Coreboot barely have time and resources for today's boards and then for only a fraction of what is available.
Coreboot should be an industry norm.
Blanking the Intel ME at boot (like they are) seems like the bigger hammer to neutralize Intel problems.
Of course.
... wanted to Coreboot but he put that on pause when he realized he could brick the boards.
Unless you have a sure-fire way of recovering from a failed BIOS flash, you have to assume that you will brick it.
There's many of us in that boat.
Cheers,
A.
#1727 Re: Installation » Login problem - no mouse or keyboard » 2018-09-04 17:18:47
Hello:
... pour over the release notes in detail tonight or tomorrow morn ...
I've checked the release notes.
In particular, the part that refers to "Session management and policykit backends"
I was able to verify that my installation complies with all the requirements ie: the "recommended default
combination of login manager (either slim or lightdm) and session management system."
As to "Starting X from a console (TTY)", although I was being able to do it in the manner described ... (in spite of having consolekit and not elogind installed)
If from the grub screen I hit 'e' and add a 1 to the end of the command line and then, instead of logging in as root, I continue with the boot process ie: with ctrl-d I can do startx and get a perfectly working desktop.
... it was with the Shutdown and Restart options being greyed out, probably the effect of not having elogind installed.(?)
So I just in case, to comply with the Release Notes requisites, I installed SLiM (which I had previously removed) and reinstalled consolekit, in case it had become mucked up somehow.
The consequence was that the working desktop described above recovered the ability to Shutdown and Restart from the panel. =-)
Afterwards, looking closely at the screen output for a few reboot cycles made me aware of an issue regarding one of the services I had not been able to start.
The thread can be read here
It turns out that the service checkroot-bootclean.sh was failing to execute properly and, not seeing anything else that could have been giving me trouble, I went for it.
Being a script that apparently runs at boot and then exits (?) does not seem like a service to me, it looks more like what it is: a start up script.
No wonder querying it with service --status-all | grep -i checkroot- did not list it as running and me making a fuss over that.
Shouldn't there be a Script Starting Service with a list of scripts to check as needed?
But I digress ...
The fact was that it was being executed at boot and it was failing.
The graphical interface for Services was of no help whatsoever so I looked for the script and edited the .sh in the name. ie: *.sh -> *.old and rebooted.
Sure enough: it was the culprit.
Now I had recovered a fully working desktop.
Which meant that apparently, apt-get clean and apt-get autoclean were not at fault.
At least not this time.
But I was still getting boot time warnings about the bootclean script failing albeit with no apparent ill effects.
I tried to use chkconfig to sort that out, but could not find it: it seems to have been dropped from ASCII (I clearly recall using it in Jesse).
Then I found out about update-rc.d, which was installed.
I thought using it would clean things up for me and that would be it.
So I did update-rc.d -f /etc/init.d/checkroot-bootclean.sh remove but doing so left me without any screen output. =^/
At that point this whole thing was getting old and I was needing my dose of espresso so I decided to take the easy way out.
But I'm not too happy about that.
I went to my Timeshift folder and recovered all the rcX.d folders in /etc from last saturday's snapshot and after renaming the existing ones as rcX.old, copied the backed up versions over to /etc and that was that.
Things seem to be back to normal, whatever that is in this installation.
But I'd like to ask a couple of questions, if I may:
1. did I use update-rc.d correctly?
2. was it the proper approach to the problem at hand? ie: to clear out a script that I wanted to stop being run.
3. why can't the script be stopped with the graphical interface ie: Applications -> System -> Services = [service]
Thanks in advance.
Cheers,
A.
#1728 Re: Installation » Services start issue » 2018-09-03 23:53:46
Hello:
Almost exactly right ...
... with three different ways of ending a line ..
... line ending are characters within the files ...
Learned quite a few things today. =^)
Thank you.
Now, off to see if I can find out how to recover my Devuan installtion from whatever apt-get clean and apt-get autoclean (apparently) did to it.
Cheers,
A.
#1729 Re: Installation » Services start issue » 2018-09-03 23:01:01
Hello:
A "newline" is a character at the end of a line, and it belongs to the text of the line in the same way as space characters belong to the line, but it also is a separator between lines in the way space characters are separators between words.
I see ...
Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.
For visudo (and sudo, I guess) the (last) line must have a terminating newline.
OK.
Many editors though don't show much different for that last newline being there or not, and some editors (like vi) even force a final newline.
Presumably the editor, jed(?), that you used, lets you end the last line without a newline character.
OK.
You can check that by making a one-line file, say xxxx.txt without entering a final newline, and then view it by cat xxxx.txt, which will show the text content of the file, and then, if the final newline is missing, the next command prompt becomes joined up on the same line.
Indeed ... =-)
groucho@devuan:~$ cat nonewline.txt
this is a test file made with jed without a final new_linegroucho@devuan:~$groucho@devuan:~$ cat newline.txt
this is a test file made with jed with a final new_line
groucho@devuan:~$ ... configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained.
Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?
As you added the % character to the beginning, you also happened to get a terminating newline, presumably because you then edited the file with a different editor (eg through visudo). The fix was due to that newline, and adding the % character "merely" changed the semantics of the line.
Exactly as you say:
1.
edit user_linssid
groucho ALL=(ALL) NOPASSWD:/usr/bin/linssid[cr] <- this [cr] is the 'new line' character and % is edited out
2. Check with visudo -c
[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_dmesg: parsed OK
/etc/sudoers.d/user_linssid: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# Thank you very much for taking the time to explain this to me.
Much obliged.
Now I'm confident I'll be able to write files for /etc/sudoers.d/ as needed.
Cheers,
A.
#1730 Re: Installation » Login problem - no mouse or keyboard » 2018-09-03 21:40:10
Hello:
I suspect that autoclean might not take eudev and our customized backend options into its equation.
I see ...
And how was I to know that ...
Make sure you have the backend compatible with your DE installed.
I have a stock-out-of-the-box Devuan ASCII that began as Jessie.
Xfce and the rest came with it, nothing fancy save for the non-free Nvidia legacy 340 drivers.
And ALWAYS check what is going to be nuked BEFORE you hit enter.
Sure ...
But apt did not give me/print ou any data or warnings related to what was being nuked that I could check or heed.
I can be reckless but (I think ...) I'm a few years past being dumb. ;^D!
In any case, if I trust apt-get update, apt-get install, apt-get upgrade and apt-get dist-upgrade to do things properly and not screw up anything, it stands to reason that I should be able to trust apt-get clean, apt-get autoclean and apt-get autoremove to also do things properly.
I'll call it the TTAG (Transitive Trust Apt-Get) theory, which unfortunately has not stood up to peer scrutiny. LOL!!!
Read the release notes.
I'll pour over the release notes in detail tonight or tomorrow morn, but in the meantime I really need to recover from this unfortunate blunder.
Any suggestions as to how I can go about it?
Any additional info you need to be able to appraise the situation?
Thanks in advance,
A.
#1731 Installation » Login problem - no mouse or keyboard » 2018-09-03 21:02:46
- Altoid
- Replies: 3
Hello:
After running apt-get clean && apt-get autoclean and rebooting I was left with a totally unresponsive mouse and keyboard.
The only way out is a hard reboot.
The exact same situation repeats itself if I boot into recovery mode and try to do startx as root: I get a desktop with a totally unresponsive mouse and keyboard and needing a hard reboot to get out.
But ...
If from the grub screen I hit 'e' and add a 1 to the end of the command line and then, instead of logging in as root, I continue with the boot process ie: with ctrl-d I can do startx and get a perfectly working desktop.
This same thing (yes, I never learn) happened to me with another distribution but only now realise that is is/may be related to running apt-get clean && apt-get autoclean.
Thinking it was a initscript problem, I reinstalled the package but no cigar.
Same with xfce. I even uninstalled SLiM with the same result.
Is it possible that running apt-get clean && apt-get autoclean has cleaned in excess?
Is there a log for apt?
Running apt-get check says everything is OK, so apparently nothing is broken. (?)
There is one noticeable difference in this desktop: Shutdown and Restart options are greyed out.
Only Log Out is available as the only user in this installation.
So I have to do sudo shutdown from a terminal but it asks me for the admin PW.
Any ideas as to what I may have mucked up now? :^,
Thanks in advance.
A.
#1732 Re: Installation » Services start issue » 2018-09-03 16:06:20
Hello:
... you create a user, there is a corresponding group of the same name created, and that is the primary group for the user.
I see ...
Now user groucho in group groucho makes all the sense to me.
Thank you for taking the time to explain that. =-)
... configured in /etc/adduser.conf. (I think if you add your user with 'useradd' instead of 'adduser' you won't get that behavior and will have to define group, shell, home and whatever else yourself.) Sudo will not be confused by this.
OK.
Good to know.
And yes, I've very recently had to fix a cock-up and adduser groucho:groucho was what I used.
Almost locked myself out.
The % before sudo in /etc/sudoers is to identify sudo as a group.
Groups are prefaced with %. (See man sudoers)
Yes, that I saw.
And since I am the only user in group groucho ...
I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.... get your user out of the sudo group ...
... more than shutdown commands available, add those other commands to sudoers.d/user_shutdown.
(The name is just a name - what's inside the file determines what it does.)
OK. Now I have learned how to do that.
deluser groucho sudo will remove the user groucho from the sudo group.
If you want the user to enter a password for sudo, then remove NOPASSWD: from the line in user_shutdown.
OK.
I don't know why smartmontools won't start from command line, but I'm sure there's a good reason for it.
You can still use smartctl on the command line - it doesn't need to be running as a service for that.
If you want it to run tests automatically and/or notify you by email if there's a problem, then you need to turn it on in /etc/default/smartmontools and configure /etc/smartd.conf to do what you want.
smartmontools, sudo service and chkroot-bootclean won't start from the CLI or from the user interface.
I have not tried other unstarted services or stopping any already started service to check how far this behavious goes.
... were probably using ext2 filesystems, which are not journaled and take a lot longer to do a filesystem check.
Be glad you're not seeing those messages. =-)The filesystem is being checked at boot, but the message probably goes by too fast for you to see it.
Install bootlogd, and you can find those messages in /var/log/boot.
Yes.
bootlogd is one of the first things I installed.
PCLinuxOS did not have it available (for some reason took it out of the repo) which, for a rolling release, made little sense to me.
It's one reason I left that distro, that boat rolls far too much for what I am used to and there are not enough life vests.
You can change how frequently the filesystem checks are done by running tune2fs.
I'll check that out.
Thank you very mych for your input.
Much appreciated.
Cheers,
A.
#1733 Re: Installation » Services start issue » 2018-09-03 13:17:53
Hello:
... the fsck output, telling you that the file system hasn't been checked in X days ...
... configure by changing the boot command line.
I like to see what goes on at boot time.
It is something I learned to do in my days as a MS minion. :^,
So I have 'quiet' removed from the grub command line.
... suspect the issue is rather the absence or presence of a newline at the end of the line.
I'm sorry, I don't understand what you mean.
Thanks for your input.
Cheers,
A.
#1734 Re: Installation » Services start issue » 2018-09-03 12:10:45
Hello:
... can start and stop services.
... seems to be working fine here.
Good ...
That's a relief.
Then it's an issue with my setup.
... want the user to be able to use sudo for all commands ...
Not all, I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.
I used PCLinuxOS for a time and they have this idea (which I adhere to) about the use of sudo:
"When implementing sudo, care should be taken to limit a users entry in /etc/sudoers to the absolute minimum of specific commands needed to perform the task at hand."
To start smartmontools/smartd, edit /etc/default/smartmontools to uncomment #start_smartd=yes.
But why won't it start by using either the CLI or the graphical interface?
Both are correct ways of doing it. (?)
You don't have to start the sudo service.
Use sudo if you want, or don't use it.
It's obviously working correctly on your system.
Yes, it seems to be working OK.
There's still the issue of using % or not using % in the /etc/sudoers.d/ files but I have the feelong that it may be related to the existence of a group name matching a user name and the user belonging to that same group.
ie: user groucho belonging to group groucho.
It's all been very enlightening.
I don't know what checkroot-bootclean.sh does.
It doesn't show up in sysv-rc-conf as a service to start/stop, but there is a symlink for it to start in runlevel 1.
I see no reason to mess with it.
It's listed as a service to run in Applications -> System -> Services = [service].
From: https://unix.stackexchange.com/question … it-scripts
"The *-bootclean.sh scripts clean up files that must or should not survive a reboot: files in /var/run, /var/lock, /tmp, etc.
Checkroot-bootclean.sh runs just after the root filesystem is mounted (which can remove spurious files created under directories that will soon become mount points, such as /run and potentially /tmp)"
I found it interesting to see what it did so I wanted to start the service.
The sudo service I understood and made sense to me to have it running.
What I was really looking for was something I recall seeing years ago (ca. 2000?) in my very early (and unsuccessful) attempts to install Debian on an old laptop.
After a certain amount of days, a script would run and inform you that X days had passed since the last file system check and was now running it.
I have not seen it since in any distrbution I've tried.
Thanks a lot for your input.
Cheers,
A.
#1735 Re: Installation » Services start issue » 2018-09-03 11:32:58
Hello:
... sudo service clears that so you always get asked for a password the first time you use sudo after a reboot.
That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.
... change how long it remembers by setting timestamp_timeout in /etc/sudoers.
Setting it to 0 should make sudo always ask for a password when you use it.
OK.
It's a good idea to have another way to get to root (eg su) ...
Yes.
My installation gets to root by means of su.
... had to add a % to the line in /etc/sudoers.d/[file_name] ...
Now I do, thanks to your post. =-)
... changing groucho to %groucho should make it match members of the group called groucho instead of user groucho.
Indeed ...
That's exactly what it is doing, as there is a group called 'groucho'.
I cannot recall creating it myself, but that does not mean much. 8^/.
BTW:
Group 'groucho has Group ID 1000 and my user 'Julis Henry Marx' belongs to it.
I'll have to look into that and see where group 'groucho' came from.
I think it was created at installation time. (?)
I'll see what happens if I take myself out of it.
But then, if I am the user groucho, why didn't using groucho (instead of %groucho) work?
Could it be that there's a sort of hierachy which which sudo works?
ie: first groups matching and then users?
I have a feeling that there being a group with a name that matches a user name is confusing sudo.
ie: user groucho belonging to group groucho.
I'll try to clean this up and see how it goes.
Thank you very much for your input.
Cheers,
A.
#1736 Re: Installation » [Solved] Permisison issue with winecfg » 2018-09-03 02:48:52
Hello:
... the % always puzzled me ...
... happy to hear you worked things out.
Thank you.
Here's yet more % puzzle for you.
The correct thing to do was to add a percent sign at the beginning of the line, like this:
%groucho ALL= NOPASSWD: /usr/bin/linssid
Well ...
Not always so.
Quite happy with being able to get away with generating a file for the /etc/sudoers.d/ directory, I set about doing it again.
This time for a command I use very often: dmesg.
Since using it with sudo was inocuous, I followed my own instructions and wrote up a file called user_dmesg with this line:
%groucho ALL= NOPASSWD: /usr/bin/linssid
As you can clearly see, it has the necessary % sign at the beginning.
But visudo -c rejects it with the same argument it rejected the line which did not have the % sign at the beginning.
On a whim, I removed the % sign and ....
It worked!
[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_dmesg: parsed OK
/etc/sudoers.d/user_linssid: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# And just why would this be so?
The only answer that I can come up with is that the use of the % sign is directly related to the path of the command to run with sudo.
ie:
/bin/dmesg <-- this command does not need the % sign.
/usr/bin/linssid <-- this command does need the % sign.
/sbin/shutdown <-- this command does not need the % sign.
So maybe it's that the files in the /etc/sudoers.d/ need a line with a % sign at the beginning if the command is in the /usr path.
I have not found any documentation on this (the syntax for these files) but given the need to be able to adequately restrict the use of sudo, it would be nice to be able to do it properly.
Any further info would be appreciated.
Thanks in advance,
A.
#1737 Re: Installation » [Solved] Permisison issue with winecfg » 2018-09-02 16:26:18
Hello:
The I ran a check with visudo -c to see if it was OK ...
[root@devuan groucho]# visudo -c >>> /etc/sudoers.d/user_linssid: syntax error near line 1 <<< parse error in /etc/sudoers.d/user_linssid near line 1 [root@devuan groucho]#... but it was not.
I do not understand the error near line 1: there's only one line and it is practically the same as the one in user_shutdown.
Am I doing something wrong or is editing with jed the problem?
Indeed ...
But just how was I to know what I was doing wrong?
The existing file in /etc/sudoers.d was copied exactly and properly edited with visudo.
And still ...
OK.
The solution ended up being this: ---> %
The line that makes up any file you want to add to the /etc/sudoers.d/ directory (apparently) has to be preceded by a percent (%) sign.
Otherwise it will not work.
I have not been able to find a place where the syntax for these files is explained.
This example I posted above was wrong:
To do this I opened the file with jed and saved it as user_linssid and edited it with jed so that ...
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
... becamegroucho ALL= NOPASSWD: /usr/bin/linssid
The correct thing to do was to add a percent sign at the beginning of the line, like this:
%groucho ALL= NOPASSWD: /usr/bin/linssid
I found out about this by reading this post: https://askubuntu.com/questions/930768/ … sodoers-fi.
And although it makes no mention of the percentage sign thing, I saw that a line in a /etc/sudoers.d file used it.
So I tried it and it worked. =^º
[rant mode]
How could I have possibly known this if the existing /etc/sudoers.d/users_shutdown file reads like this:
[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot <-- just [u]where[/u] is the % sign?
[root@devuan groucho]# And if using visudo to look at it shows me the exact same string of characters?
I mean, where is the f***ing percent sign?
[/rant mode]
Moral of the story:
Want to make a /etc/sudoers.d/file to avoid mucking up (very easy to do) the sudoers file?
1. copy an existing one.
2. edit it with visudo.
ie:
visudo -f /etc/sudoers.d/[file_name]3. make sure that you add a % sign at the start of the line.
4. save it with the intended name eg: user_whatever so you'll know what it is for.
5. make sure the file has 440 permissions.
ie:
[root@devuan groucho]# chmod 440 /etc/sudoers.d/[file_name]
5. check it all with visudo -c
[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_whatever: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# Of course, remember that you have to be a member of the sudoers group otherwise this is all moot.
Caveat: I'm no expert and WRT Linux I'm sort of playing by ear, so if any of the Devuan forum members with experience could take a minute to check that all this is not hogwash or has any errors, I'd be very obliged.
Cheers,
A.
#1738 Re: Installation » Services start issue » 2018-09-01 22:43:57
Hello:
... looks like all that script does is change the time stamp on /var/lib/sudo.
It's rather over my head but if it's to prevent sudo permissions from surviving a reboot it would not have to do much more. (?)
... only command it takes is 'start'.
... (stop|restart|whatever) do nothing.
But I have at least three services that are not starting with the graphic interface or with the command line in a terminal.
... your user is in the sudo group, you should be able to use sudo with your password for all commands.
Hmmm ...
That I don't like.
I can at times be hasty and distracted (maybe it's age?) and recognise the need to be called to attention: requiring me to enter an admin PW does that.
I don't mind being able to run sudo for a selected few commands but not all/any commands.
... safe like sudo blkid to see if that works.
groucho@devuan:~$ sudo blkid
[sudo] password for groucho:
/dev/sda1: UUID="1ACC-311B" TYPE="vfat" PARTUUID="000e0731-01"
--- snip ---
groucho@devuan:~$ It asks for a PW.
Probably because there isn't a dedicated file for that action in /etc/sudoers.d?
BTW: I have tried to create a working file there for tesing purposes but have failed, visudo -c does not like it..
See my other thread (where I split this one from).
What I don't understand is why user_shutdown works when the includedir directive in /etc/sudoers is commented out.
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALLIt is commented with a percent sign (%) instead of a number/pound sign (#)?
It's commented out in mine, too, but I can shutdown using sudo without password.
I can also ...
My guess is that it is because of the /etc/sudoers.d/user_shutdown file.
If so, % is not being used to comment a line.
But what is it for? (what's the sysntaxis?)
... also getting the same results as you for 'service --status-all' - it doesn't change when I try to start sudo.
OK ...
At least I have not screwed something up. 8^º
Can you start other unstarted services?
Maybe that's because sudo runs and then exits after it changes the time stamp.
No idea ...
But (from what I can understand) the issue goes further: I want to start a service and it will not start by any one of the two known methods.
Does not look right.
I ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.
I suspect a problem somewhere. (?)
I also see the same problem in the Miyo Linux installation I have on another drive/same hardware.
Thanks for your input.
Cheers,
A.
#1739 Installation » Services start issue » 2018-09-01 20:26:30
- Altoid
- Replies: 15
Hello:
I run an up-to-date Devian ASCII:
groucho@devuan:~$ uname -ap
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
groucho@devuan:~$
groucho@devuan:~$ suThere seems to be a problem with the starting of (some?) services.
I ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.
The services are checkroot-bootclean.sh, smartmontools and sudo.
So I try to start them from a TTY (just two for brevity's sake)
1. Check they are not already running:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# service --status-all | grep smartmontools
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] smartmontools
[root@devuan groucho]#2. Start them as root:
[root@devuan groucho]# service sudo start
[root@devuan groucho]# service smartmontools start3. Check if they have started:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# service --status-all | grep smartmontools
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] smartmontools
[root@devuan groucho]# This is a thread split from another one with a similar (?) issue here: https://dev1galaxy.org/viewtopic.php?id=2337.
My installation uses su to get root and my user is included in the sudo group.
[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
[root@devuan groucho]# groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ I can sudo shutdown, sudo reboot, etc. as permitted by /etc/sudoers.d/user_shutdown.
[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
[root@devuan groucho]# Any idea as to what is happening with services.?
Thanks in advance,
A.
#1740 Re: Installation » [Solved] Permisison issue with winecfg » 2018-08-31 10:36:03
Hello:
... man page for sudoers.
... options include timestamp_timeout which sets how often it asks ...
Thanks ... =-)
The timestamp feature could be overkill, even for me. LOL
... EDITOR=jed visudo which should let you edit /etc/sudoers with jed and have it checked.
Great ...
The checking feature is really nice to have.
But I've discovered sudo service which I did not know about.
Seems to be more suited to my use than a timestamp.
# make sure privileges don't persist across reboots
---------------------------------------------------------------------------------
EDIT: I have started another thread for this specific issue here https://dev1galaxy.org/viewtopic.php?id=2342
I have it ticked in Applications -> System -> Services = sudo.
But for some reason it won't start:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho][root@devuan groucho]# service sudo start
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# Edit:
I have discovered that it's not only Applications -> System -> Services = sudo that does not start even though it I marked it.
The other services I marked (smartmontools and checkroot-bootclean.sh) also fail to start.
The services utility asks me for the admin PW and nothing else. ie: does not reject my credentials.
---------------------------------------------------------------------------------
To practise and learn about sudo, I had a look at the file in /etc/sudoers.d/user_shutdown to make one exactly like it for LinSSID and not have to muck around with editing the sudoers file which is dangerous, as I found out for myself. (many thanks to Timeshift!).
To do this I opened the file with jed and saved it as user_linssid and edited it with jed so that ...
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
... became
groucho ALL= NOPASSWD: /usr/bin/linssid
I saved the file and gave it 0440 permissions which I have read is a must for files in sudoers.d:
[root@devuan sudoers.d]# chown 0440 user_linssid
[root@devuan sudoers.d]# The I ran a check with visudo -c to see if it was OK ...
[root@devuan groucho]# visudo -c
>>> /etc/sudoers.d/user_linssid: syntax error near line 1 <<<
parse error in /etc/sudoers.d/user_linssid near line 1
[root@devuan groucho]# ... but it was not.
I do not understand the error near line 1: there's only one line and it is practically the same as the one in user_shutdown.
Am I doing something wrong or is editing with jed the problem?
Thanks in advance.
A.
#1741 Re: Installation » [Solved] Permisison issue with winecfg » 2018-08-30 20:00:34
Hello:
I was just about to post.
I managed to get things working with PMail.
The problem was that I had added myself the the sudo group but had not logged in again. :^ '
Wasn't going to get anywhere that way.
My *.desktop file for PMail is this ...
[Desktop Entry]
Type=Application
Name=PMail
Exec=wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe
MimeType=application/x-ms-dos-executable;application/x-msi;application/x-ms-shortcut;
Icon=/home/groucho/pmail_32x32x32.png
NoDisplay=true
StartupNotify=true
GenericName=PMail32
Comment=
Terminal=false
Path=... and it works as intended.
Look in /etc/sudoers ...
[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
[root@devuan groucho]# Seems it's like you say.
... run visudo as root to add it (visudo edits a copy of /etc/sudoers with vi, then syntax checks your changes and copies it back if they are OK).
I have tried in the past to get around vi but I've found it very complicated to use.
I'm afraid I'm 20+ years late to that party, I learned the ropes with the early DOS 5.0 editors.
After trying three or four Linux CLI editors, I have finally settled on jed, it works for what I need to do.
Then try sudo -l to list what sudo will let you do. And sudo -i to get to a root shell.
groucho@devuan:~$ sudo -l
Matching Defaults entries for groucho on devuan:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User groucho may run the following commands on devuan:
(ALL : ALL) ALL
(root) NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
groucho@devuan:~$ groucho@devuan:~$ sudo -i
[sudo] password for groucho:
[root@devuan ~]# It works ... =-)
Just in case:
groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ id
uid=1000(groucho) gid=1000(groucho) groups=1000(groucho),4(adm),20(dialout),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),102(netdev),109(lpadmin),111(scanner)
groucho@devuan:~$ One thing:
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALLI don't want to be able to do anything with sudo, I would like to strictly limit what I can do as a member of the sudo group.
This ALL=(ALL:ALL) ALL seems (to me) rather excessive.
How can this be effectively limited without hampering the use of the OS?
Thank you very much for your input.
Cheers,
A.
#1742 Installation » [Solved] Permisison issue with winecfg » 2018-08-30 13:31:25
- Altoid
- Replies: 9
Hello:
I'm trying to set up Wine in my Devuan ASCII installation but I seem to have run into a problem related to permissions.
When I installed Devuan ASCII, I selected to use su and not sudo.
I see it as a sort of insurance from myself and the possibility of getting distracted and inadvertently wreaking havoc.
ie: this way I will always be reminded that whaever I am doing requires elevated privileges and will get them by entering the root PW.
But while I undertstand that this is not practical for some things, I have managed to get around the problem it brings up.
eg: to run LinSSID from a .desktop file, the command will be gksu linssid instead of the default gksudo linssid.
I don't mind having to enter a PW for an app I don't use a lot.
Now, when I run winecfg I am not able to set up the drives:
groucho@devuan:~$ winecfg
err:winecfg:open_mountmgr failed to open mount manager err 2
err:winecfg:open_mountmgr failed to open mount manager err 2
groucho@devuan:~$ If I run it with sudo, I get this:
groucho@devuan:~$ sudo winecfg
[sudo] password for groucho:
Sorry, user groucho is not allowed to execute '/usr/bin/winecfg' as root on devuan.
groucho@devuan:~$ My user is in the sudo group.
And if I run it as root, it creates a configuration directory in /root ...
[root@devuan groucho]# winecfg
wine: created the configuration directory '/root/.wine'
---
other stuff err: follows.
[root@devuan groucho]#... which will most probably (?) have the effect of needing to be root to run programs under Wine.
Is there a way to set up sudo on a per-application basis ...
ie: so that sudo will work with a select list of apps, like Wine and LinSSID.
... or am I going about this the wrong way?
Thanks in advance,
A.
#1743 Re: Installation » Timeshift 18.8 and Devuan ASCII » 2018-08-27 19:24:33
Hello:
... found it too complicated.
... tried about 5 restores and one of them failed
Yes, I know that it will render any legacy grub system unbootable.
I have had good comments after introducing it into the PCLinux forum.
... recommend partclone ...
... simple and has never let me down ...
... creates a compact image of your partition ...
I think I looked at it but the Timeshift convinced me because of it being automatic and scheduling, etc.
Seems to be much like Norton Ghost-DOS, which I used a lot when I was prisoner of the MS camp. =-)
It worked great most of the time.
... none of this answers your question, but I thought I'd share ...
On the contrary, thank you very much for taking the time to write and share your opinion/experience.
That's what this is all about, no?
Cheers,
A.
#1744 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2018-08-27 12:37:46
Hello:
There's no one here that can shed some light on this?
Thanks in advance.
A.
#1745 Installation » Timeshift 18.8 and Devuan ASCII » 2018-08-26 23:13:07
- Altoid
- Replies: 3
Hello:
I'm needing a system restore app and, having used it on other distros, was wondering if anyone here has installed Timeshift.
TimeShift
https://launchpad.net/timeshiftTimeShift for Linux is an application that provides functionality similar to the System Restore feature in Windows and the Time Machine tool in Mac OS. TimeShift protects your system by taking incremental snapshots of the file system at regular intervals. These snapshots can be restored at a later date to undo all changes to the system.
Snapshots are taken using rsync and hard-links. Common files are shared between snapshots which saves disk space. Each snapshot is a full system backup that can be browsed with a file manager.
TimeShift is similar to applications like rsnapshot, BackInTime and TimeVault but with different goals. It is designed to protect only system files and settings. User files such as documents, pictures and music are excluded. This ensures that your files remains unchanged when you restore your system to an earlier date. If you need a tool to backup your documents and files please take a look at the excellent BackInTime application which is more configurable and provides options for saving user files.
These are the links:
https://github.com/teejee2008/timeshift
https://github.com/teejee2008/timeshift … stallation
https://github.com/teejee2008/timeshift/releases
A *.RUN installer which I have never used before is available for download.
Will it work properly (thinking dependencies and such) with Devuan ASCII?
Thanks in advance.
A.
#1746 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-08-25 23:26:12
Hello:
No problem.
=-)
... if someone did, they might discover that, say, the CPU firmware (intel-microcode pkg) requires the *presence* of the mei mods ...
Yes, that crossed my mind.
... check out the links to the ME disabling how-tos?
Yes.
But these days I'm wary of any BIOS tinkering.
It's not so easy to recover from a bad burn these days.
24+ years ago, I'd be always ready to risk a mobo for the sake of experimenting with a modded BIOS file.
The half dozen times that things went south I recovered the hardware by hot-plugging the roach into a similar board to reflash it with the original saved file.
But I'm on a Sun Ultra24 Workstation now and it's enough that the last available BIOS (1.56) is quite buggy.
It actually reports the unit as 'portable' among other assorted issues.
... each of us has to consider the work in securing the OS ...
My idea is that you have to start with what you have control over ie: the OS and it's kernel.
We'll never have control/full knowledge over what is inside the chipset or the CPU.
Who would have thought just three or four years ago that this ME thing actually existed or was even possible to get away with?
A fully operational and independent OS hidden inside the mobo's chipset, ready to start up and run without any evidence in user space or traces left behind.
And I'm convinced that we don't know the half of it ...
Thanks for taking the time to write back.
Cheers,
A.
#1747 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-08-25 13:53:48
Hello:
We use the debian kernels, unchanged.
The only packages from debian that get changed are the ones that depend on systemd.
OK.
I see ...
The Debian kernel has mei built into it.
Is it at all necessary?
I had the idea that Devuan maintainers built the kernel from the source code.
The same way that some people build their own custom kernels.
Thanks for your input.
A.
#1748 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-08-25 11:43:22
Hello:
Why is the Devuan kernel loading the IME module?
It's not Devuan or a distro. It's part of the kernel.
OK.
But I suppose that (like many other things in the kernel) it can be built with or without mei.
With respect to it not being present in the latest kernel, my apologies:
It happens I made a rather embarrasing mistake. =^/
I had not done an updatedb prior to the search so the files did not show up as I do not have updatedb set up to run at every boot.
It happens that they are there, sorry for the blunder.
[root@devuan groucho]# updatedb
[root@devuan groucho]# locate mei
---
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/media/rc/keymaps/rc-gadmei-rm008z.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
---
/usr/include/linux/mei.h
---
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-7-common/include/linux/mei_cl_bus.h
---
/usr/src/linux-headers-4.9.0-7-common/include/uapi/linux/mei.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-8-common/include/linux/mei_cl_bus.h
---
/usr/src/linux-headers-4.9.0-8-common/include/uapi/linux/mei.hIntel's stated purpose:
Intel Management Engine Interface (Intel MEI)
Yes, I've read it.
I have successfully blacklisted the mei modules so that they will not load at boot time:
https://dev1galaxy.org/viewtopic.php?pid=5782#p5782
But this is just to keep the module from loading at boot time.
As you know it can be eventually loaded by an application or manually as root:
[root@devuan groucho]# lsmod | grep -i mei
[root@devuan groucho]# modprobe mei
[root@devuan groucho]# lsmod | grep -i mei
mei 102400 0
[root@devuan groucho]# The ideal situation would be that these modules were not in the kernel.
But what I'd like to know is why the Devuan maintainers build the kernel with mei in it.
I have not seen much on the web that says how useful it is.
An then, I'd also like to know what (if any) are the benefits of doing so.
I have the idea that the Devuan forum is not the usual run-of-the mill linux forum (in comparison to say Ubuntu/Mint/etc.)
I think that those of us who have chosen to move to Devuan from Debian or other systemd centric distributions are a bit more 'into-it' so it seems rather odd to me that it is just us two talking about this here, more so if we take into account all that has transpired wrt the Intel Management Engine.
In any case, I have blacklisted the mei modules and have not seen/detected (apparently and for the moment) any ill effects.
But it's still too early to say for sure.
Thank you very much for your input.
A.
#1749 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-08-24 15:34:40
Hello:
... unloaded the mods and nothing happened.
... removed and blacklisted those mods.
Thanks for the links.
I'm more or less up-to-date wrt this.
But my questions remain:
1.
Why is the Devuan kernel loading the IME module?
What is it necessary for and in what environment?
2.
Why is the module present in the kernel files for 4.9.0-7-amd64 but not for 4.9.0-8-amd64?
Not being in the 4.9.0-8-amd64 kernel files, how is it that it is still being loaded by a running 4.9.0-8-amd64 kernel?
3.
How is it being loaded and how can this be prevented in Devuan ASCII and the upcoming kernels?
Thanks in advance,
A.
#1750 Installation » Intel Management Engine module in Devuan ASCII » 2018-08-24 01:46:29
- Altoid
- Replies: 12
Hello:
While checking out the list of errors in /var/log/syslog on another distro (PCLinuxOS), I came across something that caught my eye.
At first I thought it would be something to do only with PCLinux but then I decided to see if it was the same case with Devuan ASCII:
groucho@devuan:~$ lsmod | grep mei
mei_me 36864 0
mei 102400 1 mei_me
groucho@devuan:~$ ... just to see what would happen, tried to remove it:
[root@devuan groucho]# rmmod mei
rmmod: ERROR: Module mei is in use by: mei_me
[root@devuan groucho]# As expected, removing mei_me before removing mei worked and nothing much happened.
I was not sure but it sounded like it was the infamous Intel IME, so I asked:
[root@devuan groucho]# modinfo mei
filename: /lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei.ko
license: GPL v2
description: Intel(R) Management Engine Interface
author: Intel Corporation
depends:
retpoline: Y
intree: Y
vermagic: 4.9.0-8-amd64 SMP mod_unload modversions
[root@devuan groucho]# I also asked about what module used it, and I got this:
[root@devuan groucho]# modinfo mei_me
filename: /lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei-me.ko
license: GPL v2
description: Intel(R) Management Engine Interface
author: Intel Corporation
alias: pci:v00008086d0000A2BBsv*sd*bc*sc*i*
alias: pci:v00008086d0000A2BAsv*sd*bc*sc*i*
alias: pci:v00008086d00005A9Asv*sd*bc*sc*i*
alias: pci:v00008086d00001A9Asv*sd*bc*sc*i*
alias: pci:v00008086d0000A1BAsv*sd*bc*sc*i*
alias: pci:v00008086d0000A13Bsv*sd*bc*sc*i*
alias: pci:v00008086d0000A13Asv*sd*bc*sc*i*
alias: pci:v00008086d00009D3Bsv*sd*bc*sc*i*
alias: pci:v00008086d00009D3Asv*sd*bc*sc*i*
alias: pci:v00008086d00009CBBsv*sd*bc*sc*i*
alias: pci:v00008086d00009CBAsv*sd*bc*sc*i*
alias: pci:v00008086d00008CBAsv*sd*bc*sc*i*
alias: pci:v00008086d00009C3Asv*sd*bc*sc*i*
alias: pci:v00008086d00008D3Asv*sd*bc*sc*i*
alias: pci:v00008086d00008C3Asv*sd*bc*sc*i*
alias: pci:v00008086d00001DBAsv*sd*bc*sc*i*
alias: pci:v00008086d00001CBAsv*sd*bc*sc*i*
alias: pci:v00008086d00001E3Asv*sd*bc*sc*i*
alias: pci:v00008086d00001D3Asv*sd*bc*sc*i*
alias: pci:v00008086d00001C3Asv*sd*bc*sc*i*
alias: pci:v00008086d00003B65sv*sd*bc*sc*i*
alias: pci:v00008086d00003B64sv*sd*bc*sc*i*
alias: pci:v00008086d00002E34sv*sd*bc*sc*i*
alias: pci:v00008086d00002E24sv*sd*bc*sc*i*
alias: pci:v00008086d00002E14sv*sd*bc*sc*i*
alias: pci:v00008086d00002E04sv*sd*bc*sc*i*
alias: pci:v00008086d00002A74sv*sd*bc*sc*i*
alias: pci:v00008086d00002A64sv*sd*bc*sc*i*
alias: pci:v00008086d00002A54sv*sd*bc*sc*i*
alias: pci:v00008086d00002A44sv*sd*bc*sc*i*
alias: pci:v00008086d000028F4sv*sd*bc*sc*i*
alias: pci:v00008086d000028E4sv*sd*bc*sc*i*
alias: pci:v00008086d000028D4sv*sd*bc*sc*i*
alias: pci:v00008086d000028C4sv*sd*bc*sc*i*
alias: pci:v00008086d000028B4sv*sd*bc*sc*i*
alias: pci:v00008086d000029F4sv*sd*bc*sc*i*
alias: pci:v00008086d000029E4sv*sd*bc*sc*i*
alias: pci:v00008086d000029D4sv*sd*bc*sc*i*
alias: pci:v00008086d000029C4sv*sd*bc*sc*i*
alias: pci:v00008086d000029B4sv*sd*bc*sc*i*
alias: pci:v00008086d00002A14sv*sd*bc*sc*i*
alias: pci:v00008086d00002A04sv*sd*bc*sc*i*
alias: pci:v00008086d000029A4sv*sd*bc*sc*i*
alias: pci:v00008086d00002994sv*sd*bc*sc*i*
alias: pci:v00008086d00002984sv*sd*bc*sc*i*
alias: pci:v00008086d00002974sv*sd*bc*sc*i*
depends: mei
retpoline: Y
intree: Y
vermagic: 4.9.0-8-amd64 SMP mod_unload modversions
[root@devuan groucho]# I'm running the last available ASCII kernel:
groucho@devuan:~$ uname -ap
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
groucho@devuan:~$ All this is the exact same behaviour as in PCLinuxOS with the 4.17.15 kernel.
I'm aware that the only real way to get rid of the IME problem seems to be a complete BIOS overhaul and even then it may be useless as it seems to live inside the chipset. I connect to the web through a WiFi router but I don't think it is much of a barrier.
What I don't understand is the loading of the module by the kernel or even its presence in the filesystem.
I have noticed that it does not seem to be present in the 4.9.0.8 kernel files but as I have noted above, it is being loaded and I can unload it:
groucho@devuan:~$ lsmod | grep mei
mei_me 36864 0
mei 102400 1 mei_me
groucho@devuan:~$ su
Password:
[root@devuan groucho]# rmmod mei_me
[root@devuan groucho]# rmmod mei
[root@devuan groucho]# exit
exit
groucho@devuan:~$ lsmod | grep mei
groucho@devuan:~$ .
groucho@devuan:~$ locate mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
---
/usr/include/linux/mei.h
---
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-7-common/include/linux/mei_cl_bus.h
/usr/src/linux-headers-4.9.0-7-common/include/uapi/linux/mei.h
groucho@devuan:~$ Does it have a specific purpose, is it actually needed for something in a desktop (or any other) machine?
Seeing that it is not in the 4.9.0.8 kernel files, how it is getting loaded?
I'd appreciate someone with more experience explaining what is happenning and why mei is present in Devuan.
Thanks in advance.
G.
Board footer
