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.

Indeed. Lucky the bar isn't too high, though.

No, xserver-xorg-legacy is in ASCII.

If @fsmithred meant for you bring it in from ASCII, you should make sure to "pin" ASCII as well, e.g. by a file /etc/apt/preferences.d/reluctant-ascii with the following content:

Package: *
Pin: release a=ascii
Pin-Priority: 10

Package: *
Pin: release a=testing
Pin-Priority: 10

Then you can (temporarily) add a lline to your sources.list:

deb http://pkgmaster.devuan.org/merged ascii main

And install xserver-xorg-legacy using the special command

# apt-get install -t ascii --no-install-recommends xserver-xorg-legacy

However if that threatens to bring in a lot and/or remove a lot, you should probably abort, rather.

The explanation is in how the bash expands commands, and how "-x" works.

Without quotes, a phrase like

[ -x $(type -p gedit)]

gets "expanded" into the following phrase when "gedit' is missing (aka "type" returns nothing):

[-x  ]

i.e., "-x" without argument, and that succeeds. Whereas with quotes around it, the expansion is

[ -x "" ]

i.e. "-x" with an empty string as argument, and that fails.

Perhaps your statement should have been like

if type -p $program > /dev/null ; then echo UGH ; else echo NÖF; fi

That would be using the return code of "type" as condition, with 0 meaning success and non-0 meaning fail.

Just a little bit of background:

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "auto eth0", it is a signal to the networking init script, that it should bring up eth0 on boot. That init script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "allow-hotplug eth0", it is a signal to udev, that it should bring up eth0 on boot (and also keep monitoring for later cable events). Its control script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

Of course, dhclient is only used as part of bringing up the interface if '/etc/network/interfaces' also has the line 'iface eth0 inet dhcp'.

If you are using a network manager, then you should avoid telling the networking init script or udev to bring up eth0, but rather let the network manager daemon deal with it. Whether that induces a boot delay or not depends on whether it has been improved in parity with the scripts.

btw, for the sake of clarity: I write 'improved' but I mean 'destroyed'.

That's such a beautifully mis-informed notion!

It reads as a praise to the layers and layers of code in between the person and the action, simply to make a drawing of it, so it can be operated without articulated thought.

Other than that, I have nothing