With ssh access to remote servers you can obtain time statistics quite easily. E.g.

Download timing:

ssh $remote dd if=/dev/urandom bs=100M count=2 | time cat > /dev/null 

Upload timing:

dd if=/dev/urandom bs=100M count=2 | ssh $remote "time cat > /dev/null" 

That results in time measures for 200 Mib (aka megabytes) plain bulk data transfers.

Here are some options:

1. e.g. ttps://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation is a h-chopped link

2. e.g. https://wiki.hyperbola.info/doku.php?id … stallation is that unchopped link in plain text

3. e.g. https://wiki.hyperbola.info/doku.php?id … stallation is that link with simple "url" tag wrapping:

   [url]https://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation[/url]

4. e.g. (the link) is that link with "url" wrapping that split acutal link from highlight text:

   [url=https://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation](the link)[/url]

5. e.g. https://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation is that link likewise split and used as both link and as high-light text after an initial space:

    [url=https://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation] https://wiki.hyperbola.info/doku.php?id=en:manual:reference_installation[/url]

   (without initial space in the highlight, the forum renderer reduces it to option 3)

I suppose the ordinary poster would use option 2 as it requires little to no thought around the resulting link presentation.

Option 5 is of course "The Correct Way" technically but it's rather fiddly to achieve and somewhat prone to discrepancy between the actual link and its highlight.. And option 5 actually also allows for, say, tracking parameters on the actual link without showing them.

On the other hand the general safety advice would be: Don't follow any link without first copy-paste it into a plain text editor so you can review it and be satisfied about its parts. In that spirit, the h-chopping is ideal.

"including this one"? Do you say you get som google popup from this forum?
The forum software does not raise any such popup afaik.
Which kind of browser do you use?

@TCH: there is a modemmanager-gui package which presumably interacts with the ModemManager program of the modemmanager package, and there's also the modem-manager-gui-help package with, again presumably, documentation.

@aluma, "amprolla" is not involved at all in the delivery of packages. "amprolla" runs a program that reads the meta files from the debian and devuan-only repositories and "merges" them by creating the merged meta files which it then distributes to pkgmaster.devuan.org.

pkgmaster.devuan.org serves packages. It's repository (both the devuan-only and the merged parts) is also mirrored to several other servers, and the domain name "deb.devuan.org" is used to obtain all IP addresses for all those (inkluding pkgmaster.devuan.org).

Of course, DNS resolution is a separate subsystem that mostly doesn't involve devuan servers except for eventually and intemittently obtaining that resolution list for deb.devaun.org, which nameservers here and there digests into their cache for the in-between-times resolution service.

All in all, the most problems arise in the DNS resolution sub system; it almost never leads back to hickups with the cllient networking software. Usually due to the DNS subsystem being in transition with intermediate servers being updated. On occasion there are also transient inconcistencies in downloads due to the meta files have been updated on the actual server queried for those before the package pool of the actual server queried for those.

@shimarin, thanks.

The initial step of that installer is a dialog with a menu of 8 options plus 'help'. You want me to guess that you used option '1 Install' (that's ok) and I can probably likewise guess from your outline for the handful of dialogs following; in particular that in the task selection dialog you unticked everything except the bottom one for standard utilities.

Eventually reboot into the installed system, which presents the login prompt on vt1.

So what's next? Login as root or user? And perhaps you can include the output of

grep ^Commandline /var/log/apt/history.log | grep -n ''

up to the point where you first ran into the Xorg issue.

1. Install media. This would be the filename of the iso file that you used to install devuan from. Perhaps even the URL you used. If you have done "installed devuan" some other way than using an installation media, then you would need to descritbe that too. Only so that I can do the same.

2. When installing with the installer ISO it takes you through a series of dialogs. I was asking that you tell me what to do so I can get the same installation done.

3. The boot command line is found in /var/log/syslog as a line with the text "Kernel command line:" in. It would tell me the specific kernel arguments used when the system starts. Presumably you would have "the default" from your manner of installation, so this point is merely a way for me to be ensured that my test system from points 1 and 2 runs in the same way as yours.

So don't worry about point 3, but please make sure you are thorough about points 1 and 2.

Did you install xserver-xorg-video-* package(s)?

Who is running startx; root or non-root?

How did you install? Which desktop environment did you choose? How have you got so many packages from "unknown" (especially both the nouveau and nvidia modules)?

Ok. Remove the link /usr/lib/x86_64-linux-gnu/libc.so.6 and run (as root)

# ldconfig

which usually does good things to the libraries. You might also need to set a new link (as root)

# ln -sTf /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so.6

to sort out that dangling one.

I would think this all has to do with system differences between bullseye and daedalus (bookworm), and yet it's peculiar that only expr brings a problem.

Peculiar. Try running

$ LD_DEBUG=all expr

which should dump a haystack of goodies from the ELF loader. At a glance the problem appears to be with the ELF loader but I would then have expected it to concern all programs.

The haystack should include lines like

     17051:     checking for version `GLIBC_2.34' in file /lib/x86_64-linux-gnu/libc.so.6 ...

. Those indicate the particular ABI versions that the program requires. The hope is that there is some clue for the problem towards the end of it.

@Fierelier: yes, the Devuan repository is an "on-the-fly merge" of Debian packages that uses the packages directly from Debian repositories (except for the "forked" packages). I.e., Devuan only maintains and builds forked packages, and relies on Debian doing that for the rest.

In essence Devuan is simply a re-indexing of which packages are included and where to download them; forked packages from Devuan and all other packages from Debian. Thus, if Debian stops maintaining and building i386 packages, Devuan will follow.