Hello:

@Rolfie

But it does ...

$ ls -l /etc/machine-id
-r--r--r-- 1 root root 33 Dec 13  2017 /etc/machine-id
$ 

And then the patch does not work.

@greenjeans

Right ...

I knew which one you were referring to because I had both seen it and remembered that I had seen it.
But, as you can gather *...

See the date and the attributes?
It has probably been there since my first Devuan Linux installation, Jesse.
The patch evidently did not act on an existing machine-id and so it remained static.

I'll nuke it, see what happens after a few reboots and report back, later or early tomorrow.

Sorry about the distraction. 8^/

Best,

A.

Hello:

Just checked my 1000HE netbook running Beowulf with a backported kernel.
Was never upgraded because I fear for my coffee roasting software.

Did not bother to count how many after I saw that the third MC screen passed by.
Must have been 600+ files which I promptly nuked, but it is just a guess.

Curiously enough, I never came across any line in dmesg (or other logs I look at) saying something about this in any one of my boxes, ever.
eg:

[000.0000] generating random machine-id

or

[000.0000] generating random machine-id failed - old machine-id used

Methinks that the patch applied to ASCII never really worked and if it did, it did so for just a short while or only in ASCII.
Not being something that would make a light blink (so to speak) it just laid there, dormant.
And nobody ever checked.

Till @greenjeans.  8^)

Best,

A.

Hello:

I thought as much, asked to verify.

Yes?
I don't see that happening.
ie: /etc/default/dbus is set to IDTYPE="RANDOM"  (see my previous post)
And it seems that I am not the only one.

Any idea why?
Is there a bug/problem to be addressed somewhere in my  system Devuan?
If so, it has been there since (at least) Jesse ASCII*.

*The dbus patch to generate new dbus machine-id on boot was added in ASCII.

Best,

A.

Hello:

Maybe, not necessarily.
At least not yet. 8^°

Which begs the following question:
In whose interests or (better yet, to what end) does my box/system need to have a unique machine-id.
ie: my machine-id seems to have been set long ago and it has not changed (much like your own situation) since 17/10/2018.

Best,

A.

Hello:

Why?

Not if it is (as you have mentioned) working properly.
ie: renewing the files on every boot.

Still, I did have those two very old files.

I rebooted after nuking the vintage files and the system replaced the previous valid one with a new one.
ie: just one file with the proper boot time/date present.

Lately I have mentioned that my present system ie: Daedalus started off as Jesse and from the date of the oldest file I found in the root didrectory, that would have been back in 2017.

Makes sense, my first post here is from that year.

The fact that this box has seen a succession of dist-upgrades, with all but one (a Beowulf to Chimaera nightmare) being reasonably smooth may have to be taken into account to evaluate this find.

Could it be that there was a change (or introduced bug) in how dbus managed those files and my system (at some point) retained a previous configuration? No idea, just a guess.

Let me know if you need more data.

Best,

A.

Hello:

You will not find a package named windscribe in the Debian repositories:
See https://packages.debian.org/search?keyw … ection=all

Devuan is just Debian without systemd so, save for packages which need systemd to run and cannot be adapted to run without it, all the packages in the Devuan repositories are from the Debian repositories.

That being the case, you will not find package named windscribe in the Devuan repositories either:
See https://pkginfo.devuan.org/cgi-bin/poli … e&x=submit

TL;DR:
If the windscribe package you have installed needs systemd to run, it will not work in Devuan.

You may want to consider asking the package developers / maintainers to see which options are available to you if using a non-systemd distribution.

Best,

A.

Hello:

You're welcome.

Can happen, but provided you followed instructions, it should have been more or less straightforward, albeit keeping in mind that it is still in-development.

I want my WS to be stable and reliable above all things, so I stay away from dist-upgrades for as long as I can.
ie: only after all wrinkles have been straightened out and even then after careful consideration.

This Sun U24 WS is ca. 2007 and my Devuan system started off as Jesse in 2017, upgraded only as necessary.
Excalibur is a threshold I may not cross, Daedalus is already fat enough.
Jury is still out on that and what to do.

Please do, Devuan maintainers are understaffed and overworked.
They need all the help we can give them.

The dmesg printout will most probably give you the first clues, there should be something pointing to your shares not being found or something such.

If not, it could be because the system is not looking for them so that could/would be a config issue.

eg: this is a sample of my dmesg printout on boot:

$ sudo dmesg | grep mounted
[   24.743697] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none.
[   26.341730] EXT4-fs (sdb1): re-mounted. Quota mode: none.
[   27.749364] EXT4-fs (sdb5): mounted filesystem with ordered data mode. Quota mode: none.
[   27.751511] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Quota mode: none.
[   27.775098] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Quota mode: none.
[   27.793504] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Quota mode: none.
[   27.834654] EXT4-fs (sda2): mounted filesystem with ordered data mode. Quota mode: none.
[   27.882843] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
$

Your box/laptop is undoubtedly mounting the file system in the main drive and that will show up in the printout.
I expect that your shares not being mounted or not found should also show up.

Just a guess.

Best,

A.

Hello:

Up to four (maybe more? if your card/s have the outputs/memory.

I use three 19" monitors @1280*1024 (3840*1024 desktop) fed from a pair of Nvidia Quadro FX 580 cards.

$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1024, maximum 8192 x 8192
--- snip ---
$

For a short time installed a fourth 15" monitor just to see if/how it worked, took it down for lack of space.
No serious problems save some artifacts in the centre monitor which the Nvidia driver did not have.

@greenjeans

Yes, it was a hassle.
But once you got it down pat, it worked perfectly well.

To wit:
Once I managed to write up a properly working xorg.conf for the first Linux distribution I tried, first with two and then with three monitors (cannot recall which) it was just a question of transplanting it to all the other distributions I tried out without having to touch it: it just worked® in all of them, including my first Devuan (Jesse) and so on with Devuan till the demise of the 340XX driver in Chimaera.

The only problem I see with nouveau is that it seems impossible to see under the hood, so to speak.
ie: just what is the layout of the xorg.conf file I am using now?

That should not be so as the configuration file, if it exists, gets priority.

Best,

A.

Hello:

I once had a question about this.

TL;DR
It seems that, using nouveau, you do have to have firmware-nvidia-graphics installed, whether you need it or not.
Otherwise you get some bitching in dmesg.
ie: if you use nouveau but your specific Nvidia hardware is not on that list (~4.5mmb on disk), you obviously do not need those firmware files in your system.

See here: https://dev1galaxy.org/viewtopic.php?pid=51169#p51169

Best,

A.

Hello:

Hmm ...
Password managers might be are very attractive targets to compromise.

There you go.

Best,

A.

Hello:

Not the right media to use for a test unless you are absolutely certain than you can read it in any other drive.

Consider using an OEM written media to test the drive.

Have you checked the dmesg printouts?

A.

Hello:

From the linked screen capture, it would seem that the hardware is working.

Just in case, boot the box without the optical drive plugged in, plug it in and check the dmesg printout.
If the drive is correctly recognised by the system and no errors are reported, it would mean that it is not a Devuan issue.

If the drive is working properly, the problem would lie either with the media or with the laser optic itself.
Check with a known/working factory stamped (readable) CR-ROM or DVD to rule out the media being bad.

Q: can you hear the drive spin when you load a DC/DVD? What does the dmesg printout say?

If the problem is the laser optic, it may come down to something as simple as a dirty lens or a more complicated issue like eg: a damaged laser assembly or a power problem*.

A properly working drive should recognise the media it was designed for.

Check here for the manual and specs for that drive (SH-S162L?).
https://samsung.manymanuals.com/optical … nual-14158    <- see page #32 of the manual

Best,

A.

* From a a fast look at the manual, it would seem that the drive is an internal ATA/ATAPI (E-IDE) model (?). ie: needs both 12v and 5v power.

It could be that whatever adapter you are using is not providing enough power for the laser to read properly.