Thanks again. My machines are still using BIOS; the problem was certainly of my own creating, I suspect I did a grub-install to something other than /dev/sda. I might have persevered to get things sorted out from the limited commands available in grub rescue mode, but I was able to boot from SystemRescue (which I highly recommend) copied to a usb drive. Then all that was needed was to mount the proper file system and chroot.

That machine has devuan-baseconf 0.6.4+devuan3.1

I update it regularly with aptitude, but I stay with the current stable version.

The machine originally had ubuntu and I converted it using installation from a linux system. Two other machines which have been running devuan much longer, and were migrated from Debian jesse to ascii do not have the file.

I appreciate the information. Thanks. What you show is essentially as simple as lilo.conf

My experience was with a new machine which had ubuntu and gnome on it, installed by the vendor just to check that things worked. I appreciated that gesture, but I had a hard time getting grub to change things over so that I was running Devuan, and just the packages I wanted. I did start out with a relatively simple grub.cfg, but more and more entries got added to it, making the boot process quite mystifying.

Yes, and on the nvidea machines aptitude shows that it depends on kernel 4.19.0-12; for the intel machine aptitude shows that it depends on 4.19.0-11. There are also other differences as there were some 20 or so upgrade notifications for the first cases, including firefox, and none for the second.

It isn't of great importance as all machines are reasonably up-to-date and working properly, but I am curious about what aptitude is doing. I'll check if there are any differences in apt config files.

Thanks Golinux. Now I have the definition, and realize that I had used a backports kernel on a very new machine in order to handle ethernet hardware updates that were not recognized by the stable version. In principle, without hardware at the cutting edge, using packages from backports seems not to be necessary. My interest is to have a working system that doesn't require any special features.

As a final comment, which might be useful to others, I do routine updates (usually weekly) using aptitude, which only told me that some files had not been downloaded, without explanation or query. If I had run apt, I would have received more explanation, and the prompts about what to do. As I have been using beowulf for some time, I did not anticipate any difficulties when its status changed officially to "stable".

Here is what I get trying to use apt-get update

E: Repository 'http://deb.devuan.org/merged beowulf InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.devuan.org/merged beowulf-updates InRelease' changed its 'Suite' value from 'testing-updates' to 'stable-updates'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.devuan.org/merged beowulf-security InRelease' changed its 'Suite' value from 'testing-security' to 'stable-security'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

My /etc/apt/sources list refers to "beowulf" not "stable" or "testing" and has worked since the time of the beta release.

Golinux: I first had the nvidia problem in 2011 when the two computers in question were new, and I had a lot of trouble with stuff downloaded from the nvidia website. I was straightened out by one Len Sorenson (a compatriot at the University of Waterloo) who said "do NOT try to mix and match with the Debian installer. They do not get along." He set me on the right path and I have never touched anything that was not from the Debian sources.list (we can now thankfully update that to Devuan). It is now eight years on, and the problem is another nvidia change, but the Devuan packages have got it right; my only problem was how to handle the correct information I was given in the upgrade. If things are done properly, the Devuan way, the installation scripts will use dkms to handle installing the correct drivers. The dist-upgrade process warns of an incorrect kernel module and suggests rebooting as a cure.

As a matter of interest, the other problem I have had over the years was with setting up RAID1, and the solution to that problem involved ignoring what disk manufacturers say about RAID (false raid) and listening to Linux people and installing mdadm.

I am of course elderly, and a traditionalist, using command lines, and I prefer to avoid the unnecessary complexity of things like systemd, gnome (aka Windows) and even grub. Lilo works for me :-) One of these days when I have nothing better to do I'll try and figure out what the hell is the purpose of dbus.  In the meantime I have fun computing - isn't that what computers are for (says the physicist)?

Indeed! A typo that caused me some trouble while I was working with the problem. The problem is not to over-correct and write "vidio".

The problem is fixed. I composed a reply in some more detail, but the forum logged me out while I was working on it. More details later, but the essence is to install the alternate legacy driver and then get rid of the junk left by an abortive install of the wrong one.