I guess the plan would be to remove whatever is blocking the upgrade and whatever else you don't need. You can probably remove all or most of the dmo packages. And anything with "deb9" in the version is for stretch/ascii.

Add 'sleep 1' to /etc/init.d/eudev as shown here:
https://bugs.devuan.org/cgi/bugreport.cgi?bug=483#10

That should take care of 1 and 2. If 1 is still a problem after that, install acpi-fakekey.
I don't have any ideas for 3, but maybe that will get fixed, too.

If you want to test this before you do it, you can run (as root):
udevadm trigger --action=add
and see if that gives you sound. This won't persist beyond a reboot. Editing the init script will.

Maybe...

https://files.devuan.org/devuan_beowulf … _notes.txt

I'm seeing the same configs for crda and regdb in 4.19.0-9-amd64, 5.6.0-0.bpo.2 and 5.6.0-1 in ceres.

CONFIG_CFG80211_CRDA_SUPPORT=y
CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y
CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y

Yeah, that's it. 'devuan-packages' on git changed to 'devuan' on the new server.

git.devuan.org is now the same place as gitea.devuan.dev. The old git is at gitlab.devuan.org in case anyone wants to retrieve something before it goes away completely.

Thanks. I fixed the link in my earlier post.

Wow. I think (hope) that 120 is the correct number of dmo packages installed and not 633.

You can get rid of sources.list.d/devuan.list. I don't know about the other lists. You might need to disable them temporarily and/or you might need to change the suite they're using. (stretch to buster?)

It looks like your dmo packages are older versions than what beowulf has. If you remove dmo from sources, you should be able to upgrade most of them to stock beowulf versions.

If there's something in dmo you need that isn't in the devuan repo, you can add it later. I highly recommend pinning dmo to a lower priority or disabling it altogether after you install what you want. That will prevent pulling in other stuff from dmo that you don't need or want. Just avoid dmo if you can.

And yes, you can do all this in a chroot from another system. I like to use a live-cd (or usb) for that, but rescue mode in the installer isos will also work.

I have a couple of ideas, but nothing certain.

Maybe you could remove libgstreamer-plugins-bad1.0-0 and eliminate the conflict. Two packages should not provide the same file. Maybe the newer version doesn't have the conflicting file.

You really should remove deb-multimedia from your sources. Look in /etc/apt/sources.list, look for any files in /etc/apt/sources.list.d/ and also wherever synaptic stores its sources. That alone might fix the upgrade problem, or maybe you have a bunch of other packages from dmo that might cause problems.

dpkg -l |grep dmowill give you a list of files with dmo in the name or the version. The ones with dmo in the version are from deb-multimedia. See how many you have.

How old is this system? Was it upgraded from jessie? From a jessie beta?

This one boots uefi:
https://get.refracta.org/files/experime … l-live.iso

sha256sum:

8655c89c68a454458e3d9ea1c2e0b266315f72a2f81f6e043309a4d334d0a893  devuan_beowulf_3.0.0_amd64_uefi_minimal-live.iso

Edit: I didn't modify the grub menu, so it does not have the same choices as the normal minimal-live. The first choice is the same.

Sounds like you didn't make a grub.cfg.

The minimal-live is not set up to boot uefi. If you have another linux set up on the machine, you can boot the minimal-live on usb from grub command-line. It's also possible to install it as is and use the first linux to boot this one.

If you want this to be the main or only linux, you would need to install grub-efi-amd64 before you run refractainstaller.

If you don't have another linux to boot this, it might be possible to do it with two usb sticks - one with desktop-live to get to a grub command line and one with the minimal live. I didn't try that.

Press c at grub boot menu to get to command prompt and enter the following commands.

set root=(hd0)     # Your motherboard might call it hd1. Tab-complete will help you.
linux /live/vmlinuz boot=live username=devuan
initrd /live/initrd.img
boot

apt and apt-get are mostly the same. I ran it as user instead of root, so there's a little more message than usual.

Here's an example of what I was describing:

$ apt -s remove gvfs-daemons
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  gvfs-common gvfs-libs libavahi-glib1
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  gvfs gvfs-backends gvfs-daemons
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Remv gvfs-backends [1.38.1-5]
Remv gvfs [1.38.1-5]
Remv gvfs-daemons [1.38.1-5]

I don't know. You already heard from the only one who uses synaptic

I can tell you that apt and apt-get will not automatically remove packages that were automatically installed with the packages you are removing. In a terminal, you would be told to run 'apt autoremove' to remove them.

On the other hand, aptititude will remove them automatically. The only way I know to get them off the removal list is to install them manually, and then they get marked as 'manually installed.'

It's probably safe for you to do it in synaptic and then you can tell us whether it autoremoves what is no longer needed or makes you do it manually. It's especially safe since you already have that list of packages.

HevyDevy, thanks for checking that. If you have ps_mem.py, I'd like to see the output.