XU4 Devuan 2.0 Progress

Well, having spent a few days fussing around with Gentoo USE flags, and still lost in the woods, I decided to try Devuan 2.0 grafted onto the Armbian kernel.

The good news is that once again, I got it to work. The better news is that I figured out why networking was hosed. That same old crap they stuck in along with SystemD where “eth0” (that has been THE standard default first up network card FOREVER) was changed to some long incomprehensible crap of some char in front of your MAC ID for each interface. Yes, that makes sense for major shops with a staff of 20 professional systems programmers running a farm of Virtual Machines on multi-homed $200,000 servers. It makes NO sense for the Home Gamer on a system with ONE, count it, ONE ethernet interface.

So, it turns out, the /etc/network/interfaces file is configured for eth0 (as it has been FOREVER) but they didn’t pass the “ignore it” flag in the boot string (or maybe they do, but it wasn’t in the 1.0 build so my swapping in that kernel had it borked. Whatever, if the foolishness did not exist it would not be biting me.)

I even got (once networking was up) LXDE installed. So now I’ve got a nice, windowing and lots of apps installed, Devuan 2.0 running on the XU4. Not bad for something to do while clearing the mind about Gentoo USE Flags and autounmask files!

Now, the bad thing:

Firefox is either gone, or hiding under a name I’ve not kenned just yet, and, Chromium just flashes a blue panel and dies. Is Chromium busted? Or does it depend on something in the newer kernel (that I can’t get booted…) that isn’t in the Armbian kernel I’m using?

But that’s for another day. I’m happy to boot up Devuan 1.0 for a browser for now (what I’m using to type this). I’ll get into porting browsers next week ;-) As it stands, I’m just happy with the progress to date.

Some Hairy Details

Some folks may remember that I’d gotten Devuan 2.0 on the Odroid XU4 to boot about a year ago. I’ve made hybrid systems before too.But no keyboard and mouse. What’s different this time is I’ve learned to drag along the /lib/modules and /lib/firmware files. I did that on the Funtoo port and on other hybrid systems. Guess I did learn something this year. The other difference is that I remembered having fought with the “numbered interfaces” crap a couple of times and had enough Ah-Ha to realize that might be why networking didn’t work.

OK, what did I do?

Well, first off, instead of making a dozen card images, I just took a 32 GB card and partitioned it more. This left the boot block at the front and the first partition as pristine Odroid Boot Loader and my Armbian/Devuan 1.0 Jessie build. Just like for Funtoo and Gentoo on the same card. Some “leftover space” was accumulated into the end partition. It had been “misc” and just a scratch space. So a good bit of time in “gparted” moving partitions over, shrinking them a bit, and gathering up about 4 GB of space for Yet Another OS Image.

Then I took the tarball download of XU4_Devuan_2.0 and un-tarred it into that partition. Mounted as something like /SD/Devuan IIRC. I then copied the stuff in /lib/modules to /SD/Devuan/usr/lib/modules and /lib/firmware to /SD/Devuan/lib/firmware. At this point, the boot loader in the start of the uSD card will look at partition 1 boot.ini and do what it says AND it will use the kernel if finds there. Buy changing where that boot.ini thinks it will find the / (or root) disk partition, it will change what userland gets run on top of the kernel. This kind of stuff is needed because Odroid uses a signed boot loader and you can’t play with it… well, not easily anyway.

Here’s my /dev/mmcblk0p1/boot/boot.ini file when configured to boot the first partition and Armbian/Devuan/Jessie. The first setenv is the active one and the other three are commented out. To boot Devuan 2.0, I comment out the first setenv (put a # in front) and un-comment the fourth one:

root@odroidxu4:/boot# cat boot.ini

setenv rootdev "UUID=dc9477cd-d43d-4082-82af-1cfadc352727"
# Comment out the above and uncomment the below to use Funtoo or Gentoo
# or the 3rd one to test Devuan 2.0 on existing kernel (modules & firmware duped)
#setenv rootdev "LABEL=SD_Funtoo"
#setenv rootdev "LABEL=SD_Gentoo"
#setenv rootdev "UUID=cb2dc372-b711-4cf8-9d0d-3846a0edf01c"

# U-Boot Parameters
setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"

So that got me booted and running. But no network. Then the Ah Ha had me fix up /etc/networks/interfaces.

To find out what your ethernet is named you do an “ip a” command (or drink an IPA then do the ip a command ;-)

Here’s what it looks like on a normal system:

root@odroidxu4:/boot# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1e:06:31:aa:27 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever

On those that have been abused, the ethernet will not say “eth0” but some other crap. That’s what needs to be in your /etc/network/interfaces file for your network to work. UN_fortunatly, that is based on your MAC ID and since that is different on every board, it can’t be configured by your software provider (unlike the old eth0 …)

Here’s what my Devuan 2.0 file looks like to make it work:

root@odroidxu4:/SD/misc/etc/network# cat interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
# source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto enx001e0d21aa27
iface enx001e0d21aa27 inet dhcp

auto eth0
iface eth0 inet dhcp

I left the eth0 lines in so that “whenever” I figure out how to pass the “net.ifnames=0” parameter to this kernel at boot time, I’ll still have networking. I added the lines with “enx001e0d21aa27” in them as that’s the crap my eth0 is presently named…

With that, I got networking working and could proceed with “apt-get install xfce libreoffice gimp htop” etc etc.

So I’ve got a working Devuan 2.0, with networking, with window system, with appications, all on the XU4. Just need a browser that works and I’m “good to go”.

I’ve also got a system that boots into Armbian/Jessie/Devuan 1.0, Gentoo, or Devuan 2.0 (on Armbian kernel). A nice little feature set.

So with this one uSD chip, depending no how I boot it, I can have a working browser, have a Devuan 2.0 working environment to continue tuning and building out, or have a Gentoo that boots to the CLI and where I need to develop more USE flag and masking skill to finish it. Not too bad for a week or so of work.

So that’s where I am now. None of it is what I’d call “polished”, but all of it is useful to some degree. The Devuan 1.0 for the browser and as a source for various configurations I’d done. The Devuan 2.0 as a build that actually works better (modulo the browser), but one where I need to figure out why their kernel / boot wasn’t booting and figure out how to get a working browser built. Then Gentoo as a place to continue expanding my Gentoo Build skills and what will likely (someday…) become my preferred system. The feature Gentoo has is you can control everything in the build to assure it works. The problem it has is you MUST control everything to get it to build… so I CAN make it right… once I know how to make it right…

Yeah, all this to make a $60 SBC work the way I want when I could just buy a board that was more broadly supported and without a PITA boot design and be done. Oh Well. Odroid makes well thought out hardware even if their software choices are, er, “limited” so you get to roll your own a lot…

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

9 Responses to XU4 Devuan 2.0 Progress

  1. E.M.Smith says:

    Well, I’ve got a working FireFox on Devuan 2.0 now.


    Well, seems FireFox is complicated, but keeps everything it needs in it’s own special place… so I just copied it over. From where it was in Devuan 1.0 to the same place in 2.0.

    I can now, basically, just live in the 2.0 system should I so desire.

    The starting point for FireFox is /usr/bin (do a ‘which firefox’ to find that).

    root@(none):/usr/bin# ls -l firefox*
    -rwxr-xr-x 1 root root 113 Oct  8 01:19 firefox
    lrwxrwxrwx 1 root root  30 Oct  8 01:20 firefox-esr -> ../lib/firefox-esr/firefox-esr
    root@(none):/usr/bin# cat firefox
    FIREFOX="$(which firefox)"
    [ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
    exec firefox-esr "$@"

    So actual firefox command runs a script that finds firefox-esr that is a symbolic link off to /usr/lib/firefox-esr/firefox.

    OK, copy the script from /usr/bin and copy /usr/lib/firefox-esr over, then make the sym link.

    I just did a cd to /usr/lib then “cp -r firefox-esr /SD/misc/usr/lib” (or where ever you mount it).

    It does not show up as firefox in the menu of LXDE, so I need to figure out how to make that happen. For now I just type the firefox command in a terminal window and up it comes!

    Nice! In a bastard hybrid system kludge sort of way ;-)

    But really, at this point, I have everything I need on this platform and I can let go of the Devuan 1.0 stuff while I continue to work on Gentoo. Devuan 2.0 is getting security patches et. al. so that’s a nice thing.

    I’ll leave this system multi-boot, and since my home directory is a separate file system mounted “wherever” it doesn’t matter really which partition I boot.

    But at least I don’t have to do the funny “launch htop by braille” to get my cursor to show up ;-) (A bug I’ve been living with in the 1.0 uplift system…)

    it is rather nice to have that burr out of my bum AND to have solved “How to get some Devuan 2.0 on Odroid XU4”.

    So for now I’m taking a break with my friend Cabernet and I’ll come back to being an ersatz systems programmer tomorrow… That whole “how to get the newer Devuan 2.0 kernel to boot” and “how to get X on Gentoo to work” stuff ;-) With a working updatable Devuan 2.0, the pressure is somewhat off for those things.

    BTW, I’ve just learned the term “Distro Hopper” for folks who run multiple Distributions and change between them frequently… So I guess I R 1.

    The world becomes a different place when you start to think of an operating system as kit of mix-and-match parts…

  2. E.M.Smith says:

    I wonder if this might be part of why the direct-to-SD image would not boot. /etc/fstab.

    As it comes from the tar file, it has an odd entry that caused booting to fail on the fsck:

    ## bootfs
    /dev/mmcblk0p1    /boot         vfat   defaults                  0    1

    It expects to find the /boot directory on a FAT partition. Yet the dd of=/sd/card has all of / including /boot on a single EXT4 partition. Then, this /etc/fstab entry would have it try to do an fsck of that FAT file system (that last “1” entry) where it will fail.

    IFF it is further configured to NOT show all the boot up details, but just log it until you get your login screen and get on the system, all the observer would see is “failure to boot”.

    So, OK, today’s task / experiment will be to make a new “dd” copy of the image file and inspect it prior to attempting to boot it. Mount it as a file system and see if the /etc/fstab is broken. Look in /boot at the boot arguments. Etc.

  3. E.M.Smith says:

    Pre my speculation about /boot FAT etc. That’s not it. I just did a re-image of a card.

    Devuan comes in two flavors of packaging. A compressed “tar” tap archive file format. And a compressed “img” disk image format. Until now I’d used the “image” and shoved it at a uSD card. For this (successful) effort, I used the “tarball” and stuck it into a partition on a uSD card that already had the boot sector at the front, and just repointed the boot.ini and existing kernel.

    ems@(none):/SG2/ext/SW_Images$ ls devuan_ascii_2.0.0_armhf_odroidxu4.*

    Well, turns out that the “img” isn’t really an image. I is MISSING THE SIGNED BOOT LOADER entirely. THAT is why it won’t boot.

    So what OUGHT to work, is to make a uSD card with the boot loader up front, then put the FAT and EXT4 partitions in place and load them with the stuff (either from the image file or the tarball) and call it done. So one wonders if the boot sector is “special” for boot via first FAT partition or via first EXT partition or if it doesn’t know or care… A “mis-match” problem where the release has FAT and my old system looks for first EXT4 file system type might explain some prior failures at making a hybrid boot.

    So, OK, only about a year late I’m getting a bit of clue about how to make Devuan 2.0 “go” on the Odroid XU4. BUT, what is very clear to me is that the Devuan release packaging guys did ZERO boot testing on their “.img” version.

    In this screen grab of gparted for the working uSD card, you can see the bootloader sector as a thin grey line at the very front.

    In this fresh Devuan img based uSD card, the very first sector is the FAT /boot sector. NO leading bootloader sector!

    To quote someone or other “Well, that there’s your problem right there…”

  4. p.g.sharrow says:

    Oh wow! “there is your problem right there!”
    Back in the not so good old days when I was assembling working PCs and XTs from other peoples cast offs and junk piles. Installing OS would often fail because of non-existent, misplaced or corrupted Boot files. Being uneducated and ignorant of these things and the fact they were “Hidden Files” caused me no end of aggravation and frustration over why some installations would fail while others would succeed. At some point I discovered the fact that the “boot File” had to be the right type in the right place or nothing else would work.
    More modern systems seem to be smart enough to find their needed files as long as they are “in there someplace”, it just takes longer to start up as the machine hunts for the needed files.
    I’m glad to hear you are back to successfully using Devuan2 on your selection of machines as it appears to me that Devuan may well be the OS that is needed when I am forced to ditch MS. I really don’t want to retrain my brain again. In my world a computer is “A” tool, not “The” tool, So while I follow your work with interest, I don’t really want to learn it all. I’m glad that you are doing the grunt work on finding the best path for others to follow…pg

  5. E.M.Smith says:


    FWIW, IFF I ever end up with the Holy Grail System working really just right, AND it’s a PITA to make: My intention is to make “human friendly” releases of it.

    Rather like you get new “Distributions” that are really just a re-spin of, say, Debian but with a particular collection of window manager, desktop, and applications all installed,tested and running.

    So IFF I ever do end up with the Magic Gentoo (PITA to make), you would find I’d also have up a fully made and configured system (along with binary online archive) so folks would not need to do things The Gentoo Way (all source all the time roll your own).

    That said, I’m really glad I’ve got A working Devuan 2.0 on the XU4. Now I’m going to see about making one that’s all 2.0 all the way. Including the kernel bits. I really like Devuan on the other boards / boxes where I have it. I’ll never completely abandon it no matter what else does what I want.

    FWIW, pondering this a bit: I’m suspicious that maybe the .img build is intended for the emmc card, not uSD card. I need to look at the directions for making an emmc based distribution install and see if it has special “build your boot sector” directions.

    I could easily see this being a conflict of assumptions. Devuan assuming I have an emmc card and me assuming they are making a uSD friendly image. I’d like to think it was that kind of Mutual Stupidity Bug and not a flat out failure to test their release on their part.

    But it is unlikely I’ll do that today. Today is an Australia Friday day, and that means some wine will be involved. Copious Quantities of Wine are generally not compatible with hacking disk partition table blocks and boot loader segments…. 8-}

  6. E.M.Smith says:

    Well, I’ve confirmed it.

    The Devuan image and tarball both expect to be installed to the mmc card. While I got one with my XU4, I’ve not seen it in a couple of years… so it is “somewhere safe”. For swapping distros, it was easier with the uSD card, so I decided to just go with it…

    So the basic problem is that the stuff in /boot is “all wrong” and the /etc/fstab entries are screwed up too.

    So, to make a system that works, you need to take the /boot stuff from some other distribution that does work (like Armbian, Ubuntu, Debian) and stuff that into /boot while hiding the stuff that is there. One complication here is that the release level MAY sometimes matter. Much of the time it will not, but sometimes “things change”.

    Then, since stuff is NOT on the mmc card, there are not on /dev/mmcblk0px but are on /dev/mmcblk1px instead, so your /etc/fstab has to reflect that. Also, your boot.ini command needs to know what partition to boot and you will want to add that “net.ifnames=off” to the end of the command.

    That ought to give a working system. Note that the mcc boot does not have a boot.ini but instead has a different file. boot.cmd I think it was.

    The stuff in the SD card /boot:
    armbian_first_run.txt	   dtb-4.14.133-odroidxu4	  uInitrd
    boot.bmp		   dtb-4.14.94-odroidxu4	  uInitrd-4.14.133-odroidxu4
    boot-desktop.png	   dtb-4.9.61-odroidxu4		  vmlinuz-4.14.133-odroidxu4
    boot.ini		   dtb.old			  zImage
    config-4.14.133-odroidxu4  initrd.img-4.14.133-odroidxu4
    dtb			   System.map-4.14.133-odroidxu4
    The stuff in the tar blob /boot:
    boot.cmd  boot.scr  exynos5422-odroidxu4.dtb  zImage
    And what is in the tarball boot.cmd?
    setenv bootargs console=tty0 console=ttySAC2,115200n8 verbose earlyprintk debug root=/dev/mmcblk1p2 init=/sbin/init ro ${extra}
    load mmc 0 0x43000000 ${fdtfile}
    load mmc 0 0x41000000 zImage
    #load mmc 0 0x50000000 uInitrd
    #setenv initrd_high 0xffffffff
    #bootz 0x41000000 0x50000000 0x43000000
    bootz 0x41000000 - 0x43000000

    So you can see that boot.cmd is expecting an mmc card.

    Essentially, there’s noting really wrong with the Devuan 2.0 release images. They just are not expected to be used with a uSD card. So to do that “some assembly required”.

    It would be nice if they made images both ways, or even if they just put a marker in the system name like -mmc- or some such.

    So now, having done this quasi-mode-o in my running system, I’m going to try documented a denovo build.

  7. E.M.Smith says:

    Well, it worked “from scratch”. Writeup will be posted tomorrow sometime.

    Basically, did an Armbuan install. Copued /boot to a safe partition. Erased Armbian. Extractec the Devuan tar ball into that #1 partition. Moved /boot to /OldBoot. Made a new /boit and copied the saved stuff into it. Then just housekeeping: Fix /etc/fstab to not point to the FAT partition that doesn’t exist. Change /boot/boot.ini to point at your new SD card (UUID from FILE -s or just LABEL=)

    That’s about it.

  8. E.M.Smith says:

    Posting this from the brand new all from first images Devuan 2.0 on XU4. Now begins the long process of “moving in”… I’m thinking that I’ll actually copy my data to a new space instead of just mounting my old directory. Why? Well, every so often I dump the baggage of any unknown cookies, stuff in caches, “whatever” corruption of config files, etc.

    In particular, the main account has some .xwhatever config file a bit confused, so it’s not giving me the ability to move windows properly. It happened about a week ago during the repeated swapping back and forth from Slackware to Devuan. Yeah, I can likely fix it be copy of a nw “whatever” config file telling X windows to behave itself. But…. It’s also been a few years and a few dozens of “system swaps” since I last did a reset of the home directory… so probably about time.

    The Magic Sauce to get firefox install on Devuan 2.0 is “apt-get install firefox-esr”, so I now have a nice new FireFox (78) installed. It is working very well, so far. Including working sound and video!

    OK, It’s Friday and I didn’t get the “Friday in Australia” posting up in time, nor a new W.O.O.D. nor an update on where the world is ATM… BUT, I got Devuan 2.0 to work! ;-)

    Life is full of choices…

    So in a few hours I start California Friday Sushi & Sake night… IF I’m lucky, I can get those postings up before the Sake starts flowing. Or maybe that’s if I’m unlucky ;-)

    At this moment, I’m really Really REALLY happy to have a new, clean, highly functional Odroid XU4 Devuan 2.0 running on an entirely clean new install process. AND with a working browser.

    One AwShit notie: Chromium just gives a flash of brief blue widow and crashes. Not yet working right here. Works great on Armbian. Go figure. I’m somewhat agnostic on browsers. ( I swap between about a dozen different accounts with ‘whatever’ browser to muddy any tracking ). BUT, I really love Brave on my tablet. So on my “someday do” list is to get Brave on ARM on SBCs. IFF it’s already built, fine, download and go. IF I have to build it, port it, well, OK… but later.

    Gentoo? My efforts to learn Gentoo enough to get it running AND fully loaded with aps on the XU4 will continue. While emotionally I prefer Devuan, and even with this porting grief it is easier than Gentoo: I need to assure I have an alternative non-SystemD solution in hand should things go sideways with Devuan.

    OK, enough babble, back to documenting what the heck I did to get this to work!

  9. Pingback: Friends Of Australia Friday Lambburger With Cheese! | Musings from the Chiefio

Comments are closed.