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.

Note: I just learned that the "pinning" of ascii seems to require a "pinning" of testing as well, so I've updated my post above (#6) for that. It doesn't really make a difference tor the topic here; it's just if someone tries that tidbit on some other quest.

So, the problem relates to the nouveau module, rather. The 3.6 kernel appears to have these modules compiled into the kernel, so comparisons of kernels don't say much.

I then see some 3 lines of inquiry, including that of declaring mode lines (and backgrounding @Geoff's point). The other two are to look into the solutions around "optimus/bumblebee", and/or using an nvidia module instead of nouveau.

There may be more of course, and I don't know which approach is most likely to succeed (if any).

Declaring mode lines might be the "least intrusive", but perhaps also the least likely to succeed. The steps for this would be:

• Use cvt 1024 768 to get a mode line to use

• Use X -configure to generate a xorg.conf file, where you

  • remove everything except the Monitor section,

  • add the mode line twice, with the first renamed to be "0x0",

  • before installing it as /etc/X11/xorg.conf

That should be it, I think. Run startx and capture the log, unless it works of course. The renamed mode line is as an attempt to pick up on the defaulted one as per the log; though that one is likely to, if it makes anything happier, still result in rendering a 0x0 screen, which isn't too useful. You also have a couple of test variations where you exclude the one or the other of the mode lines.

Ah, you need to undo my useless suggestions about i915.

Ah, there should be a newline; though I'm not sure that makes a difference by itself. Perhaps you should add the following line as well (with newline):

install i915 /bin/false

and probably rename the file to /etc/modprobe.d/blacklist.conf
The install line supposedly fools the kernel to run the /bin/false program as way of trying to install the module, with the desired effect of not installing it. Apparently, with "just" a blacklist line, the module might be loaded anyhow due to a dependency from another module, whereas the added install line should counteract that load path as well.

... and add it into the initramfs of course.