Hmm. The problem obviously has little to do bash as such, but with the attempt to run a dynamic 64bit binary. You are sure the sda6 OS is 64 bit as well? For example, that there is a /lib64 directory?

It feels "rude" to ask, but one of the main causes for this problem is simply that one attempts to run with a 64 bit kernel inside a 32 bit OS file system. I missed on confirming before, that you have:

# ls -lL /mnt/lib64/ld-linux-x86-64.so.2

Let's get past this one ....

That looks good. I would then confirm the executable by running it

/mnt/bin/bash

When that looks fine, your problem have risen to the level of "intricate"

The next is to confirm its dynamically linked libraries, which starts by checking which they are in the current root, and then verify that they are all present within /mnt. Use ldd /mnt/bin/bash.

Yes, my note regarding consolekit might not be relevant; it does depend on which distro you are talking about. It came up for me when building and testing the beowulf netinstall iso, and I've also seen it popping up elsewhere. It's merely one possible reason for failing grub-install that is easy to check for and rule in/out.

Another alternative would be to run xvfb on the remote, which provides a headless X server, i.e., without displaying on any of the virtual consoles.

Perhaps it's due to the version disagreement of libuuid1:amd64 and libuuid1:i386 (in beowulf) (and in unstable).

The installable package is actually named printer-driver-escpr.

Great, Andy.

As you are experiencing, there is a bottleneck in the Devuan package building process, where the creative efforts end, and the software transitions into the more "formal" and process oriented treatment at the mouth of Devuan's automated build system. Sometimes tasks end up waiting there for some while simply because the person/people to move it along are few and with already full schedules.

Don't despair; it's not a deliberate inaction against your project and effort.

I'm only at an apprentice level as package maintainer myself, but I did pick up on a couple of small specks on this diamond. I'll go through them here, although it's a public forum, so on the one hand. many people will regard it as noise, and on the other it might attract further comments, views and perspectives in a range of usefullness:

• The build dependencies (in control) seem incomplete; e.g., is there a dependency on gettext at the build stage? The control file should include "all" dependencies of what is required for building the package as well as what is required for using the built software.

• The version code (in changelog) might need to separate the source versioning from the packaging versioning. There are some "rules" regarding this, and some "tradition", and in particular, it would be sensible to start at 1 (or 0 even) for the first appearance in Devuan/experimental. I'm fairly sure Dan'll want to discuss this.

• The targeted suite (in changelog) should be "experimental" rather than "stable".

• The project needs to have the "suites/experimental" branch with that which is going to be built into the package. The automated builder builds from that branch rather than the master branch.

As you know, it's very important to have both the build dependencies and the run-time dependencies set out relative to a "pristine", minimal installation.

To move your project further, it's good with some gentle prod's like this, although I think Dan is more often at IRC than at this forum, and well, "busy" is a good term for his time between sleeps

Eventually I worked something out.

The cause of this problem is simply that apt does not see different dependency chains for different architectures. Therefore, where a package (like libuuid1) has different version codes for amd64 and i386, then, in a multi-architecture setting, the attempt to install the one will "knock out" the other, with all its ramifications.

libuuid1:amd64 and libuuid1:i386 have different version codes in Devuan beowulf.

A smaller and safer example to experiment with would be xfsdump, where also xfsdump:amd64 and xfsdump:i386 have different version codes. It's easy to see that installing the one will knock out the other (without a total system havoc). (This package is similar in Debian buster, with two different version codes for the different architectures)

Fair enough. Here's the bug tracking link:
https://bugs.debian.org/cgi-bin/bugrepo … bug=933697

It seems like libuuid1 has an explicit "Replaces: e2fsprogs" declaration, which causes great havoc in the base set up. I haven't looked into the details, but that "Replaces" directive seems totally misplaced, since libuuid1 only provides a single library, whereas e2fsprogs provides more than a few useful and essential things, but not that library, nor (as far as I can see at a glance) anything conflicting with that library.

Thus, you don't ever want to install libuuid1. Well, I wouldn't.

Perhaps you can bypass this by using equivs, and (learning to) use it; it's a fairly simple way to tell your system that you have a package of a particular version installed without actually having it installed. In this case you would fool your system with an "equivs" installation of libuuid1:i386=2.33.1-0.1+devuan1, and that might be sufficient to get all else installed. I suppose, it might affect the audio (since this library is pulled in due to pulse0), so it might need additional hands-on later. But It is for instance, trivial to download that missing library /lib/i386-linux-gnu/libuuid.so.1.3.0 and "install" it manually.

Well, I think it boots the first stage, and enters a shell prompt instead of booting the second stage, but after "pivot_root", and having "/" overlayed by a tmpfs. Therefore /etc/inittab is editable, although whatever you do to it is not persistent.

In other words, the steps are as follows. First use the advice by @Head_on_a_Stick to get serial boot console, plus the init=/bin/sh parameter to get a shell after first stage boot:

console=ttyS0 init=/bin/sh

Then modify /etc/inittab (non-persistently) for an autologin on the serial line:

# echo "T0:23:respawn:/sbin/getty -a root ttyS0 vt100" >> /etc/inittab

And then, enter second stage init:

# exec /sbin/init

Obviously you'll need to do all that every time you boot, until you get persistence set up.

Well, crazy or not, I think today's easiest method is to copy /etc/init.d/skeleton into the target init script, which then is a configuration for the interpreter script /lib/init/init-d-script that implements the control actions around the nominated "service program".

The init-d-script can also itself be copied, modified (especially by adding an LSB header) and used as the init.d script. That's a good approach if for instance your KPI is a lines-per-day measure, or more seriously, the actual service control is significantly unusual and/or complex.

The middle ground is to rather expand the skeleton copy with overriding functions for the actions where the generic implementations don't suffice.

The "difficult" part is still to read and digest the section 22.2 on Init Actions in Linux Standard Base Core Specification, Generic Part, plus a few sections following that, and to map that to the specifics of the system at hand.