I’m currently running Devuan on the Odroid XU4. I’m not done installing it…
It is running in a “chroot” space. That is, a “change root” environment. At Apple I (we) used this to “split the Cray in half” and it was a key bit of our security then. In our secure project environment we were on the actual core OS space. We saw the whole real machine. All the rest of the company (including folks in Engineering but who were not on our project) were logged into a “chroot environment” by default. They saw what looked like a Cray Computer and computed like one, but that could not see all the other users, disk, processes, whatever.
To get to our secure space, a “systems cracker” would need to get into our honey pot space, find and through the gateway router into the corporate space, find and enter the Cray Chroot space and then…. find a way to break a fundamental barrier inside the Cray OS… from a chroot space. We never had any crackers get past the gateway router, most were taken by the Honey Pot machine “apple.com” where we let “family and friends” of any employee have an account (and they knew it was exposed to the raw internet). It just LOOKED so juicy and so full of accounts, that any potential attacker had to explore it first. Then the various “Easter Eggs” got their attention. “Secret Projects” and various interesting “code names” and encrypted files and more. Basically every single attack was fooled by “all the users” doing things and all the juicy “attack surfaces” that were in reality land mines with all sorts of logging and reporting built in. We knew as soon as they knocked on the door what they were doing. Then we’d watch, collect data and observe tools / warz and eventually give them the boot. (Attacks / login attempts to accounts named “steve” “woz” and “jobs” were so frequent we made a “custom shell” that just said “go away kid, you bother me, come back when you have more skilz” and dropped their link.)
So the only attacks on “chroot” were from inside Engineering. We had a “Capture The Flag” prize for anyone who was able to break security. (Yes, we encouraged our best and brightest to attack us… rarely did anyone succeed, but we knew just how secure we were and it only got better over time… Nothing like a little “wolf at the door” to keep your skilz up, so we made sure we had some of the best wolves in the world after us ;-) Chroot never failed us.
Chroot is a very useful tool.
So I’ve been fighting with Odroid install / boot process for a while now trying to get Devuan to install and boot. Devuan says they have it, and I’ve tried to make their image “go” but there is something wrong with it. They also supply a tarball of User Land. Along the way, I did an install of Funtoo (a newer spin on Gentoo). They do the install via using an Ubuntu base, a chroot for the install, and then a reboot into the new world. Well, it reminded me of the utility of chroot…
So right now, I’m running Armbian on the Odroid XU4, and I’ve got a uSD card in a carrier mounted as a file system. It has both the Funtoo and a Devuan partition on it. I’ve done a “chroot” into the Devuan partition, and in it, I’m doing all my usual build stuff. “apt-get update” and upgrade and install gimp and more.
The Funtoo install process also alerted me to the fact that Armbian has a different disk layout / boot procedure than Ubuntu. I’d been trying to boot “other OS types” via an Armbian starting point. Ubuntu uses a FAT partition for /boot and a more direct “edit this file” approach for the boot target. I used that to boot Funtoo as their directions showed.
So it ought to also work just as well for Devuan. We’ll know in a little while. I hope to have a dual boot Funtoo / Devuan uSD chip. That would be a nice way to live on Devuan while exploring Funtoo.
I’ve put the basic steps into a small bit of a script I’ve named “chrit” for “change root into it”. The initial version was a hard coded destination, but I’ve now made that a passed parameter:
root@odroidxu4:/# bcat chrit
DEST=${1-/SD/ext4}
mount -t proc none $DEST/proc
mount --rbind /sys $DEST/sys
mount --rbind /dev $DEST/dev
chroot $DEST /bin/bash
This basically makes the devices and other system “stuff” available to the chroot environment, then tosses you into it. IF I mount a uSD card at /SD/ext4 (since ext4 is now the common default fs type) it doesn’t need an argument. But, if it is on some other disk partition, I can do something like “chrit /disk/mountpoint” and it uses that OS in that disk space and launches me into a /bin/bash CLI environment. In theory you can use other environments, and I might give it a go to try lxde some day… but for right now the Command Line is what I need and want for doing the Devuan config / install work.
Well, it looks like my installation of various programs is done, so I need to edit the /boot/boot.ini file on this chip to point at the Devuan instead of the Funtoo and see if I’ve got a full on Devuan build done and running on the Odroid XU4. Back in a bit, one way or the other ;-)
OK, after the reboot….
The “good news” is that I did get Devuan to boot. It nicely completes the whole process and presents me with the login panel.
The Bad News:
First, I had to edit /etc/fstab and turn the “0 1” into “0 0” so it would not try to fsck a FAT file system, which fails. That is likely why the regular install also fails. This whole notion of hiding the steps of the booting process is just stupid. Let me SEE what is happening and I have a hope of fixing it. Hide it all so it “looks slick” and when (and it IS a WHEN) it fails, I’m screwed. So I fixed that. Now it boots.
And presents me with that nice “username / password” login screen… and cant’t see my keyboard or mouse.
Just an OMG level of stupid in the Q/A department. Did nobody at Devuan bother to even TRY to boot this thing and log into it?
Look, I “get it”. I ran the Q.A. department at a small compiler company. Q.A. is not exactly the center of focus at any company. Nobody likes it when you piss in their soup and say ‘Not ready for Prime Time, try again”. But really? Not even a basic boot and no keyboard / mouse usb support? That’s just OMG level of stupid. Put it on the board, boot it and log in is THE first step of QA. Not “package and ship and hope”.
“Hope is NOT a strategy. -E.M.Smith”
So I guess it is up to me to figure out where they screwed the pooch and fix it. Until then I can, at least, run it in a chroot environment with Armbian providing the keyboard and mouse support….
FWIW, their cast of characters includes developers and “caretakers” and more, but nobody is titled QA Manager…
It is NOT the case that just because Microsoft thinks “the customer can do the QA” that is a good idea.
If Devuan wants a Grey Beard Q.A. Manager, I’m available, for free even… Just post a comment here.
Musings from the Chiefio 
I’ve put the Devuan assemble it yourself task on hold for a while. I tried adding in all the DTB Device tree bits I could find and some other bits. Still no KB & Mouse. It did boot and complain once as I’d screwed up the /etc/fstab entry, so it tossed me into CLI mode. That DID have kb and mouse. Go figure. So at this point “try it quick” options are running out. As I’d need to put some real head time into a “really build it the right way” from the ground up, that’s for later. Likely a lot later.
I do like the Funtoo method of grafting a userland onto a different kernel and using chroot to build / do maintenance. That saves a fair amount of things like rebooting time and I can still be using my browser in one space while doing system build stuff in the chroot space. After I work out a more “clean” set of steps, I’ll post a “how to” specifically aimed at things like doing all the customizing and apt-get stuff in a chroot for a new Devuan / similar install.
One of THE big hassles of building a new system / OS is that it ties up the monitor / computer for just that. But using a chroot space, I can fool around with the new build while everything else just stays normal and available. Also much less swapping of uSD cards and power cycles…
It is also kind of fun to have 2 different OSs running in different windows ;-)
This guy has X running so I figure I can do that too:
In which case the “worst case” would be to run some SystemD thing but just enough to get a chroot / none-systemD running LXDE or similar and treat it as a guest OS. Even on boards where there isn’t a formal Slackware or Devuan, I’m pretty sure I can make that “go”. Not ideal but better than nothing.
This also presents the opportunity to distribute compilation and / or other codes onto machines with different library sets and releases. Just set up the chroot with the matching environment and use it.
On the Rock64, I’ve mounted the same disk I use on the R.Pi M3 and it has a Gentoo partition on it. This ia a 2018 or so install that I did on the Raspberry Pi. Since it is the same A53 cpu type, and even there it’s using the 32 bit v7 instruction set instead of the v8, all the binaries are compatible. Now their might be differences in the DTB (device drivers) and kernel stuff, but all the userland is compatible.
So I’ve “chrooted into it and I’ve done an “emerge –sync” and I’m in the process of running the update. This lets me do the build / compile bits with the 2 GB memory on this board instead of the 1 GB Pi, and with a USB 3.0 disk speed ;-)
After it’s done I’ll find out if it only works on the Pi or if it can boot here, too. (That whole device tree kernel build issue).
I’m trying a stepwise update. Just going one bit at a time. So far it has accepted the key upgrade and upgraded portage, so not having the issues I had elsewhere.
It’s also nice that I can run this browser window while the build world is running in the chroot window ;-)