From the “Well that right thar is your problem…” department.
Here’s a screen shot (cropped) of the gparted display of an Armbian XU4 runnable system and the just re-flashed Devuan 2.0 (doesn’t boot) for the XU4. See the difference?
This is Armbian and it works. In particular, note the first 16 MB ‘grey area’ byes. That’s where Odroid has you put their signed boot loader as a binary blob.
gparted screen for Armbian XU4 uSD image that works
Here’s the Devuan image that doesn’t work:
Devuan 2.0 for the XU4 doesn’t work
So….
Where’s the boot loader?
This is the bit that makes the Odroids “different”. That grey blob at the front. Hardkernel have directions on their web site for how to put that there ‘on your own’. It is basically a dd of some block size / count, then you dd the rest onto the image starting after that block.
I already know the Devuan 2.0 userland works on the XU4 as I got it to boot using an entirely different kernel (but blew it on the DTB device tree bundle and it didn’t see my keyboard or mouse). So, OK, now I ‘have clue”.
Their full image is more like The Usual boot on other systems with /boot in a FAT partition and the userland in ext4. Somebody just didn’t make the XU4 image in the “odd Hardkernel way” and did it like everyone else…
So I need to find the directions at Hardkernel and “roll my own” installing the boot loader in the grey bits, making the ext file system where it belongs, and loading the tarball Devuan 2.0 into it. In Theory…
So “some assembly required” but at least now I know what to assemble… and what to leave alone.
I think this is the “recipe”, but I might just try a dd from a working earlier version…
https://wiki.odroid.com/odroid-xu4/software/building_u-boot_mainline
Seems to me that “dd bs=1M count=16 if=/SD/Armbian of=/dev/sdx” ought to work… maybe.
So guess what I’m doing “for a while” ? 9-)
IF I have the time, I might actually figure out how to report this as a bug:
Musings from the Chiefio 
I read these comments withe great interest but seldom have clue how to apply the wit and wisdom.
@G.C.:
Obscure tech stuff is only useful to someone who has the same needs and context. Like putting down the recipe for rattlesnake pie only matters to someone with s supply of rattlesnakes who wants a meat pie…
I often do these just as my notebook to a future me. Fairly often I find myself thinking “How did I do that mount a file like a disk thing?” and searching for the posting I did. Also, often, like this one, I’m posting a problem and speculation and the answer only comes latter in a comment, from me or others.
Mostly it just lets folks know what I’m doing and see that it often isn’t either quick or obvious even to an experienced hand.. So not to worry if you get stuck for a while too, just keep whacking at it…like I had to do. Basically, amusement and encouragement by example.
FWIW, the Armbuan boot section with devuan userland would not boot as a uSD. But when I swapped back to the original Armbian to boot it, and left the hybrid uSD in thd hub, the sucker booted thd hub dongle and I was in Devuan. Not sure why, but I think it was booting by UUID and the cloned boot area had the same UUID.. I’m trying it all again, but with a cloned bootloader area from an Ubuntu instead. IIRC they put explicit bootargs in the boot.ini or boot.cmd and I might get more options.
Knowing I need to make that 16mB boot loader area is nice, but I still am a bit clueless on how to make the right one… This is that “very hard to work with boot process” from Odroid that folks talk about… made deliberately “secure” and obscure for “security” that isn’t needed on a lab board…
Well, it looks like umpteenth time is the charm!
I now have a working Devuan 2.0 on the Odroid XU4. Hooray!
How?
Roughly, the Ubuntu from Hardkernel has a different boot layout. No grey area either and with separate boot and root partitions, boot being FAT.
I installed a big (7 GB or so) Ubuntu, booted it up once so it could do any partion resize and prove up the kernel and boot process, shut down and rebooted on Armbian (any os ought to do) , mounted the 2nd partition from the uSD on /SD/ext, then went in and deleted everything.
At this point it has a first partion that’s FAT and boots. Then I did a tar xvf Devuan.tar.
Swapped back to that uSD and it booted.
I’ve done the update upgrade and now it is installing LXDE. In a while I will be posting from it (right now is the tablet..) with more specifics.
Well that’s a bummer… on reboot it complains of missing firmware and enters maintenance mode. Bypass that, I get the nice GUI Login screen, but again kb and mouse not working.
udevd [427]: could not open moddep file ‘/lib/modules/4.14.141_169/modules.dep.bin’
s5p-mfc 11000000.codec: Direct firmware load for s5p-mfc-v8.fw failed with error -2
s5p_mfc_load_firmware:73: Firmware not present in /lib/firmware nor compiled in the kernel
So looks like some kernel modules I need to fish out of the Ubuntu image to do the Xwindows thing w/ kb & mouse… so a bit more to do…
In maint mode, poking around, it has /lib/modules/4.14.48 so a different kernel build.
UPDATE: well, mounted the Ubuntu .img file as a disk mount and just copied all of lib/modules over. Now I’m past that, but it is complaining about firmware, so one more iteration:
Direct firmware load for s5p-mfc-v8fw failed with error -2
Not present in /lib/firmware
What a difference in the firmware directories!
On the Devuan image:
vs on the Ubuntu image:
I need to check that the Ubuntu stuff doesn’t stomp on the Devuan entries, then copy it all over, but man that’s a lot of stuff. I get the impression Ubuntu is tossing in firmware for just about any device you might plug in…
Copied over with:
after moving /SD/ext/lib/firmware to Devuan_firmware, then doing a mkdir firmware… All the stuff in Devuan_firmware looked to exist in the Ubuntu firmware directory, so I decided to just set it aside in case f release level conflicts / dependencies…. but have it still available just in case and for comparison later.
OK , last post of the session:
I still get dumped into maint mode w/ ctl-D to continue. If I continue, I now have working KB & mouse, can login, and stuff looks good. Htop works. BUT, after installing FireFox and Chromium, both have failure to launch / crash issues.
So: Good news is the strategy works! Bad news is I’m in kernel dependency hell…
Believe it or not, this is great improvement.
I can either look to back level the Ubuntu kernel, or just copy the one ftom the Devuan (or other install) over as long as it is the right release level.
Basically, we now now how to get it to boot, so it is either stuff in the matching kernel, or if that kernel is broken, do a make kernel. But as it is pushing 3 AM that’s for after a nap…
With luck I can A/B the As Shipped Devuan build with this one and figure out what is broken in their build iso too.
OK, so another day, another WT?
I swapped to the Devuan distributed kernel and DTB for exynos… and booted… and launched FireFox and Chromium … and it acted exactly the same.
Here you can see where I set aside the two Ubuntu versions (zImage and the dtb file that matched in name the one from Devuan – the others ought not to matter and are likely compiled into the Devuan kernel which is why it is larger and does not need them as dtb loads)
So the good news is that this likely narrows down the reason for the failure to boot to NOT being the kernel or dtb. That just leaves the initial ram disk uInitrd, and the actual bits of boot code. Devuan has a boot.cmd and boot.scr, not a boot.ini file. So something different in the boot…
This further implies that it is unlikely the failure of the browsers is due to kernel dependency issues or device tree bundles (dtb). So what then?
At this point I need a bit of a think. I’ve pretty much cut back the stuff used here from Ubuntu. I did have a few bits of holdovers in firmware and modules, so maybe there?
It is likely easier to just archive a copy of this, burn a new Ubuntu Boot, and then try again without the Ubuntu firmare / modules / kernel /zImage / uInitrd. Just the boot bit and the boot.ini…
It seems to me the only potential points of failure for the browsers at this point are the firmware / modules swapped (if any have effect) or the build is just broken for the browsers.
But enough for now. After a second cuppa’ I’ll try just backing out the Ubuntu modules / firmware on this image, then resort to the more drastic “do over only use the Ubuntu boot and nothing else”…
At that point it will either work, or I’m out of possibles to try and will just wait for a new release from Devuan (and use some other SBC as my daily driver. I was using the R.Pi Devuan for a while in there and it is still pretty nice. A bit slow on loading some web pages, but OK…)
Now, where’s that kettle…
Backing out the firmware didn’t fix the pausing in the boot for “Ctl-D to continue” but re-introduce a “not found” message. Also didn’t fix browser failures.
My conclusion at this point is that the Devuan boot is what is broken (since I’m using their kernel, dtb, firmware, etc. but not their boot and it DOES now boot) so “for the future” that’s where I’ll go look. It is also pretty clear that Userland does work, but also that their is some Dependency Hell issue in trying to graft it onto a very different Ubuntu release level.
This implies I either need to learn how to “Roll my own” Devuan (best) or find a better matching host boot to graft onto (easier but more risk of failure, which see above…)
So, for now, I’m swapped back to the Rock64 running Slackware. I’ll putter more on XU4 Devuan “at some future time” but this goes back to low priority. I may start with the Devuan install .img version and just swap the boot bits (on the assumption that’s the minimum possible change to make it boot; and that they likely did test a browser launch in that code so it ought to work).
I’ve not given up on Devuan on the XU4. I fully expect some future update will be done right and I won’t have to fix it. Unfortunately, that might be a year away. So for now I’m likely to just backlevel it to the 1.0 I was running before (and either accept no updates / installs OR figure out how to use the archived repository) OR run it on straight Armbian with SystemD (BOOOO! Hiisssss) which isn’t my favorite idea.
But for now, I’m going back to the Slackware platforms to “get some work done” and will be finding out more about installing packages on them. I’ve got the basics down, but need to learn the source “Slackbuilds” bit (since it looks like Chromium is a Slackbuild)
Would it be more efficient to just pick one platform / OS and focus on it pushing harder? Only if you already KNOW just which one is preferred… If you semi-randomly picked the one with great issues on a given hardware platform, you can spin for months (years…) on it. As I have a bunch of orthogonal SBCs, the odds one of them would be “a Pill” on a Single Size For All becomes large. Thus my present strategy of “push some on several places and see what moves furthest fastest on a given SBC”. So far, that’s Slackware on systems where Devuan doesn’t “go”.
But “We’ll see”…
Why the nearly-an-OS browsers as first apps to test?
Not the first (htop and terminal window, apt-get and some other utilities are first) but close. Why is simple. I run a blog. About 3/4 of what I do depends on a browser. No browser, no joy.
Yes, I can relegate the SBC to some server like use, and have a couple of headless servers; but those are almost universally the very cheap and slower SBCs. R.Pi M2, Orange Pi One. May even do it with the $17 Pine64 A64. BUT, the Odroid XU4 is an octocore SBC that makes a very nice dekstop that plays video well. So why wast that on a headless server?
In short: Since my goal is a nice decent performance desktop to run a browser, I test the browser.
Ah. Perhaps smaller intermediate steps then (when time permits)? Ping, Dillo, Netsurf …
This may help: https://forum.odroid.com/viewtopic.php?f=96&t=30552
Good hunting!
FWIW, I don’t need to start with Ping as I start with setting the clock from my private network time server. Networking must be up for that, and it assures proper time stamps in following operations. Then I have a “pingout” command that goes by steps to the lab router (inside / outside interfaces) the house router (inside / outside) and the time server and then to an external responder site. I only use that if the apt-get update fails (as apt-get update depends on all that other stuff).
I’ll then load “my usual suite of applications” that includes NFS so I can mount my NFS server and a couple of other file system types. IF not already installed, then LXDE or XFCE pretty much shakes out the basic functions. (Oh, and Build-Essential goes in too). First thing I do then is launch htop. Gives me system status information and lets me monitor what’s going on, and shows general windowing working OK.
After that, I’ll log back in graphical. Assuming that works, and I’ve got my nice graphical environment, working networking, nfs file server, update / upgrade done, etc…. THEN I try a browser as that’s pretty much all that is left.
As per Dillo and Netsurf:
Not that fond of them as browsers. Even if they DID work, I’d not accept the build if Firefox or Chromium didn’t work. Might be useful as a “fall back” for diagnostics AFTER the big browsers fail, but not before, given my work flow on the blog.