- This topic has 26 replies, 3 voices, and was last updated Dec 14-8:41 pm by DaveW.
-
Posts
-
DaveW
Hi, A week ago, I installed apparmor and configured apparmor, on two 32 bit computers running Antix 17. The installation files were downloaded with Synaptic, and configured with help of instructions on a debian site, and Firejail support site. Both systems seem to be working okay.
Today, I attempted to do the same with another computer, which is also running 32 bit Antix 17 with Firejail.
But when making selections on Synaptic, the selected lines indicate broken packages. So, instead of using synaptic, I ran the following from terminal:
root@my-antix17:/home/myhome# apt install apparmor apparmor-utils
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:The following packages have unmet dependencies:
apparmor : Depends: libapparmor-perl but it is not going to be installed
apparmor-utils : Depends: libapparmor-perl but it is not going to be installed
Depends: python3-apparmor (= 2.11.0-3+deb9u2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@my-antix17:/home/myhome#Synaptic says libapparmor-perl has dependency perlapi-5.24.1 (with complaint: “make sure all required repositories are added and enabled.”) Synaptic shows the same repositories as were used in the two previous successful installs.
perlapi-5.24.1 is contained in perl-base. Synaptic shows this as already present. I attempted ‘apt reinstall perl-base’ and was informed that the file could not be downloaded.
I guess I don’t have the appropriate repository. Where I should I look?
Thanks!
- This topic was modified 3 years, 5 months ago by DaveW.
- This topic was modified 3 years, 5 months ago by DaveW.
Anonymous
FYI I just checked libapparmor-perl and found that it is available & that I was able to successfully install to antiX 17 system
$ apt policy libapparmor-perl libapparmor-perl: Installed: (none) Candidate: 2.11.0-3+deb9u2 Version table: 2.11.0-3+deb9u2 500 500 http://ftp.us.debian.org/debian stretch/main amd64 PackagesEven if you had altered your sources.list.d/debian.list, and your system is trying to download from “testing” branch… the libapparmor-perl package is still available from the current testing (bullseye) repository.
I guess I don’t have the appropriate repository. Where I should I look?
Nooooo it doesn’t work (work out well) like that. Don’t get a wild hair to change the configured repositories.
? On your system, what is the output of
apt policy libapparmor-perlSynaptic shows the same repositories as were used in the two previous successful installs.
Well, I’ll suggest you just sit tight, then tomorrow apt update and try again.
I’ve noticed some ‘net slowness today and several intermittently unresponsive servers.Skidoo,
Thank you for your reply.
As you suggested, I waited a day, and rechecked. Symantic still shows that the apparmor related packages are broken.You asked about the following…
$ apt policy libapparmor-perl
libapparmor-perl:
Installed: (none)
Candidate: 2.11.0-3+deb9u2
Version table:
2.11.0-3+deb9u2 500
500 http://ftp.us.debian.org/debian stretch/main i386 PackagesI see that you were using an amd64 repository, while I am using i386. Perhaps there is an issue with something in the 32 bit area of the repository?
As noted in my original post, Synaptic says libapparmor-perl has an unsatisfied dependency: perlapi-5.24.1 (Synaptic says: “make sure all required repositories are added and enabled.”) There is also mention of a possible broken “held package”.
Apparently, perlapi-5.24.1 is contained in perl-base. Synaptic shows this as already present on my system. However, assuming that the mentioned file is corrupted, I attempted ‘apt reinstall perl-base’ and was informed that the file could not be downloaded, because it could not be found in the repositories. I found that it is available for download from a debian site, but I would rather use antix distribution sources.
Could this be the “held package”?
$ apt list -a perl-base
Listing… Done
perl-base/now 5.28.1-6 i386 [installed,local]
perl-base/oldstable,oldstable 5.24.1-3+deb9u5 i386I appreciate your suggestions. I’m still baffled.
.
(reposting b/c the spamfilter ate my prior attempt)
.Instead of
apt list -a PKGNAME
try
apt policy PKGNAMEThe output of the latter will clarify which repository the pkg was installed from and/or which repositor(ies) it is currently available from. Also, you’ll discover the intalled perl-base pkg isn’t shown as “local” (which would indicate that it was manually installed, or manually injected during the course of building the antiX distribution iso) ~~ AFAIK the “antiX” repositories have never provided custom versions of a perl-base package.
perl-base is a critical pkg, it must still be available. To verify, you can check:
https://packages.debian.org/search?keywords=perl-base&searchon=names&suite=all§ion=allAlso, if you are using antiX17 + stable repository, you can check here to verify whether or the antiX repository contains a perl-base package:
http://repo.antixlinux.com/stretch/pool/main/p/Could this be the “held package”?
You can easily use the “apt-mark” command to check.
man apt-mark
If you discover that it is, in fact held… I can’t imagine who|what|why caused that.I guess I don’t have the appropriate repository. Where I should I look?
Oops, sorry, I just noticed that I missed replaying to that question.
/etc/apt/sources.lists.d/
In that directory, you should expect to find a “debian.list” file.
Yes, inspect its contents, and consider pasting that content into a codebox here in a followup reply.As noted in my original post, Synaptic says libapparmor-perl has an unsatisfied dependency: perlapi-5.24.1
This is another detail I neglected to notice during my earlier reading.
a websearch for “libapparmor-perl perlapi-5.24.1”
led to this: https://forums.solydxk.com/viewtopic.php?t=7126
which mentions that an “apt upgrade” or “apt dist-upgrade” may be required to untangle the situation.“I am using i386”
That’s often a good detail to consideer, but AFAIK all perl stuff is architecture-agnostic
(I would expect a repo to serve the same, identical, perl-whatever pkg to all requestors)
caprea
It looks like, however this happened, the version of perl-base that is installed on your system is a buster version.
The repos of antiX17 are set to stretch, normally. And the output of “apt policy libapparmor-perl” indicates also that you are actually using stretch.Did you by chance install something from outside the repos or from buster ?
Unfortunately that would not be easy to solve, maybe impossible.(pearl-base from buster pulled in a higher libc6 and so on….)Skidoo,
/etc/apt/sources.list.d/debian.lst shows the following active repositories…deb http://ftp.us.debian.org/debian/ stretch non-free contrib main
deb http://security.debian.org/ stretch/updates non-free contrib mainI tried “$ apt-mark showhold” but nothing was returned. You also asked about…
$ apt policy perl-base
perl-base:
Installed: 5.28.1-6
Candidate: 5.28.1-6
Version table:
*** 5.28.1-6 100
100 /var/lib/dpkg/status
5.24.1-3+deb9u5 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages
500 http://security.debian.org stretch/updates/main i386 PackagesCaprea,
Yes… I probably did install something from outside of the repos… but I don’t recall what it was. One of the links, that skidoo provided, gave version numbers of perl-base packages. And, as you said, the 5.28 version is Buster.The other two computers (mentioned in original post) where apparmor install went uneventfully, have the 5.24 perl-base.
It would be worthwhile reverting to the earlier perl-base, if the only thing that it would break is the unknown program from outside. But, my guess is that a lot of other things are tangled up with it.
So… If reverting to the earlier version of perl-base is not feasible, without breaking everything, I can do a fresh install from a LiveUSB made from one of the others (after backing up personal stuff, like firefox and thunderbird profiles)..
caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 >= 2.28
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28The pasted output from apt policy shows a pin priority of 100.
Forensically, is this a clue toward figuring out what (apparently),
at some point, temporarily changed the debian.list contents?Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “pin-priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 >=2.28 dependency…)
__________________________
caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 >= 2.28
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28The pasted output from apt policy shows a pin priority of 100.
Forensically, is this a clue toward figuring out what (apparently),
at some point, temporarily changed the debian.list contents?Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “pin-priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 >=2.28 dependency…)
___________________________
caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 (greaterthanorequal v2.28)
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28The pasted output from apt policy shows a pin priority of 100. Forensically, is this a clue toward figuring out what (apparently), at some point, temporarily changed the debian.list contents?
Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “Pin-Priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 2.28+ dependency…)
caprea
A suggestion. If you are going to completely reinstall now anyway, you might consider starting a somewhat pragmatic rescue attempt first.
(Of course after you have made your backups)
Put all your repos (debian and antiX) on buster and do a dist-upgrade.Buster is the new stable now anyhow.
Something like here, might worth a try.
upgrading-antix-17-to-antix-19Caprea,
I followed your suggestion, and the procedure given in the “upgrading-antix-17-to-antix-19” link.
The procedure was very well explained and straight forward. However, I ran into a snag at step #5.The system said it could not install libpam-elogind-compat due to a held package which had something to do with an incorrect version of libpam-elogind.
So, I tried “$ apt purge libpam-elogind ” and followed that with “$ apt-get install libpam-elogind ” Both commands appeared to finish successfully.During the ‘purge’ there was a line: “removing systemd”. So, I thought, perhaps that would take care of the problem.
But when all of the steps were finished, the system did not fully reboot. The boot dialogue proceeded, but then hung. I don’t recall the last few lines of the dialogue, but there was no indication of a failure, before the screen went blank.Perhaps there would have been a way to salvage it, but in the end, it was quicker to re-install antix 17 from LiveUSB, and refresh the /home directory with the backups for that computer. So, it’s up and running… and apparmor is working, now.
I think my original problem (which prevented install of apparmor) may have been caused, several months ago, when I must have installed Calibre (an ebook reader) from a Testing repository. The installed version was much higher than the one in the Stretch repos, and it probably came with some incompatible dependencies.
One issue that remains is that the Calibre version in the Stretch repos (2.75.1+dfsg-1) seems to be broken (according to Synaptic). This is not a big deal, since I have another ebook reader installed, and I have not made use of Calibre since installing it, on the previous system (except to test it right after the install).So… it’s up and running.
Thank you, both, Skidoo and Caprea, for your help!ok, good to hear you are back up n running
During the ‘purge’ there was a line: “removing systemd”.
Occasionally, confoozed antiX users have posted claims like “systemd” got on my machine, or “is now on my machine” or “i hadda remove systemd”.
The details of the purge transaction would have been preserved (available for inspection later, if you needed to review what had transpired) but now you (we) can only guess… but unless gremlins had snuck onto your system and deleted the pre-installed /etc/apt/preferences.d/00systemd file, no-way a/the systemd package could have been installed — accidentally or intentionally — on the system.
sudo cat /etc/apt/preferences.d/00systemd
Package: *systemd* Pin: origin "" Pin-Priority: -1
- You must be logged in to reply to this topic.
