Well, since process ids may have anything between one and five digits, you could as well let the interpreter do the tokenization, making it be like the following:

wmctrl -l -p | while read a b c d ; do echo $c ; done

You may want to peep at "[SOLVED] slim does not set a default session".
A bit old, but possibly relevant still.

Presumably it's because the WM_CLASS property is different between the two cases, and that the resources for urxvt refers to the differing class tag.

Use xprop | grep WM_CLASS to check.

There might be some thinklight brightness control somewhere under  /sys/bus/platform/drivers/thinkpad_acpi/ ?

Maybe the phone has two partitions? E.g. internal and external sd cards?

Great. I think. The command prompt may well be post-pivot, which would mean that you actually have booted Devuan, but that there is an issue with the graphics. A few things to inspect:

# blkid

# dmesg | tail

# tail /var/log/syslog

# ls -l /dev/sd*

Though, I'd say fsmithred has more experience about getting it back into shape from this state, so maybe you should now ignore me

Ok. I don't know why the initrd building worries about the device node, since it should just take what is given at boot time, and not at building time. There might be a number of gremlins under that stone, but maybe you get away with just rolling back and mounting devtmpfs onto /dev before another update-initramfs.

# mount -t devtmpfs none /dev

By idle guesswork, I think the initrd building really would want to find a file /var/lib/initramfs-tools/3.16.0-4-amd64 with content:

fd47cef5-ce5e-4090-8bfa-aef277a49e3e /boot/initrd.img-3.16.0-4-amd64

as its "database entry" of where that initrd is supposed to reside. But it burns my synapses trying to fathom an underlying logic for it.

Anyhow, maybe it'll be happy enough with having devtmpfs mounted.

Sorry again; I'm too sloppy. It should have been

# mount -t devpts  none /dev/pts

('ve editied the original as well)

Yes, I also expected it to go into a shell prompt; a busybox shell prompt. And it should have a number of useful commands available, plus some more in /bin and /sbin.

But maybe you should park that line of study for the moment, and first address those module complaints. They all concern USB, and perhaps it's important to get them into your initrd.

1. Thus, first restore the grub line to be

linux root=/dev/sdd1

2. Then, boot up your Mint, and mount the partition like before, chroot into it, and set up the kernel's virtual file systems:

# mount /dev/sdd1 /mnt/devuan
# chroot /mnt/devuan
# mount -t proc none /proc
# mount -t sysfs none /sys
# mount -t devpts none /dev/pts

In passing, note that the chroot command starts a /bin/bash from within the Devuan file system, and all commands are from within the Devuan file system. The running kernel however is the Mint kernel.

3. Now, edit the file /etc/initramfs-tools/modules, to add the modules you saw mentioned:

ehci-pci
ehci-orion
uhci-hcd

(note I assume it said ehci-orion with a final n, and not ehci-orio. In any case, the actual module has that final n)

4. Then rebuild the initrd with the following

# update-initramfs -u -k all

That command will look for all kernels in /boot of the chroot-ed file system (Devuan), and prepare an initrd for each, into /boot. It does not change the links /vmlinuz and /initrd.img, which thus remain pointing out the kernel to use and its associated, and now updated, initrd.

5. Then, have a peek at /etc/fstab in the chroot-ed file system, and make sure it's fully agreeable.

6. Exit the chroot, and reboot into Devuan ... without problems ... (as if:))

If it doesn't work, you might want to try the UUID variation for the grub line, i.e.

linux root=UUID=fd47cef5-ce5e-4090-8bfa-aef277a49e3e

Doing so would avoid any possible problems with USB device enumeration during boot. As fsmithred noted, it's possible that the Devuan boot-up sees a different device enumeration than the Mint boot-up (for reasons too complicated to worry about), and, say, that the Devuan partition gets enumrated as the first disk (/dev/sda1) or something. By referring to the UUID, it ignores the enumeration, and it picks the matching partition with that UUID.
It's again important that /etc/fstab of the Devuan partition agrees.

You seem to have put yourself in a muddle as you first mount /dev/sdd1 onto /mnt/devuan, and then cd into /sbin rather than /mnt/devuan/sbin.

So the rest shows that your root file system (presumably your Mint) has systemd.

Perhaps you should try # chroot /mnt/devuan instead, in order to investigate the /dev/sdd1 partition as if it was the root file system.

Maybe it has something to do with the -novtswitch argument to X:

...
[+1158.27s] DEBUG: Launching process 3692: /usr/bin/X ... -novtswitch
...

It seems far-fetched that an end user application would require debugfs, but you'll just need to mount it (see e.g. wikipedia)

Or, maybe an lsusb -t would give the same information.