Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #167580 > unrolled thread

libssl update problem

Back to article view | Back to linux.debian.user

Contents

  libssl update problem Gene Heskett <gheskett@shentel.net> - 2016-05-08 12:20 +0200
    Re: libssl update problem Gene Heskett <gheskett@shentel.net> - 2016-05-08 12:40 +0200
      Re: libssl update problem Jörg-Volker Peetz <jvpeetz@web.de> - 2016-05-09 09:50 +0200
        Re: libssl update problem Gene Heskett <gheskett@shentel.net> - 2016-05-09 12:50 +0200

#167580 — libssl update problem

Greetings;

Synaptic is telling me it cannot configure the new i386 version of libssl 
and friends on an i386 install, because it THINKS the amd64 version is 
installed.  It's been hand nuked when I found that it was not available 
to be nuked if the architecture wasn't set to include amd64 stuff.  
Short of enabling that architecture again, how can I clean up this mess?

Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

#167581

On Sunday 08 May 2016 06:10:36 Gene Heskett wrote:

> Greetings;
>
> Synaptic is telling me it cannot configure the new i386 version of
> libssl and friends on an i386 install, because it THINKS the amd64
> version is installed.  It's been hand nuked when I found that it was
> not available to be nuked if the architecture wasn't set to include
> amd64 stuff. Short of enabling that architecture again, how can I
> clean up this mess?
>
> Thanks all.
>
> Cheers, Gene Heskett

Never mind, I played 10,000 monkeys and got it.

For the record in case it helps somebody else:

sudo dpkg --configure -a

returns a list which contained the offending file.  Then

sudo dpkg --purge libssl1.0.0:amd64

Which did clean up its database.  Then:

sudo dpkg --configure -a

which then returned this:

Setting up libssl1.0.0:i386 (1.0.1e-2+deb7u21) ...
Setting up openssl (1.0.1e-2+deb7u21) ...
Setting up libssl-dev (1.0.1e-2+deb7u21) ...
Setting up libpkcs11-helper1:i386 (1.09-1) ...
Setting up libp11-2:i386 (0.2.8-2) ...

which completed the i386 versions installation. I probably need to reboot 
but I am behind a firewall in a dd-wrt reflashed router.

Yeah, nothing but kmail is running, nightly backup is done.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167600

If no amd64 packages needed on this machine, maybe the amd64 architecture could
be removed:

  dpkg --remove-architecture amd64

Then it won't install another amd64 package in the future.

Regards,
jvp.

[toc] | [prev] | [next] | [standalone]

#167606

On Monday 09 May 2016 03:39:49 Jörg-Volker Peetz wrote:

> If no amd64 packages needed on this machine, maybe the amd64
> architecture could be removed:
>
>   dpkg --remove-architecture amd64
>
> Then it won't install another amd64 package in the future.
>
Which is how I got into this mess in the first place.  Because the RTAI 
patched 64 bit kernels still don't have anywhere near the low latency 
needed to run machinery, as in cnc machinery, that a 32 bit kernel can 
achieve, I had added that architecture so I could run a 64 bit amd64 
kernel so I could do my own latency measurements.  This also had th 
added advantage of using all 8Gb in this machine, whereas the RTAI 
patches to a 32 bit kernel also wipe out the PAE, so I am 500 megs into 
swap in a days runtime. Performance of course goes in the toilet.

That worked although the latency was up some, but I only run the 
simulated LCNC on this machine.  Then I got the brilliant (not) idea of 
converting this 32 bit install into a full 64 bit amd64, but quickly ran 
into dependency hell since you can't easily replace libc6 on a running 
system. Everything was cool and I had removed most of the :amd64 stuff 
until the latest libssl fix hit the repo's.  It wouldn't configure as 
the amd64 kit was still installed.  Anyway, the procedure I posted fixed 
it all back up.  The above command in your post had already been done.

So overall, this 64 bit kernel runs much better, but the latency of this 
kernel,

gene@coyote:~/bin$ uname -a
Linux coyote 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt25-2~bpo70+1 
(2016-04-12) x86_64 GNU/Linux

is such that I could never run a stepper motor with this machine, the 25  
micro-second base-thread has up to an 83 millisecond jitter, whereas the 
RTAI patched 32 bit kernel is, on the right cpu, capable of a 3 
microsecond jitter, and the 1 millisecond servo-thread will show above 
100 milliseconds without too long a wait.  But that doesn't prevent me 
from writing gcode and testing it for correctness by running a simulated 
virtual machine on this machine from a comfy chair.  My eyes cannot see 
the timing jitter as the code is being simulated, but that would totally 
destroy both the workpiece, and maybe even the real machinery itself as 
it tries to follow orders that could be up to 100+ milliseconds late.

> Regards,
> jvp.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web