Cool! We're almost there.

Here's my quick summary of the situation.
- You can boot from the mint grub if you specify root=uuid.
- The resume file contains a valid uuid for your swap partition, and boot isn't hanging with a message about not being able to find some uuid that doesn't exist.
- We don't know Who's on first base.

What I would do first is boot into devuan the way you did.

- Run 'fdisk -l' to see if devuan is on /dev/sdd1 today. If it is, run

grub-install /dev/sdd

and if it's not on sdd, then use whatever it's calling itself. (whole drive, not partition)

- Reboot and press whatever key gets you the boot device menu. Might be F8 or F12, might be ESC or something else. It should tell you on screen before you get to the grub menu. When you get there, choose the drive with devuan on it. That will temporarily make it the first drive, and you should get to devuan's grub menu. Boot the first option (Devuan) to make sure it really works.

This should all work perfectly, and it will show you that devuan can boot itself from the first hard disk.

Next step - I give you special powers to turn you into a super-gnuru.

Reboot, do not go to the boot device menu. Just go to the mint grub menu.
Press "c"
You will get a prompt that says:   grub>

Type the following, and then press TAB a couple of times.

set root=(hd0

You'll get a list of partitions. You should be able to figure out which disk grub is calling hd0.
Erase the 0 and replace it with 1. Press TAB a couple of times. Repeat with 2 and 3.

Once you figure out what mint's grub wants to call the disk with devuan on it, enter the following commands. We expect it to be (hd3,msdos1) but it probably won't be. I'll just use that for the example, but you should use what you find.

set root=(hd3,msdos1)
linux /vmlinuz ro root=/dev/sdd1   #change this to wherever it is according to the previous command.
initrd /initrd.img
boot

It should boot into devuan.

If you want a menu entry for devuan in the mint boot menu (one that works, I mean) you can create a custom one.

Boot mint.
Edit /etc/grub.d/40_custom and add

menuentry 'Devuan on sdd1' {
  set root=(hd3,msdos1)  # or wherever it is
  linux /vmlinuz ro root=/dev/sdd1  # or use the root=uuid here
  initrd /initrd.img
}

Save the file and run update-grub. It will be added to mint's boot menu.

That's all.

Welcome to grub hell. GRUB and the kernel don't always agree on what is the first disk.I need to reply a few posts back before I even think about your last post.

cat /conf/conf.d/resume would give the error you got. Are you sure you didn't use a leading slash?

If you're in the extracted directory, cat conf/conf.d/resume should output the same line that's in /etc/initramfs-tools/resume and that should be your swap partition's uuid. It gets used when you return from hibernation to disk.

OK, back to the immediate problem. Do you change the order of the disks when you boot the diffrerent systems? That could be done by going into the bios and changing the hard disk order or by calling up the boot device menu and selecting different disks before the grub menu comes up.

Are you booting from usb on any of these occasions? GRUB will probably see the usb as hd0 when you do, and all the internal disks get bumped up one number.

As I understand it, right now you are using mint's grub to boot devuan. If you want to get rid of mint, you'll need to use devuan's grub to boot. Are you going to change the order of the hard disks when you do?

I'm posting this now, before I tell you to do something wrong.

Edit: This should be first. When you get to
'[     9.003419] IPV6: ADDRCONF (NETDEV_CHANGE): eth0: link becomes ready"
Press ENTER to see if you get a command prompt, or press alt-F2 to see if you get a console login screen.

OK, that's the end of the edit. Original message is below.
-------

To see what's inside resume, you'll need to extract the initrd. You can do this as ordinary user.

mkdir extracted
zcat /boot/initrd.img-3.16.0-4-amd64 | cpio -i
cat conf/conf.d/resume

It might contain a reference to a wrong or non-existent partition.

If you change or remove that file to make a modified initrd, repack it (as user)

find . -print0 | cpio -0 -H newc -o | gzip -c > ../custom-initrd

You'll have a file named custom-initrd in the directory above extracted.

Then make a backup copy of the existing initrd and copy the new one into place. (su to root or use sudo)

cp /boot/initrd.img-3.16.0-4-amd64 /boot/initrd.img-3.16.0-4-amd64.bak
cp ../custom-initrd /boot/initrd.img-3.16.0-4-amd64

Cross fingers and reboot.

As suggested by update-initramfs, run grep -r MODULES /etc/initramfs-tools/ to make sure one of the files in that directory contains "MODULES=most". (probably initramfs.conf. That's where it is on my jessie.)

It's probably not anything to do with usb. Those error messages seem to come up a lot when the initrd fails right before it switches root.

Try lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep resume Check to see there is a file, conf/conf.d/resume. I've seen similar problems when that file contains a uuid that no longer exsits.

FWIW, I use the following commands for chroot (where ${chroot_dir} is wherever you mount the partition):

mount --bind /sys ${chroot_dir}/sys
mount --bind /proc ${chroot_dir}/proc
mount --bind /dev ${chroot_dir}/dev
mount --bind /dev/pts ${chroot_dir}/dev/pts

Now that IS weird. I don't know how you could install systemd (or even get a broken symlink to systemd) in devuan. Is there a /lib/systemd/systemd on /dev/sdd1? You're sure you were looking at the mounted sdd1? (have to ask that) Leaving swap unformatted shouldn't affect that. If you know how to boot from grub command line, that might be useful for diagnosing the problem, in case the problem is related to the disk order changing.

linux-image-amd64 is a metapackage that will always give you the newest kernel for the release. Until recently, that would have been linux-image-3.16.0-4-amd64. The kernel with the patch for meltdown is linux-image-3.16.0-5-amd64. You probably want that one, but don't expect it to fix the current problem.

FWIW, I installed kde5 in ascii last week, and it seemed to be working fine. I haven't played with it much.

The locale, tzdata and keyboard selection pieces that run in pre-install are just the debconf dialogs you get when you run 'dpkg-reconfigure locales' and so on. The one for keyboard is 'dpkg-reconfigure keyboard-configuration'. At least that's what I assume you're talking about. I thought I had turned that off, but maybe I remember turning it on. I usually skip all those pre-install scripts. (You can mess with them or add your own scripts in /usr/lib/refractainstaller/pre-install/)

Make sure you have consolekit, libpam-ck-connector and policykit-1 installed. Any of those missing has been a source of authentication problems for others. Maybe look at some of the discussions about mate on this forum. I don't know if anyone else has had this problem. (Usual problems are with shutdown/reboot and mounting removable media.)

This is a confused mess to begin with. It won't help if you keep installing grub from different distros. Have you been closely examining and comparing the grub.cfg files from each distro every time you run grub-install? How can you keep track of what you're doing?

Pick one disto to be in charge of grub. Then see which ones you can boot from that menu. If any don't work, try starting them from grub command line. It might be that one or more installations is not where you think it is or not where grub thinks it is. https://www.linux.com/learn/how-rescue- … ub-2-Linux

With this in /etc/apt/sources.list

deb http://pkgmaster.devuan.org/merged ascii main
deb http://pkgmaster.devuan.org/merged ascii-security main
deb http://pkgmaster.devuan.org/merged ascii-updates main

I think this was missing, so you couldn't see the version. I had the same problem when I tried to download it today. I got it after updating the package cache.

apt-get update

You might be able to install them with apt-get. If not, download the packages and install with dpkg --force-downgrade -i *.deb.

apt-cache policy libeudev1 libudev1
libeudev1:
  Installed: 3.2.2-9
  Candidate: 3.2.2-9
  Version table:
 *** 3.2.2-9 500
        500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
        100 /var/lib/dpkg/status
libudev1:
  Installed: 1:3.2.2+devuan2.10
  Candidate: 1:3.2.2+devuan2.10
  Version table:
 *** 1:3.2.2+devuan2.10 500
        500 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
        100 /var/lib/dpkg/status
     215-17+deb8u7 500
        500 http://pkgmaster.devuan.org/merged jessie/main amd64 Packages

user@snapshot-ascii:~$ apt-get download libeudev1 libudev1
Get:1 http://pkgmaster.devuan.org/merged ascii/main amd64 libeudev1 amd64 3.2.2-9 [92.3 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii/main amd64 libudev1 amd64 1:3.2.2+devuan2.10 [2,092 B]
Fetched 94.4 kB in 0s (110 kB/s)
user@snapshot-ascii:~$ ls lib*
libeudev1_3.2.2-9_amd64.deb  libudev1_1%3a3.2.2+devuan2.10_amd64.deb

apt-get install eudev=3.2.2-9 libeudev1=3.2.2-9

You may get a warning that you are downgrading. Proceed. You are "downgrading" to a newer version that has a smaller version number.

Aha! Did you notice that what was in the video looks completely different from what you saw during the installation? I recognize the warnings about using uuid or labels with encryption. That was the live installer. You can use uuids or labels with encrypted partition, but you have to do it manually after the install. The installer won't do it for you.

Are there any files in /etc/initramfs-tools/conf.d/ in the devuan installation? If so, what's there?

Is there more than one hard drive on the computer? If so, please say a little more about your setup.

If you lost your home directory after editing files, you should restore those files to their previous working state. Exactly what edits did you do?