The officially official Devuan Forum!

You are not logged in.

#1 Other Issues » ntpsec not managing drift in Daedalus » 2024-06-06 04:05:55

Replies: 1

Since switching from Chimaera to Daedalus ~10 days ago, ntpsec shows it's contacting the servers, but the offset grows by a fraction of a second per day.  It appears it's contacting the servers but not managing the drift, not controlling the clock.

The only changes I made from the Daedalus factory-supplied /etc/ntpsec/ntp.conf file is to comment out the pool entries and add two server entries in order to have consistency from one boot to the next.  These are my server entries:

server nts
server nts

Doing "ntpq -p" shows this about 3 days after running "ntpdig -S" and restarting ntpsec::

     remote           refid      st t when poll reach   delay   offset   jitter
+time.cloudflare     3 8   33   64  377  10.5348 623.7458   0.5835
+oregon.time.sys  2 8   17   64  377  15.7338 627.3030   0.7425

Any suggestions to get ntpsec to put its hands on the steering wheel and drive?

#2 Re: Other Issues » 'more' in daedalus clearing the screen when it should not » 2024-01-13 22:19:50

Thanks for the suggestions.  Environment variable $MORE is not set, and there is no alias set.  If I do "date | /bin/more" (without the quotation marks), it clears the screen, prints one line of text at the top, and prints reverse-video "(END)" at the bottom.  "dpkg -S /bin/more" says it comes from util-linux.  "/bin/more --version" says, "more from util-linux 2.38.1".

Does 'more' have an antidote option to negate -p (and/or -c) in case that has (perhaps unintentionally) been made the default?  No syntax for negating an option shows up in the man page or via "--help".

#3 Other Issues » 'more' in daedalus clearing the screen when it should not » 2024-01-13 05:08:19

Replies: 6

In daedalus, with util-linux 2.38.1, /bin/more with no options initially clears the screen before starting to print text.  Based on over 40 years of using 'more', that is incorrect behavior--unless the -p or -c options had been supplied.  If the binary is called as 'page' or if the -p option is supplied, it's supposed to clear the screen.  In comparison, in chimaera, with util-linux 2.36.1, /bin/more with no options behaves correctly and does not initially clear the screen.  A web search did not reveal any discussion of how to work around this broken behavior.

Is there an (undocumented) option to nix the initial clearing of the screen?

As a side note, there's also a bug introduced probably over a decade ago now where 'more' quit showing one overlapping line of text.  If the binary is called as 'page', it's supposed to initially clear the screen and show zero overlap.  If the binary is called as 'more' with no options, it is supposed to _NOT_ initially clear the screen and is supposed to show one line of overlap as it scrolls.

#4 Other Issues » web pages flash/thrash with recent Firefox updates » 2023-09-17 04:30:02

Replies: 0

On Devuan 4 chimaera on amd64, using Firefox ESR, last night one of the pages to pay a Waste Management bill flashed/thrashed and did not load, and I was not able to pay the bill.  Today, there was an update to 102.15.1esr-1~deb11u1.  Just now, running the updated Firefox version, an Ebay page to show an order I had just placed flashed/thrashed several times and then sent me to a Captcha page.  After correctly selecting the specified pages, the browser went back to flashing/thrashing and then to Captcha--rinse, repeat.  Which combination of the following hypotheses is closer to correct:

- Firefox ESR has gone buggy and is no longer reliable
- Websites are (via malice or incompetence) punishing Firefox by making the sites not work with Firefox
- My social credit score is too low, so Firefox and/or the websites are punishing me
- (other)

#5 Re: Other Issues » Where to report a serious tcsh globbing bug? » 2023-01-04 03:53:11

Well, it looks like the system accepted the second report:


#6 Re: Other Issues » Where to report a serious tcsh globbing bug? » 2023-01-04 03:49:14

Tried to use the reportbug tool to send the bug report.  The tool refused to send it.  (I should submit bug reports against reportbug.)  In the end, I manually edited the saved draft report and emailed it manually.  After at least one automated rejection, I hope I can find a way to get the bug report filed.

#7 Re: Other Issues » Where to report a serious tcsh globbing bug? » 2022-12-30 04:09:20

Thanks for the replies/help.  The full package list for testing shows 6.21.00-1.1, the same as I'm using on Chimaera.  Oddly, the full package list for Chimaera doesn't show either csh or tcsh.

What would be the method to request a fixed version or a patch fix be considered to include in the next release?  Would that have to go through Debian's wish-list request system?

#8 Other Issues » Where to report a serious tcsh globbing bug? » 2022-09-18 22:40:03

Replies: 6

Where should a serious tcsh globbing bug be reported?  I'm running Devuan Chimaera with tcsh version 6.21.00-1.1.

In an empty directory, do these three commands:

    touch {a,b,c,d,2}{1,2,3}

    echo [a-d]*

    echo [a-d]?

Each of the echo commands prints this (modulo indentation):

    21 22 23 a1 a2 a3 b1 b2 b3 c1 c2 c3 d1 d2 d3

Each of the echo commands SHOULD print this (modulo indentation):

    a1 a2 a3 b1 b2 b3 c1 c2 c3 d1 d2 d3

The man page says this about a hyphen between square brackets:

    Within `[...]', a pair of characters separated by `-'  matches  any  character lexically between the two.

"2" is _NOT_ lexically between "a" and "d".  Therefore, the filenames that start with "2" should not be in the glob expansion.

This bug can result in files being deleted that should not have been deleted.

#9 Re: Other Issues » quit serving chimaera updates? » 2022-05-28 15:54:53

Thanks for the extremely quick reply!  That appears to work for me, too.

#10 Re: Other Issues » quit serving chimaera updates? » 2022-05-28 13:56:47

Oh, as far as I'm aware, I'm using IPv4 exclusively.  I disabled IPv6 during post-installation tuning.

#11 Other Issues » quit serving chimaera updates? » 2022-05-28 13:54:53

Replies: 3

It appears has quit serving chimaera updates.  What is the recommended replacement?

When I installed chimaera last December, this line in the original /etc/apt/sources.list referred to pkgmaster:

    deb chimaera-security main contrib non-free

I'm using apt-cacher-ng, so I adapted it to this:

    deb chimaera-security main contrib non-free

That had been working great through May 7.  On May 14, 21, and 28 (today), I get this when attempting "apt-get update":

Hit:1 chimaera InRelease
Err:2 chimaera-security InRelease
  Connection failed [IP: 3142]
Hit:3 chimaera-updates InRelease
Hit:4 chimaera-backports InRelease
Reading package lists... Done
W: Failed to fetch … /InRelease  Connection failed [IP: 3142]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Is the recommended replacement for  Or, is there a different recommended replacement?

#12 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-12-27 22:57:42

By way of follow-up, the Beowulf installation worked very well.  Even with adding the MX AHS packages and then migrating at least some of them to backports (when backports had the newer versions available), I did not see any serious problems from mixing distribution packages.  There was only one time in about 7 months that the machine crashed, apparently a GPU crash, and that was in August, 2021.

A few days ago, I installed Chimaera without any packages coming from MX or even backports.  So far, everything appears to be working very well (modulo migrating all my home-grown Python code to Python 3).  Graphics performance is excellent.  At, the 'tempting the mariner' page (with a warning, apparently about overheating systems) runs full 60fps in the small window and appears to do 20-30fps at full screen (1920x1200).

#13 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-05-23 02:33:13

Thank you for all the help.  After working through some odd issues (and a bug report about BIOS corrupting disk data), the machine just went into "production" use with a 5800 CPU, an ASUS Pro WS X570-ACE motherboard, a MSI Radeon RX 5500 XT GAMING X graphics card, Devuan Beowulf, the kernel from backports, AMD graphics and Realtek firmware from backports, some other packages from backports that apparently got pulled in as dependencies, and the Mesa and related libraries from MX AHS.  The MX AHS packages were mentioned in these linkded pages: and  So far, everything appears to be working well.

#14 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-03-10 04:06:47

It appears when I installed the backports 5.10 kernel that I used the meta package.  This is what 'dpkg -l' says for it:

ii  linux-image-amd64                       5.10.13-1~bpo10+1                   amd64        Linux for 64-bit PCs (meta-package)

Again, thank you both for the very helpful guidance.

#15 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-03-09 19:13:29

Thanks for the great info about the meta package.  During installation, I just followed the default path.  Now that I know about the meta package structure, I'll make sure to install the meta package from backports.

#17 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-03-09 01:44:15

That's a very good point.  Thank you for suggesting the 5.10 LTS branch from the beowulf-backports repository.  So far, today's current 5.10 kernel from beowulf-backports appears to be working well.  I partitioned the big HDDs and created the RAIDs.  The big RAID is doing its initial sync as I type (and for the next ~4+ hours).

I did a web search or two about how to add a backports repository.  One thing was not clear from the relevant web pages those searches found.  Does apt-get pick up updated kernel packages from backports automagically?  When I tried "apt-get -d -t beowulf-backports update", it wanted to update an enormous boatload of things, which I immediately rejected.  (Packages from the stable, non-backports repositories had already been fully updated.)

#18 Re: Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2021-03-07 01:11:17

Thank you both for those very helpful answers.  In case it might help someone else who might happen upon this thread:

After a long wait for the CPU (and some problems with a now-EOL SAS/SATA card) the machine is running.  (I had wanted a 5900X CPU, but it's still not in stock anywhere at a price even close to list.)  With a temporary (2200G) CPU, I upgraded the motherboard's BIOS to a version that supports the 5800X CPU.  That temporary CPU also allowed testing of some other issues.  I installed Beowulf with the temporary CPU.

For the kernel, I downloaded the 5.11.2 source from to my old machine, ran "make oldconfig" based on the config file from the stock Beowulf kernel (accepting the defult for all questions), cleared the value of CONFIG__SYSTEM_TRUSTED_KEYS, ran "make -j 6 bindeb-pkg", waited an hour for the build to finish, installed three DEBs (not the one with "dbg" in its name), installed the 5800X CPU, and booted it up.  So far, so good on the kernel.

Getting the GPU up to speed is still pending--one step at a time.

#19 Desktop and Multimedia » What AMD graphics card (< US$250) works on Beowulf? » 2020-12-20 03:38:26

Replies: 13

What AMD graphics card (up to US$250 price) will work with Beowulf?

I'm preparing to build a new system with an Asus Pro WS X570-ACE motherboard and either a 9 5900X or a 7 5800X CPU, with Devuan Beowulf as its first OS.  I plan to use open-source drivers, so I'm avoiding the 'PRO' cards.  After considerable searching, I have yet to find a cross-reference that says what AMD GPUs work with what version of kernel, xorg, etc.  Any pointers or suggestions?



#20 Other Issues » package for libvirtd init script » 2020-11-05 04:58:31

Replies: 2

On a Devuan Ascii system, what is the package that installs the /etc/init.d script for libvirtd?  Is it libvirt-daemon-system, or is it libvirt-daemon-system-sysv?



#21 Re: Other Issues » [SOLVED]Package updates in ascii? » 2019-03-31 04:11:02

I found the reason for my case of not getting updates.  My /etc/apt/sources.list had originally only listed the cdrom (well, actually DVD to be more precise) as sources.  That's likely a side effect of not configuring the network in the installer.  When I noticed a Raspberry Pi 3 running Devuan Ascii was getting updates that my main X86 system was not getting, investigation yielded that the Raspberry Pi's /etc/apt/sources.list had separate lines for "ascii", "ascii-updates", and "ascii-security" (along with a commented-out line for "ascii-backports").  After changing my /etc/apt/sources.list to mimic the one on the Raspberry Pi, I had ~164MB of updates to download, including Firefox 60.6.1esr.

#22 Re: Hardware & System Configuration » Raspberry Pi 3B+ network not working at boot with Ascii » 2019-02-16 22:50:32

Thanks for that pointer.  The case described there is for when "... eth0 is not connected to a network,"  In my case, my eth0 _is_ connected to a network, the same cable, switch/router port, and such where the X86 machine running Devuan Ascii boots with_out_ any DCPDISCOVER delay.  The only relevant hits found by a couple of searches were the 2660 and 1688 threads already discussed.  The 2660 thread has one solution of removing all mention of eth0 from /etc/network/interfaces, which would leave that NIC entirely unconfigured.  That thread also points to the 1668 thread.  In the 1668 thread, post #2 says to, "Replace 'allow-hotplug' with 'auto'.  That ('auto') is what I have.  Post #18 also says to remove all mention of eth0 from /etc/network/interfaces, but again that would leave that NIC entirely unconfigured, which is not the desired state when eth0 is connected to a network.

#23 Re: Hardware & System Configuration » Raspberry Pi 3B+ network not working at boot with Ascii » 2019-02-16 22:20:15

Thanks for the reply.  I read through both of those threads and the Debian bug report referenced in the latter thread.  Here's a little more detail on my situation:

I'm using only eth0 (well, and lo, of course), not wlan.

For essentially all practical purposes, I always have the network cable plugged in when I boot the Raspberry Pi.

I do not have Network Manager installed.

I boot to text console, not graphical login manager.

My directory /etc/network/interfaces.d is empty, and I have these four non-comment, non-empty lines in /etc/network/interfaces:

  auto lo
  iface lo inet loopback 
  auto eth0
  iface eth0 inet dhcp

Those four lines are identical to the corresponding lines in a 64-bit X86 machine that also runs Devuan Ascii.  The X86 machine does not have any delays.

Those four lines are also exactly how the datacenter network gurus where I work have always configured Debian-based systems for dynamic IP address on eth0.  Following the examples of said gurus, that's the way I have configured Debian-based systems I have worked with.  Except for cases whether the DHCP server (run by corporate IT) is slower than slow, I have not seen similar delays on those machines--only on the Raspberry Pi.

The X86 machine I mentioned and Raspberry Pi were tested with the same network cable, same port on the switch and router, etc.

When I boot the Raspberry Pi, the LEDs on the RJ45 jack behave curiously.  Initially, both are off.  Then, the yellow/amber LED on the right blinks on a couple of times and then goes back off--doing this once shortly before the DHCPDISCOVER line appears on the console and then again shortly after that line appears.  After the DHCPDISCOVER line appears on the console, and I think after the second round of yellow/amber blinks, the tree LED on the left comes on and stays on.

My hunch is there is something different about how the Raspberry Pi's NIC hardware, firmware, and/or drivers are initialized (relative to most X86 desktops and servers) that causes the initial dhclient process invoked by /etc/init.d/networking invoking "ifup -a" to fail/hang.

Is anyone acquainted well enough with the Raspberry Pi 3B+ NIC hardware/firmware/drivers to shed more light on why the Raspberry Pi shows the hang while the X86 machine does not?

I have a hypothesis that one possible workaround would be to remove the 'auto eth0' line from /etc/network/interfaces and add an "ifup eth0" or perhaps "ifup -a" command to /etc/rd.local.  Any second opinions on whether this would likely be reliable?

#24 Re: Other Issues » [SOLVED]Package updates in ascii? » 2019-02-16 21:45:41

Thank you, golinux, for your #22 reply.  Bug fixes and security updates are all I was looking for.  The Firefox ESR updates in question are security updates and bug fixes.  Interestingly, even though I had done nothing to my apt configuration, this morning there were over a hundred package upgrades available.  Perhaps, the mirrors might not have been syncing.

#25 Hardware & System Configuration » Raspberry Pi 3B+ network not working at boot with Ascii » 2019-02-14 04:19:19

Replies: 4

When booting a Raspberry Pi 3B+ running Devuan Ascii from image devuan_ascii_2.0.0_arm64_raspi3.img.xz plus package upgrades plus installing a bunch of non-default packages, the system tries to get an IP address from DHCP, but DHCP does not usually succeed.  About 3/4 of the time, the boot process pauses after printing one DHCPDISCOVER line, then a few/several dozen seconds later several more DHCPDISCOVER lines plus one "No DHCPOFFERS received" line print, and the boot process goes on without eth0 being up.  Later, after everything else has booted, a simple (as root) ifdown eth0 followed by ifup eth0 works within a second or two.  About 1/4 of all boots, DHCP gets an IP address in a few/several seconds, and the system boots with eth0 having a functional IP address.

Is this a known issue with DHCP and/or the Ethernet adapter driver?  Is there a known solution or workaround?  Is there a kernel module that should be listed to be loaded earlier in the boot process?


Board footer

Forum Software