menuentry 'Devuan' {
   search --fs-uuid --set=root $actual_uuid
   linux /vmlinuz root=UUID=$actual_uuid ro quiet
   initrd /initrd.img
}

^ That boots the kernel & initramfs symlinks in the root partition that always point to the latest versions.

Run update-grub after saving the file to add the new menuentry. To remove the auto-generated menuentry for Devuan either uninstall the os-prober package or add this line to /etc/default/grub (in MX):

GRUB_OS_PROBER_SKIP_LIST=$actual_uuid

Then run update-grub again to update the menu.

It might be worth considering switching to Devuan for GRUB because their version supports Secure Boot whereas MX's does not. See my Secure Boot guide on the MX forums for more on this.

When you wrote, "If that is the case and you can't see these entries when you start the machine then the Devuan system is not in "control" of GRUB, ", I logged into my MX operating system to update-grub and the command also updated my Devuan system. I had wrongly thought that the update-grub command was no longer in use but the problem was that I was trying to use it in the terminal of the operating system that did not control boot.

My system is working great again.

I have been looking at and trying your suggestions:

# /usr/sbin/update-grub

/usr/sbin/update-grub: 3: exec: grub-mkconfig: not found

and then:

# dpkg-reconfigure grub-efi-amd64

bash: dpkg-reconfigure: command not found

I have now checked  /boot/grub/grub.cfg and it does not have the other entries except 4.19.0-16-amd64, however  4.19.0-10-amd64'  is the one always loaded.
The others, noted below, are not shown in grub.cfg although they have been installed:

linux-image-4.19.0-11-amd64
linux-image-4.19.0-12-amd64
linux-image-4.19.0-13-amd64
linux-image-4.19.0-14-amd64
linux-image-4.19.0-17-amd64
linux-image-4.19.0-9-amd64
linux-image-amd64

If I could boot into 4.19.0-16-amd64 it would be a start ...

Your advice is to use the command 'set' but first I  will have to research what the command actually is and how to use it.

# cat /boot/grub/grub.cfg

    menuentry 'Devuan GNU/Linux, with Linux 4.19.0-16-amd64 (recovery mode)' --class devuan --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-16-amd64-recovery-6fa66213-220c-4c2e-9656-04163dae7831' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt4'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  6fa66213-220c-4c2e-9656-04163dae7831
        else
          search --no-floppy --fs-uuid --set=root 6fa66213-220c-4c2e-9656-04163dae7831
        fi
        echo    'Loading Linux 4.19.0-16-amd64 ...'
        linux    /boot/vmlinuz-4.19.0-16-amd64 root=UUID=6fa66213-220c-4c2e-9656-04163dae7831 ro single
        echo    'Loading initial ramdisk ...'
        initrd    /boot/initrd.img-4.19.0-16-amd64
    }
    menuentry 'Devuan GNU/Linux, with Linux 4.19.0-10-amd64' --class devuan --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-10-amd64-advanced-6fa66213-220c-4c2e-9656-04163dae7831' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt4'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  6fa66213-220c-4c2e-9656-04163dae7831
        else
          search --no-floppy --fs-uuid --set=root 6fa66213-220c-4c2e-9656-04163dae7831
        fi
        echo    'Loading Linux 4.19.0-10-amd64 ...'
        linux    /boot/vmlinuz-4.19.0-10-amd64 root=UUID=6fa66213-220c-4c2e-9656-04163dae7831 ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd    /boot/initrd.img-4.19.0-10-amd64
    }
    menuentry 'Devuan GNU/Linux, with Linux 4.19.0-10-amd64 (recovery mode)' --class devuan --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-10-amd64-recovery-6fa66213-220c-4c2e-9656-04163dae7831' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt4'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  6fa66213-220c-4c2e-9656-04163dae7831
        else
          search --no-floppy --fs-uuid --set=root 6fa66213-220c-4c2e-9656-04163dae7831
        fi
        echo    'Loading Linux 4.19.0-10-amd64 ...'
        linux    /boot/vmlinuz-4.19.0-10-amd64 root=UUID=6fa66213-220c-4c2e-9656-04163dae7831 ro single
        echo    'Loading initial ramdisk ...'
        initrd    /boot/initrd.img-4.19.0-10-amd64

Reading your reply again, I see that you write:
"If that is the case and you can't see these entries when you start the machine then the Devuan system is not in "control" of GRUB. "

This throws light on the matter - although I use Devuan as my main system, I am triple booting and occasionally use MX 19.4 patito feo (19.4 ) and Void.
MX 19.4 patito feo (19.4 ) is also Debian based and my boot control may be there. However, I believe that the command update-grub no longer works in any and every Debian system but I will boot into  MX and give it a try.

Thanks for your detailed reply.

I cannot re-install grub because there is no command in my Devuan system to re-install grub:

# grub-install /dev/sda1 is "command not found."
# grub-mkconfig -o /boot/grub/grub.cfg is "command not found."

Both of those commands are under /usr/sbin/, was that in PATH when you tried them? Did you try the full path? If you used plain su to obtain a root prompt then PATH will not include /usr/sbin/.

But you should use dpkg-reconfigure instead because then your configuration choices will be stored in the debconf database.

I cannot re-install grub because there is no command in my Devuan system to re-install grub:

# grub-install /dev/sda1 is "command not found."
# grub-mkconfig -o /boot/grub/grub.cfg is "command not found."

So is this problem only on my system? I thought it might be a common Devuan problem ...
Cheers

on the command line 'upgrade-grub' is not recognised

That command is under /usr/sbin/ so you should check if that directory is included in your user's PATH when you attempt to call the command. Or just call the full path. See also https://files.devuan.org/devuan_beowulf … _notes.txt ("Changes in su").

EDIT: hold on, the command is actually /usr/sbin/update-grub; upgrade-grub doesn't exist (AFAIK).

But that command is run automatically when the kernel is upgraded so you shouldn't have to run it manually. Check /boot/grub/grub.cfg to confirm that the Devuan system has menu entries for all of your kernel versions. If that is the case and you can't see these entries when you start the machine then the Devuan system is not in "control" of GRUB. Use the set command from the GRUB command line to find where it is looking for the configuration file.

If this is a UEFI system then the efibootmgr command can show the boot entries and their respective priorities.

As dice notes reinstalling GRUB from Devuan is probably the quickest way to fix this. To do that for a UEFI system use

# dpkg-reconfigure grub-efi-amd64 # or grub-efi-ia32 for 32-bit

For a non-UEFI system use

# dpkg-reconfigure grub-pc

My Devuan system does not upgrade the kernel and on the command line 'upgrade-grub' is not recognised.
I presume that I cannot keep the same kernel forever without harming the system so can anyone advise on how to upgrade the Devuan kernel?

When I use 'apt-get update && apt-get dist-upgrade' a new kernel is installed but as I cannot update grub-efi on my uefi system, the old kernel linux-image-4.19.0-10-amd64 remains the one in use, although newer kernels are constantly being installed.

How do others here overcome the problem of update-grub not being recognised?

Today when I updated and upgraded, linux-image-4.19.0-17-amd64 was downloaded and installed but my system does not access it.
My system continues to use  Linux 4.19.0-10-amd64 which has been the kernel for a year or two.

At the moment, this inability to update is not causing any problems but it surely cannot go on forever. Any advice?

$ uname -sr
Linux 4.19.0-10-amd64

# dpkg -l | grep linux-image | awk '{print$2}'

linux-image-4.19.0-10-amd64
linux-image-4.19.0-11-amd64
linux-image-4.19.0-12-amd64
linux-image-4.19.0-13-amd64
linux-image-4.19.0-14-amd64
linux-image-4.19.0-16-amd64
linux-image-4.19.0-17-amd64
linux-image-4.19.0-9-amd64
linux-image-amd64

When the new kernel linux-image-4.19.0-17-amd64 was downloading today, the verbose command line informed that it was being linked to linux-image-amd64 although as Linux 4.19.0-10-amd64 remains the kernel in use, this linking does not seem helpful.

The obvious way is for me to remove all the kernels one by one except for the last two, but I am loathe to do this as I think that there may be a reason for Devuan sticking to the old kernel linux-image-4.19.0-10-amd64. Forgive my ignorance for not taking this path as I was a bit worried about breaking my system and losing my files if I cannot boot into Devuan. In the old days, linux commands on the command line just used to work, Oh bring back update-grub!

Over the last year, whilst linux-image-4.19.0-10-amd64 has been in use, I have removed several kernels prior to this using the purge command e.g. 'apt remove --purge linux-image-4.19.0-8-amd64' and could remove the current system kernel using that command. Would this be recommended?

Thanks in advance for any comments to explain this matter which is puzzling me.