You are not logged in.
Hello:
Good to know someone took over at X.Org.
Kudos to Kanapickas! 8^)
Just received this in my mbox:
---
X.Org Security Advisory: July 12, 2022
Multiple input validation failures in X server extensions
=========================================================
All theses issues can lead to local privileges elevation on systems
where the X server is running privileged and remote code execution for
ssh X forwarding sessions.
* CVE-2022-2319/ZDI-CAN-16062: X.Org Server ProcXkbSetGeometry Out-Of-Bounds
Access
The handler for the ProcXkbSetGeometry request of the Xkb extension does
not properly validate the request length leading to out of bounds memory
write.
* CVE-2022-2320/ZDI-CAN-16070: X.Org Server ProcXkbSetDeviceInfo Out-Of-Bounds
Access
The handler for the ProcXkbSetDeviceInfo request of the Xkb extension
does not properly validate the request length leading to out of bounds
memory write.
Patches
-------
Patches for this issues have been committed to the xorg server git
repository. xorg-server 21.1.4 will be released shortly and will
include these patches.
commit 6907b6ea2b4ce949cb07271f5b678d5966d9df42
xkb: add request length validation for XkbSetGeometry
No validation of the various fields on that report were done, so a
malicious client could send a short request that claims it had N
sections, or rows, or keys, and the server would process the request
for N sections, running out of bounds of the actual request data.
Fix this by adding size checks to ensure our data is valid.
Fixes ZDI-CAN 16062, CVE-2022-2319.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
commit dd8caf39e9e15d8f302e54045dd08d8ebf1025dc
xkb: swap XkbSetDeviceInfo and XkbSetDeviceInfoCheck
XKB often uses a FooCheck and Foo function pair, the former is
supposed to check all values in the request and error out on
BadLength, BadValue, etc. The latter is then called once we're
confident the values are good (they may still fail on an individual
device, but that's a different topic).
In the case of XkbSetDeviceInfo, those functions were incorrectly
named, with XkbSetDeviceInfo ending up as the checker function and
XkbSetDeviceInfoCheck as the setter function. As a result, the setter
function was called before the checker function, accessing request
data and modifying device state before we ensured that the data is
valid.
In particular, the setter function relied on values being already
byte-swapped. This in turn could lead to potential OOB memory access.
Fix this by correctly naming the functions and moving the length checks
over to the checker function. These were added in 87c64fc5b0 to the
wrong function, probably due to the incorrect naming.
Fixes ZDI-CAN 16070, CVE-2022-2320.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Introduced in c06e27b2f6fd9f7b9f827623a48876a225264132
Backporting of the security fixes also needs this commit:
f1070c01d616c5f21f939d5ebc533738779451ac.
Thanks
======
The vulnerabilities have been discovered by Jan-Niklas Sohn working with
Trend Micro Zero Day Initiative and fixed by Peter Hutterer.
--
Povilas Kanapickas
-----
Best,
O.
Hello:
For whatever it may be worth, on my main box I run Devuan Beowulf on a backported kernel:
user@devuan:~$ uname -a
Linux devuan 5.10.0-0.bpo.12-amd64 #1 SMP Debian 5.10.103-1~bpo10+1 (2022-03-08) x86_64 GNU/Linux
user@devuan:~$ And I have VirtualBox 6.1.34 running a headless Chimaera VM running PiHole 5.90 and a recursive DNS server:
user@devuan:~$ vboxmanage --version
6.1.34r150636
user@devuan:~$ user@chimaera:~$ uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
user@chimaera:~$ So my guess is that 5.10 is not a problem.
I guess it may be an issue with the kernel you are using and VM support for that kernel. (?)
Best,
A.
Hello:
Celebrate the light as it begins to turn to darkness . . .
Indeed ...
For me, yesterday was the shortest day of the year and last night was the longest one. 8^/
The good thing is that, from today onwards, days will be gradually getting <i>longer/i>.
It seems to me that few people reflect on the fact that we know that light is what it is because of the existence of darkness.
Works the other way around, obviously.
In any case, it's all about the balance of the cosmos.
Best,
A.
Hello:
... means that even if you currently have a working system, at some point something will upgrade ...
+1
Exactly the case with my Nvidia 340XX legacy cards with (up to now) no chimaera drivers.
The same thing happened with my Matrox cards a few years ago.
So ...
Then it was no more Matrox, ever.
And as of this year, it is no more Nvidia, ever.
If and when I need to get new cards, they will be AMD.
... cannot fix stupidity. Learn your lesson, sigh & walk away.
Quite so.
Best,
A.
Hello:
Found this early today.
---
Symbiote Linux malware spotted, and infections are 'very hard to detect'
'Performing live forensics on an infected machine may not turn anything up' warn researchers
---
https://forums.theregister.com/forum/al … x_malware/
Anyone know about this?
Best,
A.
Hello:
I've been following this thread as I have a parallel Devuan Beowulf setup on another drive which I keep up to date.
It is a practise bed for when I finally leave Xfce behind and go to a 100% Openbox setup.
I'd like to recover the best part of my old #! Waldorf installation.
there's also rofi, dmenu replacement ...
Seems that this app (just from reading about it) suffers from what I have seen in many other applications: feature creep.
Why can't things go back to the tried and true do one thing and do it well and just not complicate things?
I like how obmenu works and not getting it in chimaera is yet another reason to keep using beowulf with a backported kernel.
slim and wicd my other ones.
Of course, YMMV.
Best,
A.
Hello:
Saw this early today:
Original killer PC spreadsheet Lotus 1-2-3 now runs on Linux natively
As Google guru who ported it points out, the operating system did not exist when 1-2-3 came out in 1983
See:
https://www.theregister.com/2022/05/25/ … x_appears/
And:
https://lock.cmpxchg8b.com/linux123.html
I used it everyday many years ago at work, till DOS got killed and W3.10 was installed on the few available PCs.
Maybe it is finally gettings it's dues? 8^D!
A.
Hello:
... a post by a Ubuntu specialist, enigma9o7 on how to compile an
nvidia-legacy-304xx driver straight from Nvidia for Ubuntu 18.04.
Thank you. 8^)
... description for version 340.107 states that the driver does
work for xorg-xserver-1.20.
At the moment my box runs beowulf on a backported kernel ...
~$ uname -a
Linux devuan 5.10.0-0.bpo.12-amd64 #1 SMP Debian 5.10.103-1~bpo10+1 (2022-03-08) x86_64 GNU/Linux
~$ ... and xorg-xserver-1.20:
~$ cat /var/log/Xorg.0.log
[ 33.934]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[ 33.935] Build Operating System: Linux 5.10.0-10-amd64 x86_64 Debian
[ 33.935] Current Operating System: Linux devuan 5.10.0-0.bpo.12-amd64 #1 SMP Debian 5.10.103-1~bpo10+1 (2022-03-08) x86_64
--- snip ---Maybe the issue is just with 5.4 kernels.
ie: 5.4 included.
... driver does not work on kernels newer than 5.4.
I don't think I'm up to using anything other than the official Devuan kernels.
... before invoking the Nvidia installer, for the XFCE desktop, disable the compositor.
Yes.
The XFCE compositor is a PITA, screws up many things.
Has been a problem for quite a while but the devs/maintainers have taken no steps to fix it.
The old let's wait for the new release song and dance while putting the blame on something else.
So I'm slowly but steadily heading towards Openbox as the XFCE 4.16 and it's path to 5.x does not look too bright.
See:
https://forum.xfce.org/viewtopic.php?pid=56141#p56141
https://forum.xfce.org/viewtopic.php?pid=56143#p56143
https://forum.xfce.org/viewtopic.php?pid=56144#p56144
Thank you very much for taking the time to write this up.
I'll just stay with the backported beowulf kernel for the time being.
*************
Edit:
Given that the proposed solution involves downgrading the kernel (ie: to a pre 5.4 kernel) it would seem that it is not a suitable one.
At least, not a suitable answer to the OP's question: install nvidia-legacy-340xx drivers on Devuan chimaera.
This thread has had 2K views, so it's evidently of some interest to many.
ie: not a unique/one off setting.
From where I am seeing it, it should not be marked as solved.
But it's the admins say that counts.
*************
Maybe the Ubuntu people will get the chaps at Debian to do something about this Nvidia problem.
Maybe not, we'll see.
But I'm not giving up my video cards again.
Best,
A.
Hello:
@deepforest:
... it's not clear whether you've found a satisfactory solution or not.
Yes, same here.
Thanks to HevyDevy* I managed to set up the legacy 340xx drivers on beowulf and posted the terminal printout of the process.
It works with beowulf but I don't know if it will work with chimaera.
See: https://dev1galaxy.org/viewtopic.php?pid=24694#p24694
Did it work for you?
Did you have to do anything differently?
* it seems that there is a HevyDevy and a hevidevi ...
One and the same maybe?
@Len E.
... have an idea on how to do the installation ...
... won't burden you with the details ...
Please do share your solution with the forum.
Not a burden, many of us are in the same leaky Nvidia boat so all data is useful
I for one am not expecting much from nouveau and won't touch wayland.
Nvidia has recently released some source code but they did not include the source files to the 340XX blob.
Those cards are not manufactured any more so I can't see the reason for not releasing the source.
But Nvidia is Nvidia ... 8^|
I refuse to ditch a pair of perfectly working and quite suitable FX-580 Quadro cards for the lack of decent Linux drivers.
I already went through that a few years ago with a pair of Matrox G450s so if needed I'll just stay on beowulf.
A step-by-step terminal printout of the installation process like the one I posted would be of great help.
Thanks in advance.
Best,
A.
Hello:
... possibly the MemAvailable measure has lost ...
I had the exact same thought when I first saw the printout.
But no, it is correct.
The thing is that the /proc/meminfo list prints like this ...
root@OpenWrt:~# cat /proc/meminfo
MemTotal: 251868 kB
MemFree: 222268 kB
MemAvailable: 208408 kB
--- snip ---... which makes sense as they are usually progressively declining values.
ie: as I understand it (?) total will always be higher than free which will be equal to or higher than available due to buffers, cached, etc. This when swap is not part of the equation as it adds to the available memory.
I think the confusion arises because I put them the wrong way around.
ie: instead of how they are originally listed.
Now it looks like it makes sense:
~$ ssh user@192.168.1.3
--- snip ---
uptime: 32 min
ui: inactive
daemon: running
mem free: 222312 kB
mem available: 208392 kB
sda1 free/used: 3.6M 53%
sda3 free/used: 362.6G 58%
hd temp: 36°C
~# Thank you for pointing that out.
Best,
A.
Hello:
printf '%s\t%s\n' "hd temp:" "${_drive_temp}°C"
Done.
~$ ssh user@192.168.1.3
--- snip ---
uptime: 9 min
ui: inactive
daemon: running
mem available: 208392 kB
mem free: 222252 kB
sda1 free/used: 3.6M 53%
sda3 free/used: 362.6G 58%
hd temp: 26°C
~$ I prefer Kelvin.
Cool! 8^D
Thank you for your input.
Best,
A.
Hello:
... check it out ...
... report back as soon as I figure out ...
It took me a while, eventually got a decent result.
Trimmed it a bit so that what I get is just the essential information.
This:
#!/bin/sh
PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin"
# \t adds tab characters
# \n adds new lines
# %s defines strings which are listed afterwards
# awk can search so no need for grep
_uptime=$(uptime| sed 's/.*up \([^,]*\), .*/\1/')
_rsync_status=$(sudo /etc/init.d/rsyncd status) # OK needs root x ash
_memavail=$(grep -i memavailable /proc/meminfo | cut -c 19-27) # OK no cats harmed
_memfree=$(grep -i memfree /proc/meminfo | cut -c 19-27) # OK no cats harmed
_fs_status1=$(df -h | grep -vE '^Filesystem|/dev/root|tmpfs' | cut -c 6-70 | grep -i sda1 | cut -c 40-50)
_fs_status2=$(df -h | grep -vE '^Filesystem|/dev/root|tmpfs' | cut -c 6-70 | grep -i sda3 | cut -c 40-50)
_drive_temp=$(sudo smartctl -a -d ata /dev/sda | awk '/Temperature/ {print $10}')
printf '%s\t\t%s\n' "uptime:" "$_uptime" # OK
printf '%s\t\t%s\n' "daemon:" "$_rsync_status" # OK
printf '%s\t%s\n' "mem available:" "$_memavail" # OK
printf '%s\t%s\n' "mem free:" "$_memfree" # OK
printf '%s\t%s\n' "sda1 free/used:" "$_fs_status1" # OK
printf '%s\t%s\n' "sda3 free/used:" "$_fs_status2" # OK
printf '%s\t' "hd temp:" "$_drive_temp" # OKGets me this when I ssh to the NAS:
~$ ssh user@192.168.1.3
--- snip ---
uptime: 2:34
daemon: running
mem available: 210064 kB
mem free: 226420 kB
sda1 free/used: 3.6M 53%
sda3 free/used: 362.6G 58%
hd temp: 48
~$ Seems good enough and the info is there.
Could not figure out how to get the °C after the temperature [number] print but it is just for me.
And I've been a Celsius man all my life. =^ )
Your pointers on lines, characters and strings were a big help.
Best,
A.
Edit: spelling/format.
Hello:
#!/bin/sh _uptime=$(uptime|cut -c 2-19) _rsync_status=$(/etc/init.d/rsyncd status) # does not need root! _memavail=$(grep -i memavailable /proc/meminfo) # save those poor cats! _memfree=$(grep -i memfree /proc/meminfo) # ditto _fs_status=$(df -h|awk '/^Filesystem/||/\/dev\/root/||/tmpfs/{ print $5 " " $1}') # awk can search so no need for grep _drive_temp=$(sudo smartctl -d ata -A /dev/sda | grep Temperature | cut -c 5-8,87-89) printf '%s\t\t%s\n\n' "uptime:" "$_uptime" # \t adds tab characters, \n adds new lines, %s defines strings which are listed afterwards printf '%s\t%s\n\n' "rsync daemon status:" "$_rsync_status" printf '%s\n%s\n%s\n\n' "memory status:" "$_mem_avail" "$_mem_free" printf '%s\t%s\n\n' "filesystem status:" "$_fs_status" # might not work :/ printf '%s\t%s\n' "drive temperature" "$_drive_temp"
Right ...
I'll check it out tonight and report back as soon as I figure out how it works.
... trapped in Windows atm ...
You'll manage. ;^ )
... post back later when I'm in a proper OS...
Thank you for your input.
Best,
A.
Hello:
I have this script running on ssh login:
#!/bin/sh
PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin"
echo uptime:
# run uptime - no load stats
uptime | cut -c 2-19
echo
echo rsync daemon status:
# run alias daemon
sudo /etc/init.d/rsyncd status
echo
echo memory status:
cat /proc/meminfo | grep -i memavailable && cat /proc/meminfo | grep -i memfree
echo
echo filesystem status:
# run alias fschk
df -h | grep -vE '^Filesystem|/dev/root|tmpfs'| awk '{ print $5 " " $1}'
echo
echo drive temperature:
# run alias tempchk
sudo smartctl -d ata -A /dev/sda | grep Temperature | cut -c 5-8,87-89
echo
echo filesystem health:
# run alias drivechk
sudo dmesg | grep -i ext4-fs | grep -i sdaThis is the terminal printout:
uptime:
10:46:23 up 0 min,
rsync daemon status:
running
memory status:
MemAvailable: 211716 kB
MemFree: 228924 kB
filesystem status:
53% /dev/sda1
58% /dev/sda3
drive temperature:
Temp 22How can I get it to print out in this format?
uptime: 10:46:23 up 0 min,
rsync daemon status: running
memory status:
MemAvailable: 211716 kB
MemFree: 228924 kB
filesystem status: 53% /dev/sda1
58% /dev/sda3
drive temperature: Temp 22Thanks in advance.
Best,
A.
Edit: spelling
Hello:
... completely off-topic for these boards ...
... your continued posting of OpenWRT-related issues on these boards is starting to look like spam.
Hmm ...
spam? 8^D !
spam: noun
unsolicited usually commercial messages (such as emails, text messages, or Internet postings) sent to a large number of recipients or posted in a large number of places
Before I say anything else, I want to say this: I value your opinions, expertise and the help provided to me more than once.
But it seems to me that you are overreacting.
In doing so you are not being rude but much worse than that: you are out of place.
Please don't take my observation personally for it is not personal.
Bear in mind that although my questions do have a relationship to OpenWRT, you may want to consider that although it is not Devuan, both distributions share 1. that they are Linux and 2. they do not use systemd.
And most importantly, my questions are related to uses/tools which are common to both of them.
That said, I'll leave this for the Dev1 admins to opine on and will abide by whatever they decide on the matter.
-------
Edit:
In case you or anyone else is interested, I found a solution to the question with which I started this thread.
Using common Linux tools.
~$ sudo /etc/init.d/rsyncd status
running
~$Added another line to /etc/profile.d/custom.sh: alias daemon="sudo /etc/init.d/rsyncd status"
And that was it.
~$ daemon
running
~$The daemon alias will be part of a script which will run anytime I ssh into the NAS and provide me at a glance with basic stats I want to know when I check on it.
-------
Thank you for your input.
Best,
A.
Hello:
... will show a (colon-separated) list ...
... run that command from OpenWRT then it will probably not have /usr/sbin/ listed ...
But it does:
groucho@OpenWrt:~$ echo $PATH
/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin
groucho@OpenWrt:~$ ... ask on the OpenWRT forums instead.
I always look for answers in search engine/s, then here and then elsewhere. In that order. 8^ )
After all OpenWRT is just Linux in a very compact package to fit in embedded systems.
But you have to coax it to do regular Linux things, like adding users and sudoers.d files.
There's always something new to learn.
... not think to try ...
Of course.
:~$ /usr/sbin/service rsyncd status
-ash: /usr/sbin/service: not found
:~$ :~# /usr/sbin/service rsyncd status
-ash: /usr/sbin/service: not found
:~# But ...
:~# service rsyncd status
running
:~# The thing is that the stanza service rsyncd status is not validated by visudo which needs to see a path.
I think this may be related to BusyBox.
Thanks a lot for your input.
Best,
A.
Hello:
... you (again?)
Yes, always ... 8^D
... confused by groucho not having /usr/sbin in PATH (and not /sbin).
Hmm ...
I'm sorry, I think I am being confusing.
The example I show previously is how I run dmesg as sudo in both my main Devuan box and the NAS.
Both my main Devuan box and the NAS have only root and my user (groucho) so it does not matter much.
But you are right, got to fix that.
Now, in my Devuan box, I can find service:
[root@devuan ~]# which service
/usr/sbin/service
[root@devuan ~]# But not in my NAS:
root@OpenWrt:~# which service
root@OpenWrt:~# root@OpenWrt:~# /usr/bin/service
-ash: /usr/bin/service: not found
root@OpenWrt:~# That said, I have not been able to find an example of a sudoers file for this on the web.
Thanks for your input.
Best,
A.
Hello:
When I need to check the status of a service in a Linux box I use this command as root:
:~# service rsyncd status
running
:~# If I want to do this as a user instead of being root, I'd generate a specific sudoers file to add to /etc/sudoers.d.
Like this one I use to run dmesg:
:~$ sudo cat /etc/sudoers.d/user_dmesg
groucho ALL = NOPASSWD:/bin/dmesg
:~$ This because I am convinced that the use of sudo, like a few other things in life, needs to be under check.
I'm at odds with it and can't find a way to get a users_service file that works.
I'd appreciate some help with that.
Thanks in advance,
A.
Hello:
Sorry, that should have been ...
No worries whatsoever, HoaS. ;^ )
Thanks (again) for your input.
Best,
A.
Hello:
... question of mixing amd64 & i386?
Really cannot say for sure.
What I can say is that ~$ apt list | grep installed | grep i386 shows me a list of 203 files.
ie: if I managed to count correctly at this hour.
Save these 10, all the rest are lib***:
~$ apt list | grep installed | grep i386 | more
elogind/oldstable,now 241.4-2 i386 [installed,automatic]
gcc-6-base/now 6.3.0-18+deb9u1 i386 [installed,local]
gcc-8-base/oldstable,now 8.3.0-6 i386 [installed,automatic]
gstreamer1.0-plugins-base/oldstable,oldstable-security,now 1.14.4-2+deb10u1 i386 [installed,automatic]
--- snip ---
mesa-va-drivers/oldstable,now 18.3.6-2+deb10u1 i386 [installed]
mesa-vdpau-drivers/oldstable,now 18.3.6-2+deb10u1 i386 [installed,automatic]
ocl-icd-libopencl1/oldstable,now 2.2.12-2 i386 [installed,automatic]
vdpau-driver-all/oldstable,now 1.1.1-10 i386 [installed,automatic]
wine32/oldstable,now 4.0-2 i386 [installed,automatic]
zlib1g/oldstable-security,now 1:1.2.11.dfsg-1+deb10u1 i386 [installed,automatic]
~$Of the whole of them, 183 were installed,automatic while only 2 were installed,local.
~$ apt list | grep installed | grep i386 | grep local | more
gcc-6-base/now 6.3.0-18+deb9u1 i386 [installed,local]
libicu57/now 57.1-6+deb9u4 i386 [installed,local]
~$ This leaves 17 that are just [installed].
ie: not [automatic] or [local].
There's probably a way to see what pulled these i386 file in.
One application that comes to mind is wine.
Hope it clears up something.
Best,
A.
Hello:
Use apt install --target beowulf-backports rsync libzstd.
No, seems it would not work.
groucho@devuan:~$ sudo apt install --target beowulf-backports rsync libzstd
--- snip ---
E: Command line option --target is not understood in combination with the other options
groucho@devuan:~$ I use aptitude very little, usually with the why option.
Thanks for your input.
Best,
A.
Hello:
Perhaps you'll need to upgrade the i386 version at the same time, by adding libzstd1:i386/beowulf-backports to the install line?
That would seem to do the trick:
groucho@devuan:~$ sudo apt install rsync/beowulf-backports libzstd1/beowulf-backports libzstd1:i386/beowulf-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '3.2.3-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [amd64]) for 'rsync'
Selected version '1.4.4+dfsg-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [amd64]) for 'libzstd1'
Selected version '1.4.4+dfsg-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [i386]) for 'libzstd1:i386'
The following additional packages will be installed:
libxxhash0
Suggested packages:
openssh-server
The following NEW packages will be installed:
libxxhash0
The following packages will be upgraded:
libzstd1 libzstd1:i386 rsync # <- what was needed
3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. # <- nothing removed
Need to get 840 kB of archives.
After this operation, 41.0 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
groucho@devuan:~$ I'll try that and report later.
Edit:
Minutes later ...
:~$ rsync -V
rsync version 3.2.3 protocol version 31
Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, hardlink-specials, symlinks, IPv6, atimes,
batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv,
symtimes, prealloc, stop-at, no crtimes
Optimizations:
SIMD, asm, openssl-crypto
Checksum list:
xxh64 (xxhash) md5 md4 none
Compress list:
zstd lz4 zlibx zlib none
--- snip ---
:~$ Now the Devuan and OpenWRT versions of rsync match.
Thanks for your input.
Best,
A.
Hello:
Or am I missing something?
Just to check, I thought maybe it was a question of installing libzstd1 1.4.4+dfsg-3~bpo10+1 as libzstd1 1.3.8+dfsg-3+deb10u2 was already installed.
ie: for some reason not being updated and be specifically installed from beowulf-backports.
But when I tried I got this huge list of files that are no longer required/removed:
:~$ sudo apt install libzstd1/beowulf-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.4.4+dfsg-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [amd64]) for 'libzstd1'
The following packages were automatically installed and are no longer required:
gstreamer1.0-plugins-base:i386 libaom0:i386 libavresample4:i386 libavutil56:i386
libblkid1:i386 libcairo2:i386 libcapi20-3:i386 libcdparanoia0:i386 libcodec2-0.8.1:i386
libcroco3:i386 libcrystalhd3:i386 libdatrie1:i386 libexif12:i386 libfontconfig1:i386
libfreetype6:i386 libfribidi0:i386 libgcrypt20:i386 libglib2.0-0:i386 libgomp1:i386
libgpg-error0:i386 libgphoto2-port12:i386 libgpm2:i386 libgraphite2-3:i386 libgsm1:i386
libgstreamer-plugins-base1.0-0:i386 libgstreamer1.0-0:i386 libharfbuzz0b:i386
libicu63:i386 libjack-jackd2-0:i386 libmount1:i386 libmp3lame0:i386 libncurses6:i386
libnuma1:i386 libopenjp2-7:i386 libopus0:i386 liborc-0.4-0:i386 libpango-1.0-0:i386
libpangocairo-1.0-0:i386 libpangoft2-1.0-0:i386 libpixman-1-0:i386 libpng16-16:i386
libsamplerate0:i386 libsdl2-2.0-0:i386 libshine3:i386 libsnappy1v5:i386 libsoxr0:i386
libspeex1:i386 libswresample3:i386 libthai0:i386 libtheora0:i386 libtwolame0:i386
libusb-1.0-0:i386 libv4l-0:i386 libv4lconvert0:i386 libva-drm2:i386 libva-x11-2:i386
libvdpau-va-gl1:i386 libvdpau1:i386 libvisual-0.4-0:i386 libvkd3d1:i386 libvpx5:i386
libvulkan1:i386 libwavpack1:i386 libwayland-client0:i386 libwayland-cursor0:i386
libwayland-egl1:i386 libwebp6:i386 libwebpmux3:i386 libx264-155:i386 libx265-165:i386
libxcb-render0:i386 libxcb-shm0:i386 libxcomposite1:i386 libxcursor1:i386 libxinerama1:i386
libxkbcommon0:i386 libxml2:i386l ibxpm4:i386 libxrandr2:i386 libxrender1:i386
libxslt1.1:i386 libxss1:i386 libxvidcore4:i386 libzvbi0:i386 mesa-vdpau-drivers:i386
ocl-icd-libopencl1:i386 vdpau-driver-all:i386
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
libasound2-plugins:i386
libavcodec58:i386
libgd3:i386
libgdk-pixbuf2.0-0:i386
libgphoto2-6:i386
librsvg2-2:i386
librsvg2-common:i386
libtiff5:i386
libwine:i386
libzstd1:i386
wine32:i386
The following packages will be upgraded:
libzstd1
1 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
Need to get 249 kB of archives.
After this operation, 241 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
:~$ The first thing I notice is that they are all :i386 but I'm not sure of the consequences.
What were they for in the first place?
I'd appreciate an opinion.
Thanks in advance.
Best,
A.
Hello:
My NAS running OpenWRT uses rsync version 3.2.3 protocol version 31 and my Devuan running with a backported kernel uses rsync version 3.1.3 protocol version 31.
beowulf-backports has rsync version 3.2.3-3~bpo10+1, which would be a match.
This is what I get when I try to install it:
:~$ sudo apt install rsync/beowulf-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '3.2.3-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [amd64]) for 'rsync'
Selected version '1.4.4+dfsg-3~bpo10+1' (Devuan Backports:3.0.0/oldstable-backports [amd64]) for 'libzstd1' because of 'rsync'
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:
rsync : Depends: libzstd1 (>= 1.4.4+dfsg-3~bpo10+1) but 1.3.8+dfsg-3+deb10u2 is to be installed
E: Unable to correct problems, you have held broken packages.
:~$ So ...
Does this mean that I cannot install it because beowulf-backports has libzstd1 1.3.8+dfsg-3+deb10u2 and not 1.4.4+dfsg-3~bpo10+1?
Or am I missing something?
Thanks in advance.
Best,
A.
Hello:
You were on the right track.
Just before dinner I was able to solve the problem via an answer to a post at Stack Exchange.
The problem was in the path for the module/s: it was missing the lowest level.
I had this:
[stuff]
--- snip ---
path = /mnt/sda3
--- snip ---But it should have been this:
[stuff]
--- snip ---
path = /mnt/sda3/stuff
--- snip ---ie: /mnt/sda3/stuff instead of /mnt/sda3
After I fixed it and rsync was working properly, I am getting a ~19MiB transfer rate.
It is not much to write about as this NAS would get 2x that with the original firmware, but ~2.5x what I was getting via ssh.
Thank you very much for your input.
Best,
A.