You are not logged in.
Hello:
Unfortunately the problem remains.
But I have discovered something, quite odd at that.
Like I mentioned, when I try to start Pegasus Mail from a terminal (ie: as the logged in user), I get this:
~$ wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe
0024:err:module:import_dll Library sechost.dll (which is needed by L"C:\\windows\\syswow64\\advapi32.dll") not found
--- snip ---
0024:err:module:import_dll Library user32.dll (which is needed by L"C:\\windows\\syswow64\\start.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"C:\\windows\\syswow64\\start.exe" failed, status c0000135
~$ Also happens when I try to start winecfg (ie: as the logged in user):
~$ winecfg
0024:err:module:import_dll Library sechost.dll (which is needed by L"C:\\windows\\syswow64\\advapi32.dll") not found
--- snip ---
0024:err:module:import_dll Library user32.dll (which is needed by L"C:\\windows\\syswow64\\start.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"C:\\windows\\syswow64\\start.exe" failed, status c0000135
~$But when I try to start wine, (ie: without specifying PROGRAM [ARGUMENTS ... ] I get this:
~$ wine
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
wine --help Display this help and exit
wine --version Output version information and exit
~$ So I tried both with privileges (ie: sudo) and it worked.
~$ sudo winecfg gets me the Wine configuration window (for Drives/Audio/Applications/Libraries/Graphics/ Desktop Integration) pop-up.
~$ wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe gets me the Pegasus Mail start up window asking me for my username, something I have never had to use.
But then I have never ran Pegasus Mail as root.
I cannot make out if this is a permissions or ownership problem, but it does not look like it is a Wine problem as seems to it work if I try to start it as root.
Edit: absoultely everything under /home/groucho/.wine is owned by $USER:$USER.
Any idea as to how to troubleshoot this?
Thanks in advance.
Best,
A.
Hello:
... or reinstalling wine to reconnect the links with the system.
I just tried reinstalling:
~$ sudo apt install --reinstall wine
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 70.6 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://deb.devuan.org/merged daedalus/main amd64 wine all 8.0~repack-4 [70.6 kB]
Fetched 70.6 kB in 8s (8709 B/s)
(Reading database ... 181668 files and directories currently installed.)
Preparing to unpack .../wine_8.0~repack-4_all.deb ...
Unpacking wine (8.0~repack-4) over (8.0~repack-4) ...
Setting up wine (8.0~repack-4) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for wine (8.0~repack-4) ...
~$ Reinstall went through with no warnings.
Unfortunately the problem remains.
Thanks for your input.
Best,
A.
Hello:
Whilst the upgrade from Beowulf to Chimaera had no adverse effects on Wine, the upgrade to Daedalus broke it.
It simply will not start.
Attempting to find out what is going on via a terminal gave me a printout which first complained about a missing Wine32 and then about a slew of *.dlls which it could not find even though they are present in the system.
Installing Wine32 made no difference, same output.
eg:
~$ wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe
0024:err:module:import_dll Library sechost.dll (which is needed by L"C:\\windows\\syswow64\\advapi32.dll") not found
0024:err:module:import_dll Library advapi32.dll (which is needed by L"C:\\windows\\syswow64\\shell32.dll") not found
0024:err:module:import_dll Library sechost.dll (which is needed by L"C:\\windows\\syswow64\\advapi32.dll") not found
--- snip ---
0024:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\syswow64\\user32.dll") not found
0024:err:module:import_dll Library user32.dll (which is needed by L"C:\\windows\\syswow64\\start.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"C:\\windows\\syswow64\\start.exe" failed, status c0000135
~$ I have been using Wine since I set up my first Linux box (mid 2015?) and never had any problems with it: it just worked as expected.
So I am rather lost as to what could be going on.
It was working perfectly well after upgrading to Chimaera, no issues.
Any one using Wine in a Daedalus install?
I would appreciate some input on this.
Thanks in advance.
Best,
A.
Hello:
... not been able to find out how to fix it.
Thinking the unsupported nvidia 340.108 driver for my twin PCI-e cards could well be the cause, I decided that my upgrading to Chimaera would be a good opportunity to see if the nouveau driver worked as well as it did in the Daedalus live-iso I had tested some time ago.
But it was (indeed) a Chimaera.
After a few hours of trying to get the two card / three screen layout to work as it was supposed to, I called it a night.
I had not had this much fun since I first spent a couple of days to get a properly working xorg.conf in a version of PCLinuxOS.
That was many years ago, may be too old for all that now.
At the time the effort proved to be well worth it as I was able to use the same configuration file from Jesse to Beowulf by simply dropping it in place, no questions asked.
But nouveau would have none of it and the xorg-config generated file was not a solution.
This morning, before I restored my Beowulf image I decided to see if whatever problem I had in front of me had been solved/taken care of in Daedalus, so I went ahead with the upgrade.
Went by witout much ado and although few desktop settings got mangled (conky panel and xfce4-panel placement and transparency) the three screens were recognised and working as intended fron the get-go, with Right click -> Open [ Terminal or root Thunar ] here is working as expected.
So, for the time being everything is well enough, time will tell.
Many thanks to the developers/maintainers involved in/with Devuan and nouveau: the problems I came across did not get fixed by themselves.
Best,
A.
Hello:
Finally decided to upgrade from Beowulf to Chimaera.
~/Desktop$ uname -a
Linux devuan 5.10.0-29-amd64 #1 SMP Debian 5.10.216-1 (2024-05-03) x86_64 GNU/Linux
~/Desktop$ But there are a couple of things that the upgraded version of Xfce seems to have broken.
eg:
Right click -> Open [ Terminal or root Thunar ] here does not work as expected ie: as it did before the upgrade.
Instead of opening where the pointer is (one of the three monitors) it always opens the selection in the centre monitor.
I have not been able to find out how to fix it.
I'd appreciate some input on this.
Thanks in advance.
Best,
A.
Hello:
A rather belated update.
... now would be a good time to do so.
Good times, bad times ...
Edie Brikell comes to mind.
Finally got my new fibre link installed so I went ahead with that.
Worked prefectly well.
Thank you very much.
Best,
A.
Hello:
... always found fsmithred to be polite & civil ...
Indeed ...
Not only that, he has devoted many hundred of hours to Devuan.
And continues to do so.
@oui
If you have problems with Devuan, you may want to consider using another distribution more suited to your specific needs.
There are a great many to choose from, with and without systemd.
A.
Hello:
Daedalus, same thing ...
I see.
Not a merge after-effect then.
Poked around some more and found this.
Debian Bug report logs - #1033594
The diversion of "/usr/bin/firefox" by "firefox-esr" package does not respect a previously added local diversion
Looked some more and found a definition/explanation of diversion
File diversions are a way of forcing dpkg(1) not to install a file into its location, but to a diverted location. Diversions can be used through the Debian package scripts to move a file away when it causes a conflict.
Right ...
But why is this happening in my box? (and apparently in yours also ...)
Thanks for your input.
Best,
A.
Hello:
Still on Devuan Beowulf with a backported kernel:
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ During my weekly update, apt offered to upgrade Firefox to 115.11.0esr.
I went ahead and in the process the output read:
--- snip ---
Preparing to unpack .../firefox-esr_115.11.0esr-1~deb10u1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr' ### <---
Unpacking firefox-esr (115.11.0esr-1~deb10u1) over (115.10.0esr-1~deb10u1) ...
Setting up firefox-esr (115.11.0esr-1~deb10u1) ...
--- snip ----I do not recall seeing this Leaving 'diversion ... line ever before.
Looked at /usr/bin and got two instances of firefox:
~$ ls /usr/bin | grep firefox
firefox
firefox-esr
~$Checked with apt and found one instance of firefox:
~$ apt list | grep installed | grep firefox
--- snip ---
firefox-esr/oldoldstable-security,now 115.11.0esr-1~deb10u1 amd64 [installed]
webext-ublock-origin-firefox/oldoldstable,oldoldstable,now 1.42.0+dfsg-1~deb10u1 all [installed]
~$mc shows them as *firefox and @firefox-esr.
~$ cat /usr/bin/firefox
#!/bin/sh
FIREFOX="$(command -v firefox)"
[ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
exec firefox-esr "$@"
~$ So /usr/bin/firefox-esr is a symbolic link to /lib/firefox-esr/firefox-esr.
Is all this related to the 'merge'?
Is there anything I have to do or does it stay like that?
Thanks in advance.
Best,
A.
Hello:
... wouldn't be able to use the current Debian package.
From what I make out of the OP, the reduced functionality has only been applied to sid, the unstable developement Debian, meaning Excalibur in Devuan.
I'd opine that there is still a long way to go till the package with the reduced functionality actually gets into the Debian stable repositories.
In the meantime, I'm sure a way to get what different users need without going against the basic do one thing and do it well philosophy will be found.
eg: base package for most users plus a set of separately packaged plugins (or similar) for those who need the different additional functionalities.(?)
Just my $0.02.
Best,
A.
Hello:
... these features are superfluous and do not really belong in a local password database manager ...
Makes a lot of sense to me.
Much more so with what we have seen happening lately.
As I understand it, julian-klode's point of view is clearly aligned with the Unix/Linux philosophy.
ie: doing one thing and doing it well.
Something to be lauded, not criticised.
As always, YMMV.
Best,
A.
Hello:
... upgraded from Daedalus to Excalibur but now I cannot install ...
Devuan Excalibur is a testing/in development version of Devuan, the equivalent (sans systemd) of Debian Trixie.
That is surely the reason you are having issues with installing FreeCAD.
I am assuming that FreeCAD worked properly under Devuan Daedalus, yes?
- testing is where the next stable suite is developed. Software is usually more up-to-date but there may still
be issues. testing becomes stable “when it is ready”.
If FreeCAD is essential to you, you may want to consider rolling back to the stable version of Devuan (ie: Daedalus) you were using.
PLEASE HELP ME!
Now, now ...
No need to scream and/or plead to get help here. 8^)
Best,
A.
Hello:
... run dpkg -L <package> to see what files from a package are actually installed ...
I went looking to see what openjdk* stuff I had installed and it turns out I have two versions:
~$ apt list | grep installed | grep "openjdk"
--- snip ---
openjdk-11-jre-headless/oldoldstable-security,now 11.0.23+9-1~deb10u1 amd64 [installed,automatic]
openjdk-11-jre/oldoldstable-security,now 11.0.23+9-1~deb10u1 amd64 [installed,automatic]
openjdk-8-jre-headless/now 8u275-b01-1~deb9u1 amd64 [installed,local]
openjdk-8-jre/now 8u275-b01-1~deb9u1 amd64 [installed,local]
~$ So I asked aptitude about that:
~$ aptitude why openjdk-11-jre-headless
i libreoffice-base Recommends default-jre | sun-java6-jre | java6-runtime | jre
i A default-jre Depends openjdk-11-jre
i A openjdk-11-jre Depends openjdk-11-jre-headless (= 11.0.23+9-1~deb10u1)
~$
~$ aptitude why openjdk-11-jre
i libreoffice-base Recommends default-jre | sun-java6-jre | java6-runtime | jre
i A default-jre Depends openjdk-11-jre
~$
~$ aptitude why openjdk-8-jre-headless
i libreoffice-base Recommends default-jre | sun-java6-jre | java6-runtime | jre
i A openjdk-8-jre Provides java6-runtime
i A openjdk-8-jre Depends openjdk-8-jre-headless (= 8u275-b01-1~deb9u1)
~$
~$ aptitude why openjdk-8-jre
i libreoffice-base Recommends default-jre | sun-java6-jre | java6-runtime | jre
i A openjdk-8-jre Provides java6-runtime
~$And then looked to find their location:
~$ locate openjdk-8
/usr/share/application-registry/openjdk-8-archive.applications
/usr/share/applications/openjdk-8-policytool.desktop
/usr/share/doc/openjdk-8-jre
/usr/share/doc/openjdk-8-jre-headless
/usr/share/doc/openjdk-8-jre-headless/JAVA_HOME
/usr/share/doc/openjdk-8-jre-headless/README.Debian
/usr/share/doc/openjdk-8-jre-headless/README.alternatives
/usr/share/doc/openjdk-8-jre-headless/changelog.Debian.gz
/usr/share/doc/openjdk-8-jre-headless/copyright
/usr/share/icons/hicolor/16x16/apps/openjdk-8.png
/usr/share/icons/hicolor/24x24/apps/openjdk-8.png
/usr/share/icons/hicolor/32x32/apps/openjdk-8.png
/usr/share/icons/hicolor/48x48/apps/openjdk-8.png
/usr/share/lintian/overrides/openjdk-8-jre
/usr/share/lintian/overrides/openjdk-8-jre-headless
/usr/share/mime-info/openjdk-8-archive.keys
/usr/share/mime-info/openjdk-8-archive.mime
/usr/share/pixmaps/openjdk-8.xpm
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.conffiles
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.list
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.md5sums
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.postinst
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.postrm
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.preinst
/var/lib/dpkg/info/openjdk-8-jre-headless:amd64.prerm
/var/lib/dpkg/info/openjdk-8-jre:amd64.list
/var/lib/dpkg/info/openjdk-8-jre:amd64.md5sums
/var/lib/dpkg/info/openjdk-8-jre:amd64.postinst
/var/lib/dpkg/info/openjdk-8-jre:amd64.preinst
/var/lib/dpkg/info/openjdk-8-jre:amd64.prerm
/var/lib/dpkg/info/openjdk-8-jre:amd64.shlibs
/var/lib/dpkg/info/openjdk-8-jre:amd64.triggers
~$~$ locate openjdk-11
/usr/share/application-registry/openjdk-11-archive.applications
/usr/share/doc/openjdk-11-jre
/usr/share/doc/openjdk-11-jre-headless
/usr/share/doc/openjdk-11-jre-headless/JAVA_HOME
/usr/share/doc/openjdk-11-jre-headless/README.Debian
/usr/share/doc/openjdk-11-jre-headless/README.alternatives
/usr/share/doc/openjdk-11-jre-headless/changelog.Debian.gz
/usr/share/doc/openjdk-11-jre-headless/copyright
/usr/share/icons/hicolor/16x16/apps/openjdk-11.png
/usr/share/icons/hicolor/24x24/apps/openjdk-11.png
/usr/share/icons/hicolor/32x32/apps/openjdk-11.png
/usr/share/icons/hicolor/48x48/apps/openjdk-11.png
/usr/share/lintian/overrides/openjdk-11-jre
/usr/share/lintian/overrides/openjdk-11-jre-headless
/usr/share/mime-info/openjdk-11-archive.keys
/usr/share/mime-info/openjdk-11-archive.mime
/usr/share/pixmaps/openjdk-11.xpm
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.conffiles
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.list
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.md5sums
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.postinst
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.postrm
/var/lib/dpkg/info/openjdk-11-jre-headless:amd64.prerm
/var/lib/dpkg/info/openjdk-11-jre:amd64.list
/var/lib/dpkg/info/openjdk-11-jre:amd64.md5sums
/var/lib/dpkg/info/openjdk-11-jre:amd64.postinst
/var/lib/dpkg/info/openjdk-11-jre:amd64.prerm
~$ The directory /usr/share/application-registry/openjdk-8-archive.applications was last modified 20201202 but the directory /usr/share/application-registry/openjdk-11-archive.applications was last modified 20240418 which leads me to suspect that the first one is redundant/unneeded.
Attempting to remove openjdk-8 looks like this:
~$ sudo apt purge openjdk-8-jre
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
openjdk-8-jre*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 260 kB disk space will be freed.
Do you want to continue? [Y/n] n
~$ie: just openjdk-8-jre
But attempting to remove openjdk-11 looks like this:
~$ sudo apt purge openjdk-11-jre
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
default-jre* openjdk-11-jre*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 640 kB disk space will be freed.
Do you want to continue? [Y/n] n
~$ie: it also drags along default-jre.
At some point in time, openjdk-8-jre was locally installed (obviously) by me.
But I cannot remember that far back, much less why.
Should I just purge it?
Thanks in advance.
Best,
A.
Hello:
I found what would seem to be (?) a broken link in /usr/bin:
/usr/bin/!clhsdb
I then traced it ...
# ls -la /usr/bin/clhsdb
lrwxrwxrwx 1 root root 24 Mar 20 2019 /usr/bin/clhsdb -> /etc/alternatives/clhsdb
#
# ls -la /etc/alternatives/clhsdb
lrwxrwxrwx 1 root root 48 Mar 20 2019 /etc/alternatives/clhsdb -> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb
#
# ls -la /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb
ls: cannot access '/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb': No such file or directory... and checked:
# ls /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/
java jjs keytool orbd pack200 policytool rmid rmiregistry servertool tnameserv unpack200
# Having made sure it was not where it was supposed (?) to be I looked and found it somewhere else:
# locate clhsdb
/etc/alternatives/clhsdb
/usr/bin/clhsdb
/var/lib/dpkg/alternatives/clhsdb
# I then traced those:
# ls -la /usr/bin/clhsdb
lrwxrwxrwx 1 root root 24 Mar 20 2019 /usr/bin/clhsdb -> /etc/alternatives/clhsdb
#
# ls -la /etc/alternatives/clhsdb
lrwxrwxrwx 1 root root 48 Mar 20 2019 /etc/alternatives/clhsdb -> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb
#
# ls -la /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb
ls: cannot access '/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/clhsdb': No such file or directory
# Rather confusing ...
The file is dated 20190324, too old to be a victim of the Debian merge war.
But a broken link surely needs fixing and I don't want to muck up my system.
Q: How to fix this? Maybe it is a product of some upgrade. eg: VBox
Thanks in advance.
Best,
A.
Hello:
... a less verbose and redundant writing style ...
Maybe.
And then, maybe not.
My verbose and redundant writing style comes from having had dedicated school teachers and my last 20+ years of professional practise in the public sector. ie: reading, proofing, vetting and as time went by authoring tender documents and technical specifications for the government.
The sort of work that, with my initials on it, ended up on a cabinet minister's desk and was usually pored through by the government's comptroller/auditor or a disgruntled bidder's legal team.
So I think it will be a maybe not.
That said, thank you for your input. 8^)
Best,
A.
Hello:
Bringing in javascript ...
... ruled out on policy grounds.
Noted.
... adding javascript only for Altoid ...
Not only for Altoid.
There is at least one other affected poster, probably more.
Noted.
Other solutions are possible ...
... tea body count is a barrier.
Noted.
I did say if at all possible and does not cause any issues so I'll leave it to you then.
That said, I am quite aware that there are much more important things to sort out.
@golinux
I imagine it does not escape you that to write in a text editor and c/p for final tweaks totally defies the whole purpose of having a browser based system for the forum so I really don't think it is a suitable option.
But there's an uptick to this thread: now you know about the timeout. 8^D
As to providing a patch, I would have no idea as to where to begin.
Thank you both for your input.
Best,
A.
Hello:
... sorry about that ...
No need to apologise. 8^)
... meant as a pun really ...
And that's the spirit it was received in. (I was actually about to riff on it but decided to stay on topic)
Rest assured that no offense was taken, none whatsoever.
... you can use the preview button to refresh the session.
Yes, but being so meticulous is time consuming, I sometimes I forget.
If at all possible and does not cause any issues, could you consider extending it 10' or 15'?
Or maybe use a pop-up like some banks use:
---
Still there? Logging out in XX seconds. -> where XX is a countdown from XX to nought.
---
Thanks in advance.
Best,
A.
Hello:
... a half-hour timeout for the idle time between interactions ...
Ahh ...
I thought as much.
Thank you for clarifying the matter for us all.
... with any posts that have been made while you ahve been sitting there prefectering spelling.
I beg to differ.
It is not just about spelling.
There's also grammar, syntax, specific/proper (IT) vocabulary, punctuation, etc.
In short: everything Mrs. Fowler (fortunately) drilled into my head at The Priory School when I was ~10.
And then there is also the issue of my random bouts of dyslexia or the lack of a good night's sleep which do not help.
Best,
A.
Hello:
... if it is a Debian package or a sanitised Devuan package.
It seems that ceph is a Debian package.
ie: maintainers are Ceph Packaging Team <team+ceph@tracker.debian.org>
Meaning that it is not a sanitised Devuan package with a Devuan maintainer.
Debian all but dropped support for sysvinit software as of Bullseye so it is highly probable that the ceph package does not have the all necessary files to run on Devuan.
But since it is in the Daedalus repository, a bug could be filed against it in Devuan.
Maybe the maintainers can do something about that that if the only thing lacking is an init script.
Best,
A.
Hello:
... from Devuan repository.
... installed ceph and cephadm using apt.
Right ...
Not the problem then. 8^)
Have a look here:
Ceph can run on any distribution that includes a supported kernel and supported system startup framework, for example sysvinit or systemd.
Now, if you look at the table below, you can see that (for Debian releases, labelled with a C) it states:
C: Ceph provides packages only. No tests have been done on these releases.
Devuan is not on that list and, like I mentioned earlier, our (highly) overworked maintainers may have skipped a beat somewhere.
eg: maybe the sysvinit files for the ceph in the Devuan repositories are missing something?
So ...
You may want to consider first filing a bug in Devuan against ceph and see what the maintainer has to say about this.
ie: if it is a Debian package or a sanitised Devuan package.
Send email to submit@bugs.devuan.org with a descriptive subject line and the first line of the body should be Package: <package name>.
Be sure to include a link to this thread.
Follow-up messages go to <number>@bugs.devuan.org
At this point in time, filing a bug in Debian by a Devuan user is guaranteed to be an exercise in frustration/futility, so the next best thing would be to ask at the ceph user's forum and see what they have to say.
Please let us know how you fared.
Best,
A.
Hello:
I run my box on Devuan Beowulf with a backported kernel.
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ I have no docker containers installed.
~$ apt list | grep installed | grep -i docker
--- snip ---
~$ When I ask apt about ceph, systemctl and systemd, I get this:
~$ sudo apt install --dry-run ceph | grep -i "systemctl\|systemd"
--- snip ...
~$ As you can see, as per grep, the terminal printout does not contain any systemctl or systemd strings.
Likewise, when I ask apt about docker, I get this:
~$ sudo apt install --dry-run docker | grep -i "systemctl\|systemd"
--- snip ---
~$ So much for my Devuan system.
But on your Devuan system you are getting this error from cephadm:
systemctl: ERROR:systemctl:Unit systemd-timesyncd.service could not be found.And systemd-timesyncd.service seems to be a Debian systemd-specific package.
So why is ceph looking for a systemd-specific Debian package when installed in Devuan?
No idea, but it do not think it should be happening.
Q: did you install ceph from a Devuan repository?
Looking around for a clue, I found this thread at the Bunsen Labs forum:
... up to Debian Buster the functionality was included in systemd, so there's no need to install it until you get to Bullseye, where it got separated out.
There is more discussion on systemd-timesyncd.service further down.
It may or may not be of relevance but from what I can make of what I read, it would seem (?) that ceph needs a time sync daemon to work but is configured to use a systemd service which (quite obviously) Devuan does not have, hence the error message.
That said, could ceph use any other one? eg: npt
Cannot really say as this is where I have reached my pay-grade ceiling.
Best,
A.
Hello:
... looks like beowulf-backports got archived.
I see ...
Right, I will edit my /etc/apt/sources.list file to reflect this change.
Thanks for the heads-up.
Best,
A.