Hello:

Thanks for the fast reply. :^ )

I see.
I would have thought it was read from 'somewhere' in the filesystem.

Not to mention that the issue would rise once again on an update of said binary.

Done.
Not what I sought to do but it works.

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep -i ww
[   509.446] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   509.447] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   509.447] (WW) Disabling Keyboard0
[   509.447] (WW) Disabling Mouse0
[   509.500] (WW) Unresolved symbol: fbGetGCPrivateKey
[   509.500] (WW) NVIDIA: The Composite and Xinerama extensions are both enabled, which
[   509.500] (WW) NVIDIA:     is an unsupported configuration.  The driver will continue
[   509.500] (WW) NVIDIA:     to load, but may behave strangely.
[   509.500] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the
[   509.500] (WW) NVIDIA:     X server.
[   510.975] (WW) NVIDIA(0): Not registering RandR
[   511.046] (WW) NVIDIA(1): Not registering RandR
[   511.174] (WW) NVIDIA(2): Not registering RandR
groucho@devuan:~$

groucho@devuan:~$ cat /var/log/Xorg.0.log | grep fonts
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/cyrillic,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
groucho@devuan:~$ 

Nah !

I fully agree that the warning is indeed harmless.
But I am one of those people that opine that if the warning is there, it is because whoever wrote the routine thought it best to put it there and label it as a warning (WW) and not as default setting (==), for example. So it should be taken care of.

These things are like dust: harmless but eventually they pile up too high and then they clog up something.

We're always bitching when some routine goes south and there's no indication of what went on.

Thanks for your input.

Cheers,

A.

Hello:

Welcome and thank you. :-)

OK.
Nice sampling.

Seems something common then?

I went Ubunbtu -> Mint --> CrunchBang --> PCLinuxOS, allways two at the same time and got here for the same reasons with the exception of # ! which Newborough (developer) gave up on. 

So I plan to stay here for the long run.

Same here.

But there's a problem at boot time, right before the desktop comes up: on two of my three monitors I get artifacts made up of a sort checkerboard type design in black, grey and white square/rectangular portions of different sizes which last a few seconds.

Apparently no big deal but it is rather annoying.

I think it is (?) a problem with the package or the driver version used in the package because I did not get them (error in dmesg or artifacts) when I ran PCLinuxOS on this same rig. ie: exactly the same hardware but using Mate instead of Xfce.

Do you get any artifacts like the ones I am attempting to describe?
Maybe it's an issue due to the three monitor setup?

Ideally it would be good to know the origin of the error and act upon that.

Thank you very much for your input.

Cheers,

A.

Hello:

Well ...

1.

2.
Once I found out that the one I wanted was Firefox-55.0.glibc2.3.4-x86_64, I went looking for it but the repo jumps from 52.9 to 60.4.

That's about it.

Cheers,

A.

Hello:

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)

... 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.

Hello:

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.

OK.

OK.

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:~$ 

Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?

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.

Hello:

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.

I'm sorry, I don't understand what you mean. 

Thanks for your input.

Cheers,

A.

Hello:

That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.

OK.

Yes.
My installation gets to root by means of su.

Now I do, thanks to your post.   =-)

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.

Hello:

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:

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:

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.