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.

On a hasty reading it looks to me like the getty doesn't respawn, which suggests a shell termination problem.

You might want to test this theory by inspecting the process list before and after exiting. E.g.:

• login at tty1

• type ps axww| grep getty

• shift to tty2, login and then type exit

• shift back to tty1 and type ps axww | grep getty again (or use up-arrow)

If the second getty list does include tty2, then it's not a respawn problem.

Otherwise the problem is likely that the shell doesn't complete it's termination, perhaps due waiting for an unavailable resource.

initrd ?

Random search result: https://blog.markshead.com/79/setting-up-svn-over-ssh/

I don't use svn myself, but apparently it's just a case of setting up a shared directory over ssh. The client side (on linux) would refer to that using the format

svn co svn+ssh://<path to repo>

(Windows clients would be the same but different)

The random search result doesn't suggest the server side need additional, particular software.

Limiting the repository size may need some more;. e.g., to mount a partition as the directory. Or perhaps even bind mount a loop-back mounted file with a file system in.

hth

Threads are dynamically named by the Subject line of their first post.
Thus: edit the first post, and change the Subject line.

Let me derail a moment with this note (that might be obvious to many): that I'm learning new about the repo's and that my "world model" above is a bit too simplistic for reality. Probably a good thing, though that model kind of works for me for the moment.

Then, about HTTPS.

The current mirroring technique uses DNS to make deb.devuan.org resolve to some mirror's IP for each "request". Then the problem with using HTTPS is that it requires the sharing of credentials, where recipient organisations need to take on the responsibility of taking due care of them. This is part of the 'trust aspect' of using HTTPS more than the transport encryption aspect, and to have a commercial organisation (which is applicable for many mirrors) take on a responsibility is asking for more than the mere mirroring functionality. Many mirrors do serve via HTTPS, but they do so with their own domain names rather than named as deb.devuan.org.

The alternative solutions would involve handling all requests, either proxying them or bouncing temporary redirects, by a layer of deb.devuan.org hosts physically distributed over the world. This would attract a significant ongoing effort and cost.

Thus, if HTTPS is my thing, then I need to set up my sources.list to use the accredited name(s) of my chosen server(s) directly.

Yes, you should use deb.devuan.org, and the URLs should also end with /merged. Please check and try again.

Well, totally right in that about insults, though. Not the Google bit, obviously, but the rest