Hello:

The pair of cards were at a really great price.
Impossible to pass up or resist, for that matter.

Yes.
I saw from the terminal that the VM that runs pihole was not up and the printout when atempting to run /sbin/vboxconfig put me up to speed.
Much more verbose in that respect than the nvidia drivers.  8^/

Sure.
Like installing a backported kernel.

Done.
Booted into my SLiM log-it as always.

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

Apparently everything runs as it should.
There may be a problem with the wicd daemon not starting right away, I'll have to look into that.

Thanks a lot for your input.

Best,

A.

Hello:

I see ...
Sort of.

It would seem, if I understand correctly, that you have with your Chimaera) installation what I want to have with my Beowulf installation.

ie: Beowulf with a an up-to-date 5.10 backported kernel
Eventually, a couple of (or all, don't know yet) backported applications.

Not Chimaera because of the reasons posted previously.

How can I get this done?

Thanks in advance.

Best,

A.

Hello:

First there's the issue of the nvidia-legacy-340xx drivers and then the demise of python 2.7.18.
There are a couple of applications that will not work in chimaera, which is why I use the backported kernel.

Thanks for your input.

Best,

A.

Hello:

Hmm ...
No thanks.

I'd prefer that any and all recommends be something I get to consider installing to then decide and not something that is installed because some Debian packager though it was a good idea.

That is how the Linux bloat we have today started ...

I think that a system-wide block on recommends is a great idea.
Of course, YMMV.

Thank you for your input.

Best,

A.

Hello:

You're welcome.

The 340XX drivers were not dropped by Debian / Devuan.
It was Nvidia that dropped support for graphic cards working only with the 340XX driver.

The 340XX drivers are propiertary/closed source and Debian cannot supply a 340XX package because Nvidia will not update them for newer kernels.

True to their A1-asshole mentality, they will not release the code for the hardware to be used in newer kernels.
That said, it seems that it may be possible to run them on Debian Bullseye/Devuan Chimaera:

https://forums.debian.net/viewtopic.php … 73#p742573

I have not attempted to do it, no idea if it works without problems.

See here: https://forums.debian.net/viewtopic.php … 77#p745277
It is a patched proprietary driver "nvidia-legacy-340xx-driver_340.108-11" from "Debian Sid" repository.

If you try and succeed, please let us know how you did it and what results you got.

And yes, Nouevau does not seem to be up to scratch.

A few years ago (when XP was mothballed) and decided my definitive move to Linux, I was met with the fact that there were no drivers for my excellent Matrox G550 PCI cards as there were no available drivers for Linux, another proprietary fuck-up.

Between a rock and a hard place, I decided to invest in a whole new setup which is the one I have been using since, with a few HW upgrades.
A Sun Ultra 24 WS running 2xNVidia FX580 for three 19" monitors using the NVidia 340XX proprietary drivers, works perfect and do not need anything more.

If I can upgrade to Devuan Chimaera using these cards, fine.
And if Chimarea is the last kernel I can use with them, I'll probably stay there using a backported kernel for as long as I can.

Of course, YMMV.

Best,

A.

Hello:

Just downloaded Lotus SmartSuite 9.8.2 Millennium Edition from here:

https://winworldpc.com/download/bb07d55 … 00008a0da4

Installed without issues in my W98SE VM using an ISO mounting application.
Avoided all the unneeded stuff (dictionaries, MM files, database application, etc.) and kept only Lotus 123 and Lotus WordPro.
Both seem to work perfectly well and WordPro can save in quite a few MS-Word and WP formats, down to the good old rtf.

I'll see further on if can run properly on my Devuan Wine installation and set it up there.
If it works for me, it will finally be good-bye to the bloated mess LO is.

Best,

A.

Hello:

apt list | grep installed | grep java reveals the existence of java-common and a vast array of xyz-java files, all of them automatically installed.

The printout of aptitude why java-common is:

~$ aptitude why java-common
i   libreoffice-nlpsolver Depends default-jre | sun-java6-jre | java6-runtime | jre
i A default-jre           Depends default-jre-headless (= 2:1.11-71)               
i A default-jre-headless  Depends java-common              

Further investigation made me start laughing ...

~$ aptitude why libreoffice-nlpsolver
i   task-desktop      Recommends task-xfce-desktop | task-cinnamon-desktop | task-kde-desktop | task-lxqt-desktop | task-mate-desktop
p   task-xfce-desktop Recommends libreoffice                                                                                         
p   libreoffice       Recommends libreoffice-nlpsolver    

[rant]
WTHF does task-xfce-desktop have a recommends for libreoffice?
Just who comes up with all this crap?
[/rant]

About libreoffice-nlpsolver:

Really ...
Who was the braided idiot that came up with the idea that optimizing nonlinear programming models was something every TD&H would want to do with his LibreOffice calc?

No wonder LO is such a bloated POS.

When (long ago and far away) it stopped being possible to install Word and Excel on your PC as stand alone applications and the Office Suite was born, I recall thinking it was a really bad move for end users and I still do.

With respect to log4j, it seems that it is also down to LO:

~$ aptitude why liblog4j1.2-java
i   libreoffice-report-builder            Depends libpentaho-reporting-flow-engine-java (>= 0.9.4)
i A libpentaho-reporting-flow-engine-java Depends libapache-poi-java                              
i A libapache-poi-java                    Depends liblog4j1.2-java          

And that libreoffice-report-builder being what specifically relies on it and every TD&H absolutely needs to have:

Removing this evidently absolutely indispensable extension from my system also removes a very long list of java related files, I spaced them out so it would be for easier to grasp how large this fuck-up is:

~$ sudo apt purge libreoffice-report-builder
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:

ant ant-contrib ant-optional libactivation-java
libaopalliance-java libapache-poi-java libapache-pom-java
libargs4j-java libasm-java libatinject-jsr330-api-java libbase-java
libbcmail-java libbcpkix-java libbcprov-java libcdi-api-java libcglib-java
libcodemodel-java libcommons-cli-java libcommons-codec-java
libcommons-collections3-java libcommons-collections4-java
libcommons-compress-java libcommons-io-java libcommons-lang3-java
libcommons-logging-java libcommons-math3-java libcommons-parent-java
libcurvesapi-java libdom4j-java libdtd-parser-java libehcache-java
libfastinfoset-java libflute-java libfonts-java libformula-java
libgeronimo-annotation-1.3-spec-java libgeronimo-interceptor-3.0-spec-java
libguava-java libguice-java libhawtjni-runtime-java libhttpclient-java
libhttpcore-java libicu4j-java libintellij-annotations-java libisorelax-java
libistack-commons-java libitext-java libjansi-java libjansi-native-java
libjaxb-api-java libjaxb-java libjaxen-java libjcommon-java libjdom1-java
libjetbrains-annotations-java libjsoup-java libjsr305-java liblayout-java libloader-java
liblog4j1.2-java libmail-java libmaven-file-management-java libmaven-parent-java
libmaven-resolver-java libmaven-shared-io-java
libmaven-shared-utils-java libmaven3-core-java libmsv-java
libpentaho-reporting-flow-engine-java libpixie-java libplexus-archiver-java
libplexus-cipher-java libplexus-classworlds-java libplexus-component-annotations-java
libplexus-interpolation-java libplexus-io-java libplexus-sec-dispatcher-java
libplexus-utils2-java librelaxng-datatype-java librepository-java librngom-java
libsac-java libsaxonhe-java libserializer-java libsisu-guice-java libsisu-inject-java
libsisu-ioc-java libsisu-plexus-java libslf4j-java libsnappy-java libsnappy-jni
libstax-ex-java libstreambuffer-java libtxw2-java libwagon-http-java
libwagon-provider-api-java libxerces2-java libxml-commons-external-java
libxml-commons-resolver1.1-java libxml-java libxmlbeans-java libxom-java
libxpp2-java libxpp3-java libxsom-java libxz-java

Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  libreoffice-report-builder*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 406 kB disk space will be freed.
Do you want to continue? [Y/n] 

I went ahead with the removal.
Worst that could happen would be to reinstall it.

After typing Y, doing autoremove and autoclean, the final test was apt install -f, which apparently has not detected anything missing.

So ...
It would seem (?) that the LO installed java crap can be weeded out with just uninstalling the libreoffice-nlpsolver and libreoffice-report-builder and extensions, most importantly log4j.

~$ apt list | grep installed | grep log4j
~$ 

.

Unfortunately, some java  files remain:

~$ apt list | grep installed | grep java

ca-certificates-java/oldstable,oldstable,now 20190405 all [installed,automatic]
java-common/oldstable,oldstable,now 0.71 all [installed,automatic]
javascript-common/oldstable,oldstable,now 11 all [installed,automatic]
libatk-wrapper-java-jni/oldstable,now 0.33.3-22+deb10u1 amd64 [installed,automatic]
libatk-wrapper-java/oldstable,oldstable,now 0.33.3-22+deb10u1 all [installed,automatic]
libel-api-java/oldstable,oldstable,now 3.0.0-2+deb10u1 all [installed,automatic]
libhsqldb1.8.0-java/oldstable,oldstable,now 1.8.0.10+dfsg-10 all [installed,automatic]
libjavascriptcoregtk-4.0-18/oldstable-security,now 2.34.6-1~deb10u1 amd64 [installed,automatic]
libjsp-api-java/oldstable,oldstable,now 2.3.4-2+deb10u1 all [installed,automatic]
libreoffice-java-common/oldstable,oldstable,now 1:6.1.5-3+deb10u7 all [installed]
libservlet-api-java/oldstable,oldstable,now 4.0.1-2 all [installed,automatic]
libservlet3.1-java/oldstable,oldstable,now 1:4.0.1-2 all [installed]
libwebsocket-api-java/oldstable,oldstable,now 1.1-1+deb10u1 all [installed,automatic]
~$ 

As to where all these come from, I bet good money it is all (mostly) due to LO.
I'll have to see about how to get rid of those too.

But for now it seems the log4j problem has been solved. (?)

Any comments on how to go from here will be appreciated.

Thanks in advance,

A.

Hello:

On this or most anything, methinks.
I fear that they cannot help it.

They've all been inbued with the same dumb-down KoolAid.

Ahh ...
If forking is required, I cannot but agree with you.

Right ...
Maybe add this as a commentary to the Release Notes most no one reads?  8^/

eg:
If you do not want the apparmor crap foisted on you without your knowledge when upgrading etc., etc., ...

NB:
For some reason it didn't work from the cmd line as root.
So I just created the file and then edited it.

Probably.

I'd also have to change the default /etc/apt/apt.conf.d/99synaptic to false.

I really find it quite tiresome/annoying to have to be on alert for this everytime I upgrade the kernel.
It should not be so.

But then, here we are.

Thanks a lot for your input.
I'll follow your suggestion to avoid this and all recommends in a system-wide manner.

A sort of 'Kill the dog and get rid of the rabies' solution.
Well done.  8^D

Best,

A.

Hello:

You're welcome.

I see.

From my limited understanding of the problem at hand, there is something (could be a bug) that is not allowing access to your mailbox.
My gut tells me that the issue is like the one that was affecting mutt.

Maybe there's something in the /var/log/auth file that could be of use.

Is there a log file for evolution you could look at?

I've seen that version 3.2.3 has/had a debug setting you can enable to start it from the command line:
See: https://askubuntu.com/questions/301665/ … -a-logfile

I do not use apparmor or any of the other 'security' applications like tomoyo that are quietly enabled by default (!) in Linux these days, so my kernel command line includes security=none apparmor=0.

You may want to try adding the same stanza at boot time to see if it has any effect as as well as temporarily disabling firejail while you are at it.

Hope that helps, can't think of anything else.

Best,

A.

EDIT:

It would seem that it's a bug ...

https://bugs.debian.org/cgi-bin/bugrepo … 1006603#10

... albeit with a temporary workaround:

Best,

A.

Hello:

It's well worth trying ...

First I zapped with sgdisk:

~$ sudo sgdisk --zap-all /dev/sdf

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.
~$

Then I used fdisk to create a partition and delete the iso9660 signature:

~$ sudo fdisk /dev/sdf

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x0be77ae3.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)

Select (default p): p
Partition number (1-4, default 1):
First sector (2048-585937499, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-585937499, default 585937499):

Created a new partition 1 of type 'Linux' and of size 279.4 GiB.
Partition #1 contains a iso9660 signature.

Do you want to remove the signature? [Y]es/[N]o: y

The signature will be removed by a write command.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
~$

Unfortunately I was not able to recover anything from fsck and any of the listed superblocks.
ie: 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 and 71663616

They were all corrupted.  8^|

At this point I decided to cut my losses and cleared the #$%& drive, formatted as ext4 and put it back on-line.
Fortunately, I was able to scrape back some files using PhotoRec but, as I posted earlier, it is a huge mess I have to sift through by hand.

My sincere thank you to all who pitched in.

Best,

A.

Hello:

Hmm ...
Nice club we belong to.

TestDisk has saved my hide once or twice.
But I had never before had to face such a screw up.

I dd'id the *iso file to a data HDD drive instead of dd'ing it to the USB stick. 8^/

~$ sudo dd if=/home/user/Downloads/chimaera_amd64_desktop-live.iso of=/dev/sdg1 bs=1M

I've realised that this happened because I used lsblk to re-check the USB drive's asigned letter.

This instead of checking it with gparted as I always do.
Big mistake ...

For some reason the USB drive did not mount.
As a result of that, /dev/sdg1 ended up being assigned to the data HDD drive drive instead of the USB drive.

I knew (from the last time I plugged it in) that the USB drive mounted at /dev/sdg1, so when I saw it in the lsblk printout, I assumed everything was all right.

Obviously, I did not notice that the size was 279.4G instead of 7.2G.     
Had I checked with gparted, this would have not happened.

No idea how to do that.
Would you mind explaining how to  do it?

Indeed ...
A real mess.
See my previous post.

Thanks in advance,

A.