Today was spent doing some tech tidy-up and exploring a few other bits of Tech Stuff. The very short form: On the Odroid XU4, after an update to the latest (Armbian uplifted to Devuan) the USB 3.0 is working! A direct install of Devuan 2.0 hung up on no working network without some added work…
More Detail:
I started the day with the designed for XU4 direct install of Devuan 2.0 “Ascii”. It boots. It works. Oh Joy! In prior times they had an XU 3/4 build that was supposed to work on both, but didn’t work on the 4. Now it works. the downside? It shows up without Ethernet working. What’s wrong? I don’t know. It could just be that it needs some configuring, or it could be more. I edited /etc/network/interfaces and did what ought to be a usable config, but no joy. Perhaps just some other config stuff, or perhaps something bigger. I’ll be setting up a WiFi dongle in the next few days and trying again to get one or the other going.
Instead of flogging that horse some more, I booted my working Armbian / Devuan uplift uSD chip. Did an “apt-get update; apt-get upgrade”. There were some messages that looked to me like kernel and kernel modules not being upgraded (no surprise as it likely needs an “apt-get dist-upgrade” or a manual kernel swap for that). In any case, it worked and rebooted nicely.
After the reboot I decided to try the USB 3.0 interfaces again. Why? Too many hours spent copying disks in the last few weeks. Plugged in a 1 TB disk with an xfs file system on it and proceeded to dump some wads of stuff onto it. It Worked!. Watching syslog showed no error messages showing up. (tail -f /var/log/syslog).
So at the moment I’m busy moving one disk worth of “stuff” onto that disk and then I’d do a cmp compare on it to make sure things didn’t change in the moving ;-) After that, I’ll be ready to try moving some system directories (/tmp and /usr ) and then some speed tests.
I’ll also be doing similar testing on other file system types, just to be sure ;-) The xfs file system was designed by Silicon Graphics for very large and high performance file systems on supercomputer class machines (of that era…) and it might be that matters… Besides, once something “had issues”, it’s good to be cautious when it finally gets working.
It also seems like the screen “jitter” on dragging a screen is reduced (still there a bit on very busy screens with lots of windows open, but “livable” now).
So, with all of that, I’m going to spend the rest of tonight and likely some of tomorrow settling in on the XU4 as my “Daily Driver” with a USB 3.0 disk for home directory and more. Hopefully it’s just some config omission on the Devuan 2.0 purpose built build and I can get off of the Armbian / Devuan conversion hybrid approach.
So, in conclusion, finally it looks like my Odroid XU4 has reached the point where it’s usable as a much faster version of the R. Pi and without too many quirks. I do really like the speed it’s got. IF the next couple of days continue as a success, well, I’ll be quite happy to buy a second one! ;-)
Musings from the Chiefio 
I’ve moved a copy of my home directory onto a USB 3.0 ext3 file system, plus copied the few hundred GB of data from the xfs file system to an ext3 partition (both on USB 3.0). Then I put /tmp and the /var and /usr file systems on USB 3.0 disks / partitions.
It is all working Just Fine(!)…. and I’ve noticed a significant speed improvement. The copy disk to disk was MUCH faster than from USB 2.0 to USB 3.0.
The whole system seems snappier. No timing information yet, just experiential observations. I also put a 2 GB swap partition on the USB 3.0 disk. With swap, /tmp and /var all next to each other, a large many I/Os can happen with very little head seek. Then it also avoids the ‘write a big block’ problem with SD cards. (To write one byte, a large block of data is read, the byte changed, then the whole block written back. It’s on the order of 100,000 chars as I understand it – but I’d expect that to vary with maker and size of card.)
I launched a Youtube – CPU was only about 1/2 used ;-) I’ll try full screen HD after I move it back to the TV / HDMI monitor and off the “adapter to DVI” that doesn’t “do” sound…
Basically, it is almost like a real computer now ;-)
While I’m OK on the Armbian / Devuan uplift, I expect some of the petty annoyances to be gone in a straight Devuan 2.0 build; so hope it isn’t too hard to get networking working so I can complete the software download and configuration steps. Once that is done, I will at long last have the Odroid XU4 working as I wanted. It is darned close now, but still has issues with the launch of x-windows not showing a cursor until I click on something (which is a challenge when you can’t see it to put it ON something to click…) and then the jitter on window moves indicates the GPU isn’t doing the re-compositing – I’m hoping that’s fixed in the direct Devuan – the embedded folks who created Armbian are not big on fancy video ;-)
Well, I consider that pretty good for one night.
E.M have you tried the HC1/2?
@CoRev:
At $1500, um, no:
https://www.waspbarcode.com/mobile-computers/hc1-mobile-computer
Unless there’s some other HC1/2…
Looks like the networking kernel modules are missing. Doing a “modprobe R8152” works on this release and gives a FAIL on module missing on the Devuan 2.0 release.
(I’m using the same WiFi adapter in each case and the builtin Ethernet is constant too).
I need to find out what models are needed for the regular Ethernet and get them onto the chip, then loaded into the kernel. It is a crapshoot if I can just copy over the modules from this older version of the kernel, or not…
This is pretty sloppy Q.A. (IMHO) by Devuan. It means they didn’t even do a basic test of Ethernet connectivity. I probably need to find out how to report bugs to them, since web searches make it look like I’m one of almost none trying to run Devuan on the Odroid XU4… i.e. not a lot of other folks posting “how to” fix things.
Some bits of info for “later” of for anyone it might help.
I did an “lsmod” to list the modules loaded under both the Armbian and Devuan versions. The Armbian is at kernel 4.14.69 while the Devuan 2.0 is still on 4.14.48. While they are only minor numbers, it’s 21 minor revisions… so then I took the lsmod output and used that to make a script that looked up each module and told me about it on the Armbian. I then used that same list on the Devuan (since whatever is missing on it is present in Armbian) and figured I’d just look at “what was missing”.
Here’s the script:
Here/s the output on the Armbian build:
Then the output from doing it on the Devuan 2.0 build. Note that I did it with 2>> redirecting std err output into the same file to capture the module missing complaints:
Clearly there’s a whole lot of modules not there. Many of these, like btrfs, are not there as I’ve not been able to install the btrfs file system code due to no ethernet…
As I’m not sure what module is supporting (or supposed ot support…) the on-board ethernet, I chose the 8188eu module for my WiFi dongle as my attempt to get a module loaded.
Taking the stupid-and-hope approach, I just copied all the stuff in /lib/modules/4.14.69-odroidxu4/kernel/drivers/net/wireless/ from Armbian to Devuan. Hey, it was worth a shot. The driver is clearly in there… but it is from a different kernel level…
Well, it didn’t work. Modprobe still didn’t find it, even with a reboot.
So now I have a few chioces.
1) Live on the Armbian / Devuan “uplift” until Devaun gets a round tuit and adds the drivers.
2) Learn the right way to build and install the modules
3) Try grafting the Devuan UserLand on top of the Armbian kernel – modules and all.
Folks saw me do that grafting of userland onto a different kernel back with the Devuan 64 bit kernel and 32 bit UserLand (when 64 bit UserLand was having issues like FireFox not well…). The difference here is that it’s different kernel levels, so if any fundamental calls changed, or libraries are incompatible, well… but it ought to work ;-)
I’m most likely to just do #1 for a while. Well, by definition I’ll be doing it anyway until something gets fixed one way or another… but the key point is that I won’t be doing much of #2 or #3 to get away from #1. I’m not really interested in becoming a Kernel Systems Programmer… Even just at the making kernel modules level. I might though… if it becomes necessary.
Before that, it is modesly likely I’ll try grafting Devuan 2.0 UserLand onto an Armbian (uplifted) kernel & modules. It ought to be fairly quick so if it fails, not much time wasted. But not soon. I’ve sunk about as much time into Devuan 2.0 native on this board as is reasonable for now. I have a working version, and lots of higher priority stuff to do… But “someday” when the urge hits, I’ll give it a go – unless Devuan fixes it first.
So, OK, on to “other stuff”… for “a while”…
E.M. I meant the Odroid HC1/2 https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/ $54 and includes a SATA-3 connection for the HDD. AFAIK the difference between the HC1 & 2 is the 2 can fit either a 2.5 or 3.5 inch HDD.
Ah, yes, their “Home Cloud” thing. I looked at them but didn’t do anything with it since I didn’t have the XU4 working well yet. It’s basically an XU4 with a huge heat sink and SATA attachment point.
At $49 that HC-1 is a pretty good deal. I’ve got some old dinky disks harvested from various laptops that died over the years… Hmmm….. ;-)
Oh Yeah… now I remember why I gave it a pass… No video out.
As I have about 28 TB of USB 3.0 and almost no SATA drives (just some old few GB ones from laptops being recycled.) Then that zero video possible… I’ve used video a lot when trying to debug or configure a “headless” server… I’m willing to pay the extra $12 or so for those two features…
Now were I building a large disk server farm, it might be worth it…
Ethernet connection? You don’t hear that much anymore ;-)
One wonders if you could more easily incorporate a wireless adapter.
I prefer Ethernet. It’s way faster than WIFI. More stable and secure, too.
I don’t stream much, but when I do, I don’t want it spacing out all the time.
I also have all my stuff hard wired with CAT 7 Ethernet cable. Minor hassle to set up but once put in place it is trouble free, and you don’t have to worry about someone hacking your wifi system.
It is getting a bit difficult to find modems which are hard wire only though as the general market thinks wifi is the only way to connect computers now days.
As an aside on DietPi:
I have just sunk this morning into trying DietPi on the XU4. Why? Why not? (Really it was just to see if that light weight distro would be an easy path to a network appliance or to a web browsing desktop without the drama of of an Armbian -> Devuan uplift or Devuan-no-network fixing.)
Well, it had drama…
First off, the download was quick and the “dd” onto the chip was very fast. WooHoo! Put it in and power up and blinky lights… and blinky lights… and blinky lights… (Some searching and web searching later and nothing clarifying…) I had an “insight moment”: Wait, I’m using the DVI Monitor with HDMI Adapter… but the XU4 works with it fine… but it’s different software… but… Swapping to the TV, it boots to a viable screen…
OK, I then re-flashed the uSD card (since who knows what state the first boot was crashed into via powerfail). Reboot… Now I get the various screens it starts with to config. Ncurses based (big blocks of blue with embedded menus): UN-fortunately the “color” is basicallly light grey text on a lighter sort of white background embedded in a light grey panel background… Getting close, and low, and squinting I can read it… so I go ahead. ( I think this is an artifact of the TV having different contrast behaviours from the typical monitor settings)
The Diet Pi has a menu driven network based software selection and installation process. It MUST be used. (You might be able to bypass it, but then it’s all manual all the time if you can figure out where they do things). So this isn’t a “stick in the image with LXDE and boot”. It’s “boot to a login and run the configure script / program that pulls stuff down via the internet”. OK, I chose a bunch of stuff, installed it, and LXDE was one of them. It reboots 3 times during this whole process. One to update / upgrade the base set. One to install some stuff. One to configure it more.
On final boot as a login, it failed with a “X can not find screen”. OK… So “something” in the X-Windows conifig is messed up. No LXDE for me.
As I’m VERY un-fond of X-windows configuring and debugging (having done way to much of it in my life) unless there is some VERY compelling reason to use a given system / OS / whatever; that is just a deal killer for me. Especially when it’s supposedly a user friendly hand-holdy release. Look, just put up a Desktop Image WITH some desktop (preferably LXDE or XFCE) already working. Let it be a simple “download and boot”. Please.
OK, it was all of about 3 hours wasted (or “learning experience”…) so not a huge thing. It was “waiting for coffee to hit” time mostly, so even less of a loss of productive time. Since it REQUIRED the TV, I was not able to watch news and get double duty out of that time for about 1/2 of it. (My normal habit is to have some news / financial show / info feed running on the TV so ‘lost time’ and ‘waiting for command to finish’ is not wasted completely.)
My conclusion:? Like a lot of other software releases, the support for the XU4 “has issues”. Folks pretend it’s 100% compatible with the XU3 and it just is not. NO hardware that is different in even minor ways is 100% compatible. Some can be close enough, but this isn’t. Furthermore, like most folks, they have “cheaped it” on making sound & video work well. I know, it’s hard. Leaving it for your end consumers to cope with is still a bad idea.
Thus ends my XU4/DietPi exploration.
One other side bar note:
Having watched the HTOP display of system usage, the Octo-Core is not nearly as important as 4 fast cores. THE major benefit is the notion that it shifts to 4 low power cores when load is light. This matters a lot in a battery powered tablet or phone, not at all in a desktop SBC. It is most likely that a simple Quad-core higher end SBC would be as high performance or better – and have far fewer issues with software support. On the DietPi website, it shows some comparative performance graphs for various boards that seems to indicate the same. FWIW, a YouTube video comparing a bunch of boards found the Rock64 and RockPro64 were about the same or beat it. I’ll post that video (if I can find it again) in a future posting. So while I do love the XU4 for the speed and experience, it is likely that a fast quad core would be better and cheaper.
I have a Rockchip based board on my Christmas List so I might end up evaluating one of them next year ;-)
@Ossqss:
Well, that depends…
Yes, you don’t hear about it much anymore – that’s largely because it just ALWAYS is expected to work 100% without any issues. And mostly it does. What’s to talk about?
Of the systems on my desktop, one is occasionally WiFi based connectivity. 7 are only Ethernet. That one that is WiFi is also Ethernet connected as needed / desired. In the bedroom, the Chromebox is an Ethernet connected media box that can do WiFi is needed but mostly not.
What’s WiFi?
The Macbook Air (has no Ethernet port) and cell phones, along with the Rokus.
I’m going looking for a wired Roku…
Why?
As pointed out by Power Grab and Larry: It is SAFE and SECURE and FAST and TROUBLE FREE.
I’d also note that with the insomnia issues we had with WiFi at default (hi) power settings, we’ve cut the WiFi power way back and shut off 5 GHz and things are much better. This makes me very concerned about ubiquitous 24 x 7 WiFi / 5G. We now shut off the WiFi when sleeping. (Thus the desire for wired Roku so I can watch TV when the spouse goes to bed early ;-)
So “going forward” my direction is to reduce WiFi use as much as possible with a goal of “only turn it one when needed for an hour or two / day” for devices that are not wired Ethernet capable. Had I a wired Ethernet Roku in the office I’d have WiFi off for an additional 10 hours / day…
Setting up WiFi dongles is one Big PITA. It still has too much “black art” in it and not all devices work with all software choices. There’s a degree of arcania in choosing your settings and it just isn’t a “plug and go” thing for most folks. It is one of my “cringe jobs” on any new platform. Here in Silly-Con Valley, there’s so much use that I have to audit the current usage and try to find a non-crowded channel. Most folks don’t bother and then you get 4 houses all watching TV over the same channel and throughput suffers. (My neighbor’s WiFi is now a stronger signal inside my house than is my own WiFi… I get “full bars” off at least 6 sources… while I’ve cut mine down to 2 bars in the living room).
So that’s why you hear a lot about WiFi and nobody bothers talking about Ethernet. What’s to say? I plugged my computer in and it worked….
@Larry L:
It is usually possible to shut off the WiFi. (Though it isn’t always clear if that actually shuts off the hardware transmitter… so checking the signal can matter).
I’ve built WiFi routers out of a R.Pi and it wasn’t hard. Unless I need one from the Telco due to some requirement of theirs, I now build my own internal use WiFi routers via the Pi or similar boards. An 8 port switch is pretty cheap these days ($40? something like that) and plug that into a SBC with a WiFi dongle to get a router. (some assembly and configuration required ;-) Using something without an on-board WiFi means you can “pull the dongle” when you want to KNOW WiFi is dead…
Since most WiFi is well under 100 Mbit, the typical 100 Mbit Ethernet is fine for the uplink to the WiFi router. (I.e. you do not need a GigE port SBC)
Frankly, it takes me less time to set one up than it takes to buy one – either from driving to the local Fry’s or sinking time into reading specs and stuff on Amazon / Web Searches and deciding what’s going to work. Once you have some WiFi dongles in a drawer and a couple of SBCs that are not dedicated to constant use, it’s really fast to cobble one together. When AT&T killed my ADSL service, I tossed together a R.Pi with ethernet to my internal network and WiFi to a hotspot (T-Mobile) and used it as my router; all in about an hour. Use it for about a week until AT&T fixed things… It’s a good skill to have ;-)