I apologize for my clumsiness. I didn't make it clear what my overall requirements are. I've fulfilled them, and will describe the solution.

The requirements are these:

Step alpha:  After doing a stock devuan installation on a system which has Internet access, install a shopping list of packages (and those on which they depend, of course). For me, not all of these are available on the desktop.iso, things like clisp, valgrind, and dos2unix. When the smoke clears, I want directory /usr/src to contain linux-headers-$(uname -r); I do not want to see the linux headers for any other version of the system. Just deleting the wrong ones won't work, because their presence is evidence that I've installed something that depends on them, and that needs to be avoided at the outset.

Step beta:  Repeat all of this on a system which does not have Internet access.

The solution may have unnecessary steps or other details, but I've tested it, and it works.

During the stock installation in both steps, in the "Choose software to install" menu, I deselected the Devuan desktop environment and added Console productivity.

A handy command is dpkg --list. Each time I used it, I removed all the output except the bare names of the packages which have been installed. To keep output clean, whenever I wanted to install a package, I checked to see whether it was already installed. The other time I used it was near the end of step alpha, to gather all the packages together in preparation for step beta.

The major discovery in the first step is that one shouldn't put entries for both the DVD and deb.devuan.org in file /etc/apt/sources.list at the same time. If you do, it will always go for the later linux-headers, even if it doesn't match what you're running.  It doesn't matter which entry comes first in the file; you'll always get the problematic result.

Ok, here's step alpha. Consider doing everything under the script command, so you can diagnose problems more easily.

1. I found that /etc/apt/sources.list already referred to the DVD.  I added [trusted=yes] (surrounded by spaces) just after the initial "deb" on the "deb" line. I don't know whether it's necessary, but it works.

2. apt-get update

3. For each package in my shopping list, if it hasn't been installed already while installing prior packages, apt-get --yes install this-package-name; don't worry if you get an error; just keep going.

4. Change /etc/apt/sources.list so that the only entry is deb http://deb.devuan.org/merged beowulf contrib main non-free; of course, you'll want to change beowulf as necessary.

5. Make a list of items on the shopping list which have not yet been (successfully) installed.

6. dhclient; just for kicks and grins, go out of your way to delay doing this until just now.

7. apt-get update

8. For each item on this later list, check whether it's already been installed (perhaps on this step 8); if not, apt-get --yes install this-package-name; blow up if an error happens. After each package has been installed, ls -l /usr/src. If installing this package has resulted in expanding the content of that directory to include a later linux-headers, you have a problem which this whole algorithm won't solve. Sorry.

9. Create an empty directory to contain all the packages you've installed. Copy into it all of /var/cache/apt/archives/*.deb. Those are the packages you installed from the Internet, not from the DVD.

10. From the list of all installed packages, fish out from the DVD the .deb files for all packages not already copied from /var/cache/apt/archives/, and copy them into the directory of packages you're building. I did a one-time check before I set out on this adventure: no package is represented on the DVD with more than one version, and multiple copies of a given package had the same md5sum.

11. tar together the .deb files you've gathered in your new directory.

12. (cd /usr/src; ln -s linux-headers-$(uname -r) linux)

And here's step beta. Once again, consider doing everything under the script command.

1. After a stock installation as described above, get the tarball of the packages you installed in step alpha.

2. dpkg --recursive --install your-package-directory

3. Using the handy-dandy list of already installed packages, list the names of any packages in your directory which were not successfully installed.  If the list is non-empty, go back to step 2. Rinse and repeat until everything has been installed. If you get to the point where another iteration won't solve even one problem, then you're in a situation beyond the scope of this post. Sorry.

In my case, the following happened:

Selecting previously unselected package gawk.
dpkg: regarding .../gawk_4.2.1+dfsg-1_amd64.deb containing gawk, pre-dependency problem:
 gawk pre-depends on libmpfr6 (>= 3.1.3)
  libmpfr6 is not installed.

dpkg: error processing archive packages.d/gawk_4.2.1+dfsg-1_amd64.deb (--install):
 pre-dependency problem - not installing gawk

... and I didn't have to scan all the script output to find this problem, because at the end of the dpkg --recursive command was this:

Errors were encountered while processing:
 packages.d/gawk_4.2.1+dfsg-1_amd64.deb

So I repeated the dpkg --recursive command. I could probably have just installed gawk, but rerunning everything is a robust recovery that will also work in the future if I ever have more complex dependency problems.

Anyway, after success:

4. (cd /usr/src; ln -s linux-headers-$(uname -r) linux)

... and Bob's your uncle.

My environment involves machines which do not have internet access, and it would be really, really, really handy to be able to use this DVD, and this version of Linux, and its matching source. Is there any way at all that I can get the matching source?

It seems that module-assistant does the trick, but at least for me there remains a problem.

My ultimate goal is to be able to work with module source code on machines which are not connected to the Internet. Unfortunately, module-assistant requires an Internet connection. The question arises: is there a workaround?  Can I do the same thing without an Internet connection, and therefore without module-assistant?

In theory, module-assistant does only two things: install some packages; and place the appropriate symbolic link at /usr/src/linux.  The trick is to discover whether this is ALL that module-assistant does.  If so, we can get along without it, and install without access to the Internet.

So I did some before-and-after comparisons for two sequences.  The first sequence, with access to the Internet:

-- do a stock install of devuan from DVD
-- run dhclient
-- add deb http://deb.devuan.org/merged beowulf contrib main nonfree to /etc/apt/sources.list
-- in that same file, comment out the cdrom line
-- run apt-get update
-- run apt install module-assistant
-- run m-a prepare

Preparation for the second sequence:

-- download all packages installed in the previous ma-prepare

Now the second sequence, on a host without access to the Internet:

-- do a stock install of devuan from DVD
-- do NOT run dhclient
-- download from the mothership host a directory containing packages downloaded from the Internet
-- run dpkg --recursive --install that-directory
-- run

ln -s $(ls /usr/src | grep linux-headers | grep -v common) /usr/src/linux

Before-and-after comparisons were made by gathering the following data before, and then after, each sequence:

-- the names of all installed packages, found by running dpkg-query --list
-- the names of all files, basically a find / | sort
-- for each regular file less than 64k in length, the length and checksum

So, did the second sequence do as well as the first?  Yes, and actually a little better.  The only significant differences were that the second sequence created links in /etc/alternatives that the first did not (and, of course, package module-assistant itself wasn't installed).

It seems that module-assistant, when installing a package, did pretty much everything, but the output to the console looks different, as though module-assistant installed packages slightly different from how dpkg --install would. Indeed, that's so: links in /etc/alternatives are missing from the m-a prepare results.

Most importantly, m-a prepare didn't do anything other than what was advertised. So the second sequence is adequate, and solves the original "no Internet" problem.

Except:

One host of interest is older, a 32-bit machine.  I haven't tested this solution for 32 bits, but of course I will.  If I have any difficulty, I'll report it in this thread (unless the thread is closed at that point, or something).

Well, now, this is really embarrassing.

In the light of day, when it comes to using the hardware native screen font, there are actually two advantages for using Head's solution.  One, as he says: it's less hacky.  The other: um, their solution works and mine doesn't.  I don't know why my testing was so abysmal.

But wait!  There's another solution!  It's hacky, but it works:

mv /etc/console-setup /etc/xxconsole-setup

The advantage is that if you ever want to reverse this, you don't have to have access to a DVD, or a USB stick, or the Internet, to do so, because you won't have to reinstall console-setup.  Just reverse the rename.

Aaaand, for esthetic consistency goodness, you can go full hacky:

mv /boot/grub/fonts /boot/grub/xxfonts

Ok, I looked at the digium page and saw that it advised five kernel command line arguments. It said that on a given system, one of them should disable the frame buffer, and that it wouldn't hurt to throw all five of them in there. I found that either of two of them worked for me. I settled on "nomodeset".

"Settling on nomodeset" means that I could boot, press "e" to edit the commands, find the "linux" line, and add nomodeset as one of the parameters. That worked. But my application runs while I'm away, and on power failure followed by power restore, I want the application to start up without human invervention.  So pressing "e" is not an option there.  The page does say how to make the nomodeset parameter permanent and automatic.

The page first advises editing /boot/grub/menu.lst, but that file doesn't exist. No problem: the page goes on to advise that on "modern Debian systems" one should instead edit /etc/grub.d/10_linux. Look for the "linux" command, and add the parameter (in this case, "nomodeset") to that line.  It turns out there are two such lines; I modified both of them.  It had no effect whatsoever; that is, when I rebooted, (a) pressing "e" presented me with a "linux" line that did not include "nomodeset", and (b) after the system finished booting, /dev/fb0 was present. Further, I found that crippling /etc/grub.d/10_linux (with s/linux/linus/, s/LINUX/LINUS/, s/Linux/Linus, just for fun), or removing that file entirely, didn't change how devuan booted. That file seems to have zero effect on boot. Hmm.

It turns out that the answer (at least for devuan 3.0) is:

Edit /etc/default/grub. Find this line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

Add to that line one or all of these five arguments:

vga=normal
nofb
nomodeset
video=vesafb:off
i915.modeset=0

I changed that line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

Then close the edit and run update-grub.

When you reboot, you'll notice two things. First, if you press "e" while in grub, you'll see that the nomodeset is there on the linux line. Second, when rebooting has finished, you'll notice that /dev/fb0 is absent.

That worked, but only after (duh) I ran dhclient.  And now I wonder whether running dhclient without apt-get update was all I needed to do in the first place (except for that one package that inexplicably appeared anyway). Further experimentation on a freshly installed devuan system will answer that, but meanwhile the two of you have helped muchly. Thanks.