You are not logged in.
(... I suppose you are using latest firmware...)
That is correct.
Phil
So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy).
I think you should ask them why they want RHEL7. And perhaps you could try to explain to them why it may not be the best choice for an embedded system.
Phil
Here's mine:
# grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: EPT disabled
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
Doesn't look good.
Phil
@pcalvert, why pin the rest of the repository to 50?
Because aptitude was trying to pull other packages (e.g., intel-microcode) from that repo during upgrades, and pinning the rest of the repository to 50 stopped that behavior. Pinning it to 100 didn't work. I thought it would, but it didn't.
Also, their Flash package downloads updated Flash versions without needing to be updated itself so using the .deb might be the best option.
I'm not sure what you mean by that.
Phil
I use an MX repo for one package by using apt-pinning.
/etc/apt/preferences.d/mxrepo-pinning :
Package: adobe-flashplugin
Pin: origin "mxrepo.com"
Pin-Priority: 100
Package: *
Pin: origin "mxrepo.com"
Pin-Priority: 50
/etc/apt/sources.list.d/mx-17.list :
# MX Community Main and Test Repos
deb http://mxrepo.com/mx/repo/ stretch non-free main
#deb http://mxrepo.com/mx/testrepo/ stretch test
Download the repo keyring and install it:
wget http://mxrepo.com/mx/repo/pool/main/m/mx-archive-keyring/mx-archive-keyring_2018.2mx17_all.deb
sudo dpkg -i mx-archive-keyring_2018.2mx17_all.deb
Phil
My results:
$ apt policy firefox-esr
firefox-esr:
Installed: 60.7.2esr-1~deb9u1
Candidate: 60.7.2esr-1~deb9u1
Version table:
*** 60.7.2esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
60.6.3esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-updates/main i386 Packages
60.6.1esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Debian Stretch version: 60.8.0esr-1~deb9u1
Phil
Update: The problem seems to have been fixed.
$ apt policy firefox-esr
firefox-esr:
Installed: 60.7.1esr-1~deb9u1
Candidate: 60.7.1esr-1~deb9u1
Version table:
*** 60.7.1esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
60.6.3esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-updates/main i386 Packages
60.6.1esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Phil
This info may help:
SSD’s, Journaling, and noatime/relatime
https://tytso.livejournal.com/61830.html
Improving the Resilience of HDDs & Ext4
https://myles.sh/improving-the-resilience-of-your-hdds/
[Especially the section on tuning ext4.]
Phil
Try using aptitude. It may give you some other options, some of which may allow you to get rid of pulseaudio and pulseaudio-utils.
Phil
I downloaded the Firefox ESR package from here:
https://packages.debian.org/stretch/firefox-esr
Then I installed it using gdebi.
Result:
$ apt policy firefox-esr
firefox-esr:
Installed: 60.7.1esr-1~deb9u1
Candidate: 60.7.1esr-1~deb9u1
Version table:
*** 60.7.1esr-1~deb9u1 100
100 /var/lib/dpkg/status
60.7.0esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
60.6.3esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-updates/main i386 Packages
60.6.1esr-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Phil
Here's my result:
$ date && apt policy thunderbird
Sun Jun 16 12:56:56 EDT 2019
thunderbird:
Installed: 1:60.7.0-1~deb9u1
Candidate: 1:60.7.0-1~deb9u1
Version table:
2:52.9.1-2~mx17+2 50
50 http://mxrepo.com/mx/repo stretch/main i386 Packages
*** 1:60.7.0-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
1:60.6.1-1~deb9u1 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Here's some more data:
$ apt policy intel-microcode:amd64
intel-microcode:amd64:
Installed: (none)
Candidate: 3.20190514.1~deb9u1
Version table:
3.20190514.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free amd64 Packages
3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free amd64 Packages
$ apt policy intel-microcode
intel-microcode:
Installed: 3.20180807a.2~deb9u1
Candidate: 3.20180807a.2~deb9u1
Version table:
*** 3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free i386 Packages
100 /var/lib/dpkg/status
3.20180807a.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free i386 Packages
So, the package for 64-bit systems is up to date, but the one for 32-bit systems is not. Although I am by no means an expert on Devuan, this seems to suggest that Amprolla is not working properly.
Phil
Here's another example:
- -------------------------------------------------------------------------
Debian Security Advisory DSA-4447-1 security@debian.org
https://www.debian.org/security/ Moritz Muehlenhoff
May 15, 2019 https://www.debian.org/security/faq
- -------------------------------------------------------------------------
Package : intel-microcode
CVE ID : CVE-2018-12126 CVE-2018-12127 CVE-2018-12130
CVE-2019-11091
This update ships updated CPU microcode for most types of Intel CPUs. It
provides mitigations for the MSBDS, MFBDS, MLPDS and MDSUM hardware
vulnerabilities.
To fully resolve these vulnerabilities it is also necessary to update
the Linux kernel packages as released in DSA 4444.
For the stable distribution (stretch), these problems have been fixed in
version 3.20190514.1~deb9u1.
We recommend that you upgrade your intel-microcode packages.
For the detailed security status of intel-microcode please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/intel-microcode
Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/
More than 60 hours later and the update has not shown up yet:
$ apt policy intel-microcode
intel-microcode:
Installed: 3.20180807a.2~deb9u1
Candidate: 3.20180807a.2~deb9u1
Version table:
*** 3.20180807a.2~deb9u1 500
500 http://deb.devuan.org/merged ascii/non-free i386 Packages
100 /var/lib/dpkg/status
3.20180807a.1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/non-free i386 Packages
Phil
While I doubt Debian repositories work as intended on Devuan, let's say I want to install Lutris. The most common way to do that under Debian is to add a repo and then update and install. Could I add that Debian repo on Devuan?
Yes. The instructions for Debian found on this web page should also work for Devuan:
Phil
/etc/apt/preferences.d/mxrepo (or some other file name)
Package: * Pin: origin "mxrepo.com" Pin-Priority: 400
I think that will work. The man page for apt_preferences says that origin can match a hostname. I don't know if you need to make a separate entry for la.mxrepo.com or if the one will get both.
It turned out that a pin priority of 400 is too high. Even 100 is too high. I lowered it to 50 and now it works; 99 probably would have also worked, but I didn't bother testing it since the problem was already solved.
EDIT:
I thought I had this working, but further testing (via routine usage of the system) proved me wrong. I believe I have it working now, though, using this configuration:
Package: adobe-flashplugin
Pin: origin "mxrepo.com"
Pin-Priority: 100
Package: *
Pin: origin "mxrepo.com"
Pin-Priority: 50
Phil
@fsmithred: That works. Thank-you!
@anonymous: Try running aptitude update or apt-get update and then check again.
Here are my results:
$ apt policy openssh-client
openssh-client:
Installed: 1:7.4p1-10+deb9u6
Candidate: 1:7.4p1-10+deb9u6
Version table:
*** 1:7.4p1-10+deb9u6 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
100 /var/lib/dpkg/status
1:7.4p1-10+deb9u5 500
500 http://deb.devuan.org/merged ascii/main i386 Packages
Phil
The reason I set ASCII as the default release was because I am using an MX Linux repo for their adobe-flashplugin package.
Contents of /etc/apt/sources.list.d/mx-17.list:
# MX Community Main and Test Repos
deb http://mxrepo.com/mx/repo/ stretch non-free #main
#deb http://la.mxrepo.com/mx/testrepo/ stretch test
However, with the MX-17 repo enabled, APT tries to pull in other packages:
$ aptitude upgrade -s
The following packages will be upgraded:
intel-microcode unrar
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,557 kB of archives. After unpacking 9,216 B will be used.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?]
If I lower the priority of the MX-17 repo to 400, will that solve this problem? If so, how do I do that?
I am not using apt pinning. This directory is empty:
/etc/apt/preferences.d
However, I have this...
// Set ASCII as the default release
APT::Default-Release "ascii";
...in this directory:
/etc/apt/apt.conf.d
Could that be the reason?
Thanks for the reply. Here's that info:
$ apt policy libssl1.0.2
libssl1.0.2:
Installed: 1.0.2q-1~deb9u1
Candidate: 1.0.2q-1~deb9u1
Version table:
1.0.2r-1~deb9u1 500
500 http://deb.devuan.org/merged ascii-security/main i386 Packages
*** 1.0.2q-1~deb9u1 990
990 http://deb.devuan.org/merged ascii/main i386 Packages
100 /var/lib/dpkg/status
That's an interesting (but puzzling) result.
Is it normal for security updates to take several days to show up in Devuan? I am notified when there are security updates for Debian, and I've noticed that it often takes several days for those updates to show up in Devuan.
For example:
- -------------------------------------------------------------------------
Debian Security Advisory DSA-4400-1 security@debian.org
https://www.debian.org/security/ Moritz Muehlenhoff
February 28, 2019 https://www.debian.org/security/faq
- -------------------------------------------------------------------------Package : openssl1.0
CVE ID : CVE-2019-1559Juraj Somorovsky, Robert Merget and Nimrod Aviram discovered a padding
oracle attack in OpenSSL.For the stable distribution (stretch), this problem has been fixed in
version 1.0.2r-1~deb9u1.We recommend that you upgrade your openssl1.0 packages.
For the detailed security status of openssl1.0 please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/openssl1.0Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org
My amd64 Devuan system received that update today, though it might have been available earlier because that system is in a VM and runs only periodically. However, my i386 Devuan system still thinks that 1.0.2q-1~deb9u1 is the latest version of that package:
$ aptitude upgrade libssl1.0.2 -s
libssl1.0.2 is already installed at the latest version (1.0.2q-1~deb9u1), so it will not be upgraded
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Would download/install/remove packages.
Is this normal behavior?
Phil
I created a new Firefox profile to see if that would help, but it did not. I also have Devuan ASCII (64-bit) in a VM, and I tried the same test with that system. No problem there.
The Devuan ASCII system with the problem, the one that I am using right now, started out as Debian Squeeze, so it's an old system that (likely) has a considerable amount of cruft. Since I am planning to reinstall the system some time next year, I now consider this problem as solved. Thank you all for your help.
Phil
P.S. I unchecked "Allow pages to choose their own fonts, instead of your selections above", and the problem is now gone.
Looks fine to me:
https://transfer.sh/iRrGh/coupon-test.pdf
It looks fine to me too. BTW, I am using "Document Viewer", which I believe is Evince.
Here's mine:
https://transfer.sh/Ui8xn/Firefox-print-to-PDF-test.pdf
Phil
If anyone wants to test this, visit this web page:
Tamiflu Prices and Tamiflu Coupons - GoodRx
Click on one of the green buttons that read "GET FREE COUPON". After the page with the coupon loads, print the page to a PDF file.
Phil
Thank you for your reply.
I'm just assuming, you have saved a file named "pfd.js" instead of printing to a file "pdf.pdf".
Your assumption is incorrect.
Phil