Posts by Altoid

Altoid · Other Issues

Hello:

fsmithred wrote:

For the initial transfer, maybe you can bypass the router ...

Yes, that would work.
But it's rather a hassle to do the setup.

fsmithred wrote:

... you could add a faster router ...

I've been looking at second hand 4/5 port gigabit routers and desktop switches to plug in all my gear ie: box, netbook and NAS.
Nothing into the router save the new router/switch.

That way the link from box to NAS would go through the GB router/switch and not through the telco router with the 100M ports.
Am I correct?

If so, maybe just a 'dumb' desktop switch would do the trick?

fsmithred wrote:

Not sure about how the phone works but it might be possible ...

I am having a contentious issue with the local telco regarding VoIP, which they are intent in shoving down my throat.
I don't want it but they insist, to the point of threatening to cut my land line and leave me without a phone.

So I'd rather not muck with the ADSL router's setup.
They have a habit of resetting it remotely and screwing up the DNS settings pointing to a VM running inside my box (Pi-Hole+Unbound).

Think a 'dumb' switch may do well enough?

Thanks for your input.

Best,

A.

Altoid · Other Issues

Hello:

fsmithred wrote:

... 11MB/s with rsync or sftp on the local network, Cat6 with gigabit router.

My telco provided ADSL router config page says that LAN/WAN speed in both ports (my box and the NAS) is 100M/Full.

My box has an on-board 82566DM-2 Gigabit Network adapter.
The WD My Book NAS has a Gigabit Ethernet port.

Seems the problem is the bloody router as everything goes through there.
No wonder.

Can't change the telco router. I'd lose my landline.

Any suggestions?

Thanks in advance.

Best,

A.

Altoid · Other Issues

Hello:

For backing up what I have in my box I use two applications: Timeshift and BackInTime.

Timeshift takes system snapshots and BackInTime takes /user/home snapshots with the usual exclusions.
It has always worked quite well.

Up to now, all the generated snapshots were stored on a separate 2.5" SATA 500Gb drive rigged into the box.
It has one partition and two directories: /media/bkups/backintime and /media/bkups/timeshift.

This was not the ideal solution and after procrastinating for the longest while got a 1TB NAS to back-up the contents of that 500Gb drive.
The back-up drive inside the box is 38% used ie: 174GiB / 457GiB according to my conky panel.

Late yesterday I set about doing the first rsync from my box to the NAS.

[root@devuan ~]# rsync -a -stats ~/media/bckups root@192.168.1.3:/mnt/sda3

I started it @22:55 last night and it is still going ... @17:00 !

I understand that a first sync to an empty drive takes much longer and that file size ie: a great many small files can make the operation last a lot longer.

But it's been almost 18 hours.
Maybe I should have cp'd everything over first?

The conky panel says:

Outgoing: 6.57MiB /s total: 410GiB

Does that not seem like a lot of overhead?

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

For those who have not purged log4j from their systems:

Originally mentioned here (late December 2021) at Dev1 by hevidevi here ...

https://dev1galaxy.org/viewtopic.php?id=4715

... and then press here:

https://www.theregister.com/2022/03/16/ … net_log4j/

We now have this:

https://www.theregister.com/2022/04/20/ … j_patches/

Jessica Lyons Hardcastle @ The Register wrote:

Amazon Web Services has updated its Log4j security patches after it was discovered the original fixes made customer deployments vulnerable to container escape and privilege escalation.
The vulnerabilities introduced by Amazon's Log4j hotpatch – CVE-2021-3100, CVE-2021-3101, CVE-2022-0070, CVE-2022-0071 – are all high-severity bugs rated 8.8 out of 10 on the CVSS.

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

/usr/local/bin/ is not in your user's PATH ...

Yes. v

Altoid wrote:

I did not want to get into fussing with PATH.
I still have to find where it is set ... 8^|

Head_on_a_Stick wrote:

No idea ...

It is not in the *.img and editing /etc/*preinit did not work.
You have to create /etc/profile.d and populate it accordingly.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

hevidevi wrote:

Thanks ...

You're welcome.

hevidevi wrote:

... a try myself.

Obviously, the use you can give it depends on the hardware you run it on.
eg: I use a MyBook Live which has a SATA HD instead of firmware.

As this would be OT/non Devuan, feel free to contact me.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

hevidevi wrote:

... a way to create a regular user on this OpenWrt ...

Yes.

It is not as straight forward as in a regular distribution because the tools are not installed by default.
In these router firmwares such as OpenWRT (an OS by any other name), space is at a premium.

So if it is not needed, it is not in the image to install.
And if you need it, make sure it is not in BusyBox before you install it.

That said, first you have to install at least these files from the OpenWRT repository:

To manage groups in your system.

shadow-groups
shadow-groupadd
shadow-groupdel

To manage users in your system:

shadow-useradd
shadow-userdel
shadow-usermod

You may also want to install sudo to put your user in /etc/sudoers.d/ with strict premissions for specific tasks that require elevated privileges.

You then proceed more or less as would be usual in a regular distributions.
Some things you'll have to do by hand.

There are quite a few more shadow-* files available but I still have to see what they are about.
eg: shadow-login, shadow-logout.d, shadow-passwd, etc.

Unfortunately, the wiki pages about OpenWRT packages are all but empty.

Check this page: https://openwrt.org/docs/guide-user/base-system/users

groucho@OpenWrt:~$ whoami
groucho
groucho@OpenWrt:~$

groucho@OpenWrt:~$ groups
adm ftp users network ntp groucho
groucho@OpenWrt:~$

Edit: keep in mind that a regular user ie: not root can only log in via ssh.

I think there may be a file in the repository that would add something to the UI to be able to add another user.
Can't recall if it was OpenWRT or the WD software.

If you find anything interesting, please let let me know.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

... could have moved /root/shutdown to /usr/bin/ ...

Originally I had it in /usr/local/bin.
As I could not get it to work unless I used ./, I moved it.
I did not want to get into fussing with PATH.
I still have to find where it is set ... 8^|

Head_on_a_Stick wrote:

... could have added /root/ to PATH ...

Hmm ...
I may have a thing for abusing cat ...
But I do know that is not a thing to do.

Head_on_a_Stick wrote:

... placing the actual script itself at /usr/bin/shutdown seems more sensible.

OK.
It works well as it is but I'll move it to its proper place later today.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Head_on_a_Stick wrote:

# mv /usr/bin/closebook.sh /usr/bin/shutdown

Perfect. 8^)
Thank you very much.

Could you tell me what I was doing wrong?
Was it having script to call another one?

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

hevidevi wrote:

... maybe in your closebook.sh script you should not declare the PATH=/bin:/sbin ...

I put it in just in case the system path has some issue.
Belt and suspenders thing.

But that would not seem to be the problem because the script is found and the executables in it are run properly.

What is not being found is the script that calls closebook.sh unless I run it as ./shutdown.

I just realised that the /root folder is not in the system PATH variable:

root@OpenWrt:~# $PATH
-ash: /usr/sbin:/usr/bin:/sbin:/bin: not found
root@OpenWrt:~#

This one:

root@OpenWrt:~# ls
shutdown
root@OpenWrt:~#

Which you can see here:

root@OpenWrt:/# ls
bin         dev         lib         mnt         proc        # root #        srv         tmp         var
boot        etc         lost+found  overlay     rom         sbin        sys         usr         www
root@OpenWrt:/#

No idea as to how to follow up.
Surely it is not a good idea to have the root folder in the path.

Thanks for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Still playing around with my new My Book Live thingy, trying to set up a solution to the lack of a shutdown command in this PowerPC 44x processor.
This is the OpenWRT installed on the unit:

~# uname -a
Linux_book 5.4.179 #0 Wed Feb 16 20:29:10 2022 ppc GNU/Linux
~#

I wrote a script to shut down the board gracefully:

root@OpenWrt:/usr/bin# cat closebook.sh
#!/bin/sh
# script to stop drive and shut down MBL
# gives ~15s from blue led <on> to unplug unit
PATH=/bin:/sbin

sync && wait && hdparm -Y /dev/sda && wait && halt
root@OpenWrt:/usr/bin#

The script is executable:

root@OpenWrt:~# ls -l /usr/bin/closebook.sh
-rwxr-xr-x    1 root     root           166 Apr 17 08:40 /usr/bin/closebook.sh
root@OpenWrt:~#

Once the front LED goes from green to blue, you have to physically disconnect power to the board within ~15s, otherwise a watchdog will sense the new situation and proceed to reboot the board.

For the time being, I call the /usr/bin/closebook.sh from ~/ with another script:

root@OpenWrt:~# cat shutdown 
#!/bin/sh
sh -c '/usr/bin/closebook.sh'
root@OpenWrt:~#

The script is executable:

root@OpenWrt:~# ls -l shutdown
-rwxr--r--    1 root     root            40 Apr 17 10:07 shutdown
root@OpenWrt:~#

It works as intended and have not had an instance where the plug was pulled late or where the watchdog reboot caused any issues.
Unsurprisingly, not shutting down in this manner will always cause dmesg to print this:

[    0.907630] EXT4-fs (sda2): warning: mounting unchecked fs, running e2fsck is recommended
[    5.802598] EXT4-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended

The main problem is that while /dev/sda1 but can be unmounted to run e2fsck, /dev/sda2 holds the rootfs and cannot be unmounted:

root@OpenWrt:~# blkid
--- snip ---
/dev/sda2: LABEL="rootfs" UUID="ff313567-e9f1-5a5d-9895-3ba130b4a864" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="228c756a-02"
--- snip ---
root@OpenWrt:~#

But I digress ...

The thing is that to run the script I have to do it with ./, otherwise it is not found:

root@OpenWrt:~# shutdown
-ash: shutdown: not found
root@OpenWrt:~#

This even though I am running it as root and it is located in what would be home directory:

root@OpenWrt:~# ls
shutdown
root@OpenWrt:~#

The system's $PATH:

root@OpenWrt:~# $PATH
-ash: /usr/sbin:/usr/bin:/sbin:/bin: not found
root@OpenWrt:~#

I'm sure it is a $PATH issue ...

What am I doing wrong?

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

hevidevi wrote:

... that system would have to enable some sort of admin ...
... possible to build busybox ash, bash with certain flags to enable ...

Could be.
But the idea is to avoid building anything with/for OpenWRT as it would complicate eventual sysupgrades.

I found this:
https://forum.sailfishos.org/t/busybox- … sh/6808/11

Not really a big deal.
When I finally get this NAS figured out and running as I want, I won't be needing access all the time like I'm having to do now.
I'll mark this thread solved.

Thanks for your input.

A.

Altoid · Off-topic

Hello:

golinux wrote:

Why would anyone want systemd in the first place?

Indeed ...
+1 8^D

systemd is the absolute opposite of basic Linux philosophy.
ie: Write programs that do one thing and do it well.

A.

Altoid · Hardware & System Configuration

Hello:

hevidevi wrote:

try these in your .bashrc if you do not already have them.
export HISTSIZE=10000
export HISTFILESIZE=10000
export HISTCONTROL=ignorespace:ignoredups

Hmm ...
I don't have a user set up on this system.
Maybe that's the reason? Have not had time to set up sudo either yet.

Edit:

I keep forgetting that this is a small footprint OS for embedded systems, a very different type of Linux.
That means that I should look in the right place and not bug my fellow Dev1 members.

OpenWRT does not use bash but ash.

From: https://forum.openwrt.org/t/enable-bash-history/70815

Ash (mainly the dash fork) is also fairly popular in embedded Linux systems. dash version 0.3.8-5 was incorporated into BusyBox 3, the catch-all executable often employed in this area, and is used in distributions like DSLinux, Alpine Linux 1, Tiny Core Linux and Linux-based router firmware such as OpenWrt, Tomato and DD-WRT.

and

ash is provided by busybox, which provides all basic shell & Linux default app features in OpenWrt.
You can enable the history feature in busybox and recompile a personal version of it for yourself, so that you can have ash that remembers history.

ash is part of the firmware image and while I can install the bash package, it will not survive a system upgrade.

There seems to be a work-around, I'll have to investigate further.

Thanks a lot for your input.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Playing around with SSH and my new My Book Live thingy, i have found a few things I'm used to do not work as expected.

This is the OpenWRT installed on the unit:

~# uname -a
Linux_book 5.4.179 #0 Wed Feb 16 20:29:10 2022 ppc GNU/Linux
~#

dmesg shows this:

One of those things is the bash history I use a lot.
It is an important part of my slow-ish training to eventually master the use of the terminal as much as possible.
eg: the history does not survive a reboot of the system.

How can I fix this?

Thanks in advance,

A.

Altoid · Hardware & System Configuration

Hello:

Altoid wrote:

... example of 2020's firmware for this system ...
... OpenWRT
... if anyone here has done anything on these WD thinguies.

Seems I'm the only one here scavenging on old hardware. 8^D

I'll mark this thread as solved.

I have managed to successfully install OpenWRT 21.02.2 to the WD-MBL and it is working, albeit with an expected issue: it seems that the APM821xx processor does not have a way to poweroff or even halt.

So while I'm installing a couple of missing utils I see if I can find a suitable work around, maybe with a script and a switch for when it needs to be moved or taken off-line for a few days.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

garyk wrote:

You may find this helpful.

Thanks but I finally managed to successfully reset the unit late tonight.
After that it got assigned a proper IP by the router and I can access it via ssh and the UI via a browser.

After checking it out, I see it runs on an old linux kernel:

~# uname -a
Linux MyBookLive 2.6.32.11-svn70860 #1 Thu May 17 13:32:51 PDT 2012 ppc GNU/Linux
~#

I have to look into something newer without all the media suff the original FW has as I want to use it as a backup drive.
eg: Twonky, iTunes, etc.

But there's does not seem to be much available for PowerPC/ppc32 these days as Debian dropped support when Debian 8 came out.

The only example of 2020's firmware for this system that I have come across is OpenWRT which also has regular updates.
Also found someone who says he's been running Gentoo for about 10 years on his various units but he has now switched them all to OpenWRT.

I wonder if anyone here has done anything on these WD thinguies.

Thanks for your input.

Best,

O.

Altoid · Hardware & System Configuration

Hello:

Yewsterday I came across a practically new 1Tb MyBook Live for a bit under US$30 (!) and as I am needing a better backup routine, I went for it.
My only worry was that the 1Tb SATA drive would have some dings but even if it did, the hardware in the box was worth it.

The thing runs on an APM82181@800 MHz CPU, 256MB + 512Kb flash.
It has a SATA bay and Gigabit Ethernet LAN but no USB port.

After resetting it, when I hooked it up to the router it reported the proper MAC address with a 169.254.7.194 IP address.
Not the expected 192.168.1.1 or thereabouts.

As I was not able to get into the UI via browser, ssh or in any way get into the system and as I still had to check the drive before going forward, I decided to disassemble the case to remove the drive and hook it up to my main box with the idea of modifying a configuration file to set up another IP.

disks and gparted reported nothing nasty and gsmartcontrol gave it a clean bill of health.
No grown defects.

This is the drive's data and layout:

Model: WDC WD10EURX-63FH1Y0 (01.01A01)
Size: 1.0 TB (1,000,204,886,016 bytes)
Partitioning: GUID Partition Table
Serial: WD-WMC1U7235566

freespace   | swap partition 3 | partition 1       | partition 2       | partition 4: primary
16Mb        | 513Mb            | 2.0Gb             | 2.0Gb             | 996Gb
unallocated | basic data       | linux raid        | linux raid        | filesystem
                               | linux raid member | linux raid member | ext4

Unfortunately, I cannot mount the primary partition and get this error:

Error mounting /dev/sda4 at /media/groucho/7599bee0-ee74-4354-9c41-dbc05d70b49d: wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or helper program, or other error

When I try lsblk to see what's there I get this:

~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
|-sda1   8:1    0   1.9G  0 part 
|-sda2   8:2    0   1.9G  0 part 
|-sda3   8:3    0   489M  0 part 
`-sda4   8:4    0 927.2G  0 part 
--- snip ---
~$

When I try parted to see what's there I get this:

~$ parted -l
[sudo] password for groucho: 
Model: ATA WDC WD10EURX-63F (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 3      15.7MB  528MB   513MB                primary  msftdata
 1      528MB   2576MB  2048MB  ext3         primary  raid
 2      2576MB  4624MB  2048MB  ext3         primary  raid
 4      4624MB  1000GB  996GB   ext4         primary  msftdata
--- snip ---
~$

What confounds me is the gpt partition table, this is a 1TB drive and other configurations only go to 3Tb.
And the msftdata flag.

I have no Windows installation to do anything with.

There is the also possibility of using WRT instead of the WD software.
I'm sure it won't have the problems thousands of users had last year.

Any ideas?

Thanks in advance.

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Marjorie wrote:

... installed a new version of zlib1g:amd64 (1:1.2.11.dfsg-2+deb11u1) from Chimaera-security this morning.

Thanks for the update on this.

Last night I updated my netbook and main box running Beowulf backported and saw the upgrade come in.

The following packages will be upgraded:
  rsyslog zlib1g zlib1g:i386 zlib1g-dev

Seems all is well and right on time as usual with Linux Devuan. 8^D

Best,

A.

Altoid · Hardware & System Configuration

Hello:

Marjorie wrote:

... fixed in Debian for Bookworm and Sid ...
... Stretch, Buster and Bullseye have yet to be fixed.
... expect it will be fixed shortly ...
... stable and older remain vulnerable ...

Thanks for the information.
I guess we can wait a bit more, it's been out there forever. ;^)

Best,

A.

Altoid · Hardware & System Configuration

Hello:

This article came up yesterday at ElReg:

Zlib crash-an-app bug finally squashed, 17 years later.
https://www.theregister.com/2022/03/30/ … /?td=rt-4a

It is about a long standing bug in the zlib data-compression library.
Having been reported in 2018, it was never looked at or fixed.
Until now.

https://www.openwall.com/lists/oss-secu … 22/03/24/1

Jessica Lyons Hardcastle @The Register wrote:

A patch is available on Github, and security analysts recommend updating to Zlib version 1.2.12. Linux distros Ubuntu and Alpine, to name two, have also implemented the fix in their latest releases.

Don't know how problematic this can be for the everyday Devuan user.
It has been out there forever ...

Best,

A.

Altoid · Installation

Hello:

myself wrote:

... seems the problem is with the wrong version of the dkms package.

I was able to fix it all by doing a manual installation:

apt -t beowulf-backports install nvidia-legacy-340xx-driver --no-install-recommends

Now ...

~$ apt list | grep installed | grep legacy-340xx
--- snip ---
libegl1-nvidia-legacy-340xx/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
libgl1-nvidia-legacy-340xx-glx/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
libgles1-nvidia-legacy-340xx/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]
libgles2-nvidia-legacy-340xx/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]
libnvidia-legacy-340xx-cfg1/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]
libnvidia-legacy-340xx-eglcore/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
libnvidia-legacy-340xx-glcore/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
libnvidia-legacy-340xx-ml1/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-alternative/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver-bin/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver-libs/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]
nvidia-legacy-340xx-kernel-dkms/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-kernel-support/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-legacy-340xx-vdpau-driver/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
nvidia-settings-legacy-340xx/oldstable,now 340.108-1~deb10u1 amd64 [installed]
xserver-xorg-video-nvidia-legacy-340xx/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed,automatic]
~$

I think (?) what was happening is related to what rolfie points out here:

https://dev1galaxy.org/viewtopic.php?pid=35311#p35311

In any case, now it works.

Best,

A.

Altoid · Installation

Hello:

After my success with updating the backported kernel in my main Beowulf box, I decided to do the same with my parallel Beowulf installation.
It lives on a separate drive in the same box, albeit with a spartan Openbox desktop which is operational but unfinished.

As I was going through the update, I noticed that it was going to Linux devuan 5.10.0-0.bpo.12-amd64 which when I did the same in my main box had not yet been signed.

On reboot, just like with my main box, I was not able to get X started so followed the steps I took here to get things fixed:

https://dev1galaxy.org/viewtopic.php?id=4948

Basically install what was missing via ...

# apt -t beowulf-backports install linux-image-amd64
and
# apt -t beowulf-backports install linux-headers-amd64

But no, no cigar.

There seems to be some sort of dependency problem somewhere.
Here is what I could fish out of /var/log/apt/term.log:

Log started: 2022-03-22  17:32:49
Setting up nvidia-legacy-340xx-kernel-dkms (340.108-3~deb10u1) ...
Removing old nvidia-legacy-340xx-340.108 DKMS files...

------------------------------
Deleting module version: 340.108
completely from the DKMS tree.
------------------------------
Done.
Loading new nvidia-legacy-340xx-340.108 DKMS files...
Building for 5.10.0-0.bpo.12-amd64
Building initial module for 5.10.0-0.bpo.12-amd64

Error! Bad return status for module build on kernel: 5.10.0-0.bpo.12-amd64 (x86_64)      <---------------------------------------                    

Consult /var/lib/dkms/nvidia-legacy-340xx/340.108/build/make.log for more information.
error processing package nvidia-legacy-340xx-kernel-dkms (--configure):
installed nvidia-legacy-340xx-kernel-dkms package post-installation script subprocess returned error exit status 10
dependency problems prevent configuration of nvidia-legacy-340xx-driver:

nvidia-legacy-340xx-driver depends on nvidia-legacy-340xx-kernel-dkms (= 340.108-3~deb10u1) | nvidia-legacy-340xx-kernel-340.108; however:
  Package nvidia-legacy-340xx-kernel-dkms is not configured yet.
  Package nvidia-legacy-340xx-kernel-340.108 is not installed.
  Package nvidia-legacy-340xx-kernel-dkms which provides nvidia-legacy-340xx-kernel-340.108 is not configured yet.

error processing package nvidia-legacy-340xx-driver (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-legacy-340xx-kernel-dkms
 nvidia-legacy-340xx-driver
Log ended: 2022-03-22  17:33:20

I did not encounter any problems when I later updated my main box from Linux devuan 5.10.0-0.bpo.11-amd64 to the now signed Linux devuan 5.10.0-0.bpo.12-amd64.

I then went looking to see what may be amiss:

uname -a gave the same printout and cat /etc/apt/sources.list shows the same in both installations:

~$ cat /etc/apt/sources.list
## package repositories

# Changed - 20210218 - upgrade to Beowulf

# beowulf stable
deb http://deb.devuan.org/merged/ beowulf main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-security main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-updates main contrib non-free 

# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/merged/ beowulf-backports main contrib non-free 

# virtual box repository x installation
deb https://download.virtualbox.org/virtualbox/debian/ buster contrib non-free 
~$

Then I looked for anomalies in the installed 340xx packages and found that the lists were not the same:

My main box has 17 packages:

libegl1-nvidia-legacy-340xx/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
libgl1-nvidia-legacy-340xx-glx/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
	
        libgles1-nvidia-legacy-340xx/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]    <---- missing
	libgles2-nvidia-legacy-340xx/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]    <---- missing
	libnvidia-legacy-340xx-cfg1/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]     <---- missing

libnvidia-legacy-340xx-eglcore/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
libnvidia-legacy-340xx-glcore/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
libnvidia-legacy-340xx-ml1/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
nvidia-legacy-340xx-alternative/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver-bin/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver-libs/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
nvidia-legacy-340xx-driver/oldstable,now 340.108-3~deb10u1 amd64 [installed]

	nvidia-legacy-340xx-kernel-dkms/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]    <---- bad version

nvidia-legacy-340xx-kernel-support/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]
nvidia-legacy-340xx-vdpau-driver/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]

	nvidia-settings-legacy-340xx/oldstable,now 340.108-1~deb10u1 amd64 [installed,automatic]    <---- missing

xserver-xorg-video-nvidia-legacy-340xx/oldstable,now 340.108-3~deb10u1 amd64 [installed,automatic]

But the parallel installation has only 13 packages and the wrong version for the package that is not able to complete its job: nvidia-legacy-340xx-kernel-dkms/oldstable-backports.

ie:
The working installation has nvidia-legacy-340xx-kernel-dkms /oldstable-backports,now 340.108-10~bpo10+1 amd64
The non-working installation has nvidia-legacy-340xx-kernel-dkms /oldstable-backports,now 340.108-3 ~deb10u1 amd64

340.108-10~bpo10+1 is the backported driver
340.108-3 ~deb10u1 does not seem to be.

Any idea as to why this is so?
Can't figure out what is wrong or how it got like this.

I tried manually installing the missing packaged but it seems the problems is with the wrong version of the dkms package.

Thanks in advance.

Best,

A.

Altoid · Installation

Hello:

rolfie wrote:

... why I don't use NVidea at all.

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

rolfie wrote:

... run a setup for your drivers that builds the modules.
... need the headers for the new kernel ...
... need them for building the VBox kernel modules.

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^/

rolfie wrote:

... a manual process.

Sure.
Like installing a backported kernel.

rolfie wrote:

Try that:

# apt -t beowulf-backports install linux-headers-amd64

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.

Altoid · Installation

Hello:

rolfie wrote:

Run the previously posted command, that will do the job.

Done.
But the system does not find the nvidia driver module so I cannot get a desktop.
Just command line.

X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[    63.984] Build Operating System: Linux 5.10.0-10-amd64 x86_64 Debian
[    63.985] Current Operating System: Linux devuan 5.10.0-0.bpo.11-amd64 #1 SMP Debian 5.10.92-1~bpo10+1 (2022-02-03) x86_64
--- snip ---
[    64.025] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
[    64.025] (EE) NVIDIA:     system's kernel log for additional error messages and
[    64.025] (EE) NVIDIA:     consult the NVIDIA README for details.

Makes sense that it cannot find it.
ie: whereas there are 340xx modules in /lib/modules/5.10.0-0.bpo.3-amd64/updates/dkms ...

~$ locate 340xx
--- snip ---
/lib/modules/5.10.0-0.bpo.3-amd64/updates/dkms/nvidia-legacy-340xx-uvm.ko
/lib/modules/5.10.0-0.bpo.3-amd64/updates/dkms/nvidia-legacy-340xx.ko
--- snip ---

... there is no /updates or /updates/dkms directory in /lib/modules/5.10.0-0.bpo.11-amd64

~$ ls /lib/modules/5.10.0-0.bpo.11-amd64
kernel         modules.alias.bin  modules.builtin.bin      modules.dep      modules.devname  modules.softdep  modules.symbols.bin
modules.alias  modules.builtin    modules.builtin.modinfo  modules.dep.bin  modules.order    modules.symbols
~$

I did find this one via apt list but it is the one I have installed:

~$ apt list | grep nvidia-legacy-340xx | grep dkms
--- snip ---
nvidia-legacy-340xx-kernel-dkms/oldstable-backports,now 340.108-10~bpo10+1 amd64 [installed]
--- snip ---
~$

System's working with the previous version so it's not a serious problem.
But I don't get what has happened.

Thanks in advance.

Best,

A.

The officially official Devuan Forum!

#951 Re: Other Issues » [SOLVED] rsync operation takes ages » 2022-04-22 07:45:35

#952 Re: Other Issues » [SOLVED] rsync operation takes ages » 2022-04-22 00:03:39

#953 Other Issues » [SOLVED] rsync operation takes ages » 2022-04-21 19:58:02

#954 Hardware & System Configuration » Log4j vulnerabilty - Yet again » 2022-04-21 10:57:08

#955 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-19 14:22:02

#956 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-19 10:15:38

#957 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-18 17:13:18

#958 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-18 16:36:38

#959 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-17 20:21:16

#960 Re: Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-17 16:56:08

#961 Hardware & System Configuration » [SOLVED] Script $PATH question » 2022-04-17 14:17:58

#962 Re: Hardware & System Configuration » [SOLVED] Bash history configuration » 2022-04-15 22:44:59

#963 Re: Off-topic » Why don't we just fork systemd and remove unneccessary bloat? » 2022-04-15 22:32:39

#964 Re: Hardware & System Configuration » [SOLVED] Bash history configuration » 2022-04-14 14:32:57

#965 Hardware & System Configuration » [SOLVED] Bash history configuration » 2022-04-14 14:07:55

#966 Re: Hardware & System Configuration » [SOLVED] WD MyBook Live with Devuan » 2022-04-14 13:58:08

#967 Re: Hardware & System Configuration » [SOLVED] WD MyBook Live with Devuan » 2022-04-13 07:01:32

#968 Hardware & System Configuration » [SOLVED] WD MyBook Live with Devuan » 2022-04-12 21:29:36

#969 Re: Hardware & System Configuration » [SOLVED] Zlib crash-an-app bug - does it affect us? » 2022-04-02 10:46:40

#970 Re: Hardware & System Configuration » [SOLVED] Zlib crash-an-app bug - does it affect us? » 2022-03-31 22:59:01

#971 Hardware & System Configuration » [SOLVED] Zlib crash-an-app bug - does it affect us? » 2022-03-31 21:12:35

#972 Re: Installation » [SOLVED] More Nvidia 340xx woes .... » 2022-03-22 23:05:56

#973 Installation » [SOLVED] More Nvidia 340xx woes .... » 2022-03-22 21:17:38

#974 Re: Installation » [SOLVED] Backported kernel update » 2022-03-20 18:39:15

#975 Re: Installation » [SOLVED] Backported kernel update » 2022-03-20 16:25:21

Board footer