My rice'd up N2Plus

Post Reply
User avatar
mægpie
Posts: 13
Joined: Mon Feb 15, 2021 3:00 pm
languages_spoken: english,german
ODROIDs: Odroid-N2plus
Has thanked: 12 times
Been thanked: 15 times
Contact:

My rice'd up N2Plus

Post by mægpie »

This is no howto for some maker-project nor anything that needs hardware modification.
I bought the N2Plus last spring, because it appeared to me that this could be the first ARM-SBC capable of running a full-featured linux desktop on a mainline kernel.
At this time I was wrong and it took nearly one year of trial-and-error from my side and much development effort from the community for the result, that I want to present here.
I will also comment some decisions that i made and the pitfalls I had to overcome.

So - take a look at my new workhorse:

Image Image Image Image

Fancy, he ?!? :mrgreen:
Some impressions of the workflow. I have no HDMI-Grabber, so the screen capture was made with wf-recorder on the device and it all seems a bit laggy - but in real-life it all works absolutely fluent and snappy.

[youtube]8VbGbfWQBAc[/youtube]
[youtube]2CsUxcradic[/youtube]

When I assembled the system I took a close look at the RAM and CPU overhead of the components.
Basically, I wanted the system as lean as it can be, Wayland was big priority and it should be - of course - Archlinux based.

I knew Wayfire already, i tried it beside the Plasma-Desktop that i ran recently. It appears to me, that this Project is the most promising, innovative and mature Wayland-Compositor with the most active development atm. (Beside Mutter, but Gnome isn't an option for me.)
And it takes no time to become familiar with it and its configuration options, its well-documented and by its modular design it can fine-grained configured to suit one's needs.
So Wayfire - check!

At some time i flirted with an Voidlinux installation, because of its reputation as an maximal lean distribution. I researched about it, and decided that this would be an adventure to spare for another day... ;)
But the possibility of gettin' rid of SystemD seemed quite appealing to me. I came to archlinux ~ one year before they switched from SysVinit to SystemD and felt somehow that Archlinux has lost a little bit of it's shine for me with this decision.
Just my opinion - I have nothing against SystemD - I just have never become familiar with it. After ten years of using Arch I havent fully figured out, how this systemd stuff works. For SysVinit it took ten hours...
Long talk, short sense - I stumbled upon https://artixlinux.org , a archlinux distribution that runs three optional init-systems, one of them runit, the init of Voidlinux, and the ARM port of it : https://armtix.artixlinux.org
Installing it was a piece of cake at first - I downloaded the provided runit ROOTFS and symply rsynced it over the base ALARM-Odroid-N2 image rootfs (without /boot and /usr/lib/modules), rebooted, added @jgmdev's repository, updated linux-odroid-511 and u-boot - BINGO!
It booted at once to tty, including sshd.
(On a later try with the December image this hasnt worked for some reason, I then took the route that is explained in the "Migration" article of the Wiki: https://wiki.artixlinux.org/Main/Migration.
But then make sure to use the configuration files provided with the armtix-ROOTFS instead those explained in the Wiki !)
The core-system in this state took less than 80Mb RAM. Of course with much of the daemons disabled, that making a modern desktop usable. But that was for sure a lean base to continue...
It came apparent, that by using runit-init I could spare at least 30Mb RAM and the related overhead without losing any functionality. That alone might to be neglected, but the fact that now I can switch tty's by Ctrl-Alt-FKey in the fraction of a second, and that Ctrl-Alt-Del finishes at once the compositor and does an immediate reboot in the tty, and that a reboot does not hang for about 1:30m for unknown reason is so a refreshing old-scool behavior that I must do a

Armtix-Runit with jgmdev's linux-odroid-511 - check!

Together with the latest mesa, this configuration has proven for me it's stability and usability. It works flawlessly for me since the beginning of February.
I have tweaked around with some other factors, for example tried f2fs and xfs filesystems on emmc and will share my expieriences in another post on another day.

Thats all, folks, thankya!
These users thanked the author mægpie for the post (total 3):
odroid (Thu Feb 18, 2021 10:19 am) • jgmdev (Fri Feb 19, 2021 2:22 pm) • harddroid (Fri Feb 19, 2021 9:30 pm)

jgmdev
Posts: 322
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, N2+, C4, HC4
Has thanked: 130 times
Been thanked: 234 times
Contact:

Re: My rice'd up N2Plus

Post by jgmdev »

mægpie wrote:
Thu Feb 18, 2021 6:00 am
... and that a reboot does not hang for about 1:30m for unknown reason is so a refreshing old-scool behavior that I must do a
That detail alone got my interest on trying armtix :D. I too wonder why sometimes the reboot doesn't works as it should (especially when trying to reboot from a Gnome session). I should learn to read the system logs with journalctl to see if I can find the cause of the problematic reboots. Maybe some one already knows the cause.

mad_ady
Posts: 9250
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 599 times
Been thanked: 622 times
Contact:

Re: My rice'd up N2Plus

Post by mad_ady »

The default systemd timeouts can be safely lowered globally to 10s for instance, though networking has a "hardcoded" timeout that needs to be edited too.
I think the reason for such big timeouts is to allow network-based filesystems to fully sync before network outage
These users thanked the author mad_ady for the post (total 2):
mægpie (Sun Feb 21, 2021 1:26 pm) • jgmdev (Wed Feb 24, 2021 6:28 pm)

User avatar
mægpie
Posts: 13
Joined: Mon Feb 15, 2021 3:00 pm
languages_spoken: english,german
ODROIDs: Odroid-N2plus
Has thanked: 12 times
Been thanked: 15 times
Contact:

Re: My rice'd up N2Plus

Post by mægpie »

mad_ady wrote:
Fri Feb 19, 2021 2:55 pm
... I think the reason for such big timeouts is to allow network-based filesystems to fully sync before network outage
Thanks for the explanation. :)
But these delayed shutdowns/reboots happened also with my former x86_64-device, without any running network-sharing daemon. The only way to get rid of it was to completely disable hardware watchdog modules (ITco_watchdog((?)) in my case).

Beside that SystemD always felt like a blackbox in my system anyway - a fixed part, very monolithic, hard to configure and write .service files for.
It may be convenient for normal desktop use, but there's a reason it isn't commonly used to init embedded systems nor legacy HTPC's or anything that - it IS bulky and by default a overkill of functionality and overhead - at least for ES and SBC's.
Sure nothing that the N2+ couldn't handle, but I looked for the leanest solution and I think that we all agree that the N2+- beside it's capability's - is a computer and a architecture that benefits of every spared CPU-cycle and kB RAM whatsoever ...
jgmdev wrote:
Fri Feb 19, 2021 2:26 pm
... That detail alone got my interest on trying armtix ...
I highly recommend you to do so... (BTW - Very much thanks for hosting archdroid-repo! If I can do anything to support you please dont' hesitate to PM me... :D )

Enough for init-systems - in the end it's a matter of freedom and personal choice& preference...
As far as I am concerned - I migrated all my machines to runit in the meanwhile... :mrgreen:

I think I should explain my technical background and expertice here to make my viewpoints more clear:
I am no developer or skilled maker as most of the community here. I can read well documented code in most lang and have a aproximate idea of what this code does and how I can change It to suit my needs. I (normally) do no soldering in my freetime - except when fixing the controller board of our dishwasher once again...
In a former live I was a freelancer, offering Illustrations, Pre-Print-Design and Interface-Design services.
I used to do my Designs on a WindowsXP machine, and the Update to SP2 lead to data loss of several hundred hours worktime and the data of two actual assignment with very near deadlines.
That painful (and expensive) experience lead me to think-over my Backup behaviour - and to leave Windows in favour of Linux. These day's my colleagues looked at me in disbelief - it was beyond their imagination that one could do Pre-Print Graphics on any other machine than an Apple.
But I sticked to Linux until today and proved them the opposite. So I think I have a relatively profound knowledge of Linux in total, Archlinux in special, and the surrounding Open-Source "ecosystem".

As an designer, I don't care so much about absolute amounts, The subjective impression, the "look-and-feel" and the conceptional design are more important to me;
I think that the human perception is capable to judge wich solutions works better in total - even when the difference are just a few steps in a given color-room or faster execution of a few milliseconds. Benchmarks are instruments of second choice for me to identify bottlenecks or prove my perceptions.

So take my claims here with a grain of salt - although most of them are evident, or otherwise proven. I will post numerical evidence or sources when available.

So stay tuned, as I am not at the end annoying the fellow community here with the further optimizations I made to my Odroid-N2 and it's rice .... Later this dayI will post about my experiences and choices of a displaymanager, filesystem, some coreutils and login-shell... CY!
These users thanked the author mægpie for the post:
jgmdev (Sun Feb 21, 2021 6:00 pm)

User avatar
mægpie
Posts: 13
Joined: Mon Feb 15, 2021 3:00 pm
languages_spoken: english,german
ODROIDs: Odroid-N2plus
Has thanked: 12 times
Been thanked: 15 times
Contact:

Re: My rice'd up N2Plus

Post by mægpie »

The next station of my optimization efforts were related to the Displaymanager.
I wanted to avoid a redundant Xserver or Wayland-Client running in the background, so I looked for tty-based displaymanagers. There are a amount of them, but just a few support wayland-sessions.
These werde the ones i considered suitable for the premise and stable enough to use :
  • Greetd - optional with tuigreeter
    I can confirm it works fine with systemd and runit. Havn't dived deep into it, because I finally chose another solution. Written in Rust.
  • Ly - so far my favourite displaymanager, although you can expect minor bugs. Very minimal and absolutely beautiful !!! Offers the possibility to start .xinitrc or any shellscript at login by default. Mainly written in plain C.
    But at the time I tested it It showed unbearable display flickering, that made it unuseable on the Odroid. I don't know if it was because the buggy state of the panfrost driver at this time, or if it just doesn't play well with runit or the aarch64 architecture. If someone is willing to make further tries on runit-based systems : The voidlinux PKGREPO provides service-files for runit and here are the service-files I experimented with to no success.
  • EmpTTY - The DM of my choice now. Works flawlessly on systemd, runit and openrc, including autologin. Provides uncomparable customization options with a sane default. Choice of session appears in a numerical list after login. Written in Go.
    When compiling it for another init make sure to change make flag from "... install-systemd" to "... install-runit" or "... install-openrc" f.e. in the AUR PKGBUILD.
Emptty - check!

The next post will cover my experiences with several root-filesystems on emmc...
These users thanked the author mægpie for the post:
jgmdev (Wed Feb 24, 2021 6:33 pm)

User avatar
mægpie
Posts: 13
Joined: Mon Feb 15, 2021 3:00 pm
languages_spoken: english,german
ODROIDs: Odroid-N2plus
Has thanked: 12 times
Been thanked: 15 times
Contact:

Re: My rice'd up N2Plus

Post by mægpie »

As for the filesystems :

I have always used ext4 without scrutinizing this choice very much.
It has always done what's supposed to do, and has kept the integrity of my data for more than 10 years on some HDD's now.
Although they had to take some serious hardships in my hands... :oops:
That's amazing and all you can ask for an filesystem for the average user.

But recently - I'd say sometime after 5.0 Kernel ... - I realized some strange behaviours of my ext4-formated storage devices :
First, the typical noise of my HDD's heads suddenly changed. They were louder and more often in motion. There are some very old HDD's among my storage so I did the usual HDD integrity tests with no result, fsck'd several times and nothing changed. So i ignored that for the time being.
But the second issue was very annoying : Whenever i copied a amount of data large enough, let's say more than 4GB on any ext4 formated drive, whether USB-Sticks, SSD's or HDD's, the syncing and unmounting of these storages took ages!!!
On the SSD's this issue was not so prominent, but for a USB-Stick copied ~12GB over, It took more than 45Min. to sync and unmount and on another HDD, copied over ~700GB, at least 1 and a half hour. Interrupting the process and unclean unmount resulted in just partly synced data and data loss.
This was reproduceable with the same drive on the Intel-Machine and on the Odroid, too.
The same drive, xfs-formated, synced and unmounted nearly at once - ext4-formated it took ages to unmount again. And in addition all xfs-formated HDD's are completely silent again...(?!?!)

I have'nt researched further since. I wonder, if someone has experienced such an issue, too?

That was the reason for me to took the time to experiment with and research about alternative filesystems. This very interesting Phoronix-Article was my source for an overview what to expect:
Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS
I can confirm the end-results of this benchmark beside Btrfs, whereby I have no practical experience with.Some personal experiences and additions:
  • Both, XFS and F2FS are complete uncomplicated to boot into on emmc of my Odroid-N2+, running linux-odroid-5.11.0 and uboot-2015.01.171-1. A f2fs-root seemingly requires a

    Code: Select all

     rootfstype=f2fs
    Kernel argument. Don't forget to update the /etc/fstab.
  • Both filesystems are performing great, on emmc and microSD, BUT
  • Although I am on a f2fs root atm, there are some, to be honest a lot serious disadvantages and risks in using it on the Odroid-N2 Plus:
    This filesystem seems very vunerable to data loss/filesystem corruption by sudden poweroffs: A major drawback on still experimentally supported boards as the Odroid-N2 / S922X, where a poweroff sometimes is inavoidable. Your should consider that when you entrust your data to such a filesystem on such a device.
    Sometimes, the fsck-hook does'nt repair the filesystem and

    Code: Select all

    dump.f2fs /dev/mmcblk1p1
    shows a sudden-poweroff after several reboots. In this case add a

    Code: Select all

    fsck.mode=force
    to the kernel commandline.
    And make sure to remove the kernel argument after that again:
    Otherwise you will notice soon, that fsck.f2fs can remarkable slow down your boot. I have a 1TB SanDisk Extreme microSDXC in the SD-Card slot, f2fs-formated, mounted as /home and after big data transfers it took occasionally 1:30m for the system to begin to boot after a fsck.
    And the last disadvantage of a f2fs-rootfilesystem is that (please dont force me to prove that...) compiling binaries and the execution of several python- and bashscripts is remarkably delayed and slower on this filesystem. Don't ask me why, when you use for example trizen to make a AUR package the PKGBUILD-parsing is soooooo slow. I dont think that appearance is deceptive.
    This affects the user experience very much on a system like ALARM where you often belong to compiling your binaries or especially if you are developing.
    I will stick to F2FS whatsoever - I am tired of component hopping... and all in all it performs very well on my rel stable system.
    One interesting feature of F2FS i want to mention finally here : It seems, that f2fs-filesystems supports on-the-fly encryption of folders and files on a unencrypted partition: Nice to have.
    See : F2FS File-based encryption support
  • I reformated my HDD's to XFS.
    Copying the same chunk of ~700GB / ~14000 mediafiles to the same Samsung Black HDD (I cant look for the Model atm.) over a USB3-Dockingstation took on the ext4 filesystem 3:28 hrs.
    On the XFS filesystem the whole transfer took 2:36.
    XFS as a rootfs may have some pitfalls that I am not aware of, because I ran it just for a short test period unlike my current install on F2FS
As a conclusion I can encourage you to try out ext4-alternatives to optimize your user-experience with the Odroid-N2(+). It seems that the last year has changed a lot in the linux-filesystem landscape...

Next Post will be about some coreutils alternatives and my choice of the login-shell.

Until then... BB

EDIT: Added link

User avatar
mægpie
Posts: 13
Joined: Mon Feb 15, 2021 3:00 pm
languages_spoken: english,german
ODROIDs: Odroid-N2plus
Has thanked: 12 times
Been thanked: 15 times
Contact:

Re: My rice'd up N2Plus

Post by mægpie »

Next stage in setting up a lean system on my Odroid-N2Plus involved the choice of a login-shell and terminal-emulator.
And these both turned out to be REAL GEMS of open-source software... I highly recommend everyone to try them out !

Regarding to the terminal-emulator: I wanted it lean, Wayland native and of course stable and performant.
My choice fell on foot.
The community around lead-developer Daniel Eklöf has accomplished to develop a wayland-native terminal-emulator with minimal dependecies in less than a year, that easily outperforms every other alternatives I tried so far by worlds apart!
It has seen it's first stable release just one week ago, so it's a really hot-baked project, that deserves all attention it can only receive.
Foot renders fonts perfect at whatever resolution, has on-the-fly DPI font size adjustment and native sixel-graphics support in terminal, dozens of additional features, and is very well documented with a kind and responsive developer-community.
Originally I chose Foot-Terminal because it supports a Server-Client model, that help to reduce overhead to an minimum when you like a terminal-based workflow.
Most other terminals are starting additional instances with every terminal window opened, what sums up to a not negligible overhead of RAM and CPU. Foot avoids that effectively by its Server-Client model.
Please forgive me all the bold typography and excitement - but I am sure you will share my enthusiasm when you try "foot" out!

So - Foot-Terminal - check!

As for the login-shell: I know that this choice I made isn't suitable for everyone and that it might perceived questionable to the average Linux user:
First I must confess here that I am a bash-hater: Yes, I hate bash.
The shell concept of unixoid OS's is so mighty and original, but bash - with it's counterintuitive syntax and dependency on external tools to do the job it's build for - has always hindered me to gain full control over my system.
Your are free to laugh at me for this position, but please consider that I am not a developer, I am just a user and designer that firmly believes in the KISS principle. Not in regard to software development, of course. It's an concept that is known in design theory too, albeit under other labels.
And bash for sure doesn't fit that label - simple.

But fortunately there are alternatives in the Open-Source world: Fish, zsh, ksh and you name it...
The Ion-Shell was my first try, and I have never felt the need to look further.
The developers claim, that the Ion-Shell ist the most performant shell atm., if you make use of it's internal functions. I can't confirm or deny that. For sure it's far more performant than bash.
But what I can confirm is the conceptual beauty and simplicity of its syntax.
This shell has brought me to begin scripting again, and I have written several scripts since then without any obstacles or problems, that weren't covered in the documentation. Work-in-progress bashscripts, that I was never capable of finishing, were translated and completed 'en passant'.

Ion originated as the default login-shell of RedoxOS, an operating system project completely written in Rust, that also has passed a milestone at the beginning of 2021 : It is now self-hosted and can now be considered a original OS, without any external dependencies. Hence Ion ist written in pure Rust, too.
And it fits so well on a Linux system - whaddapitty that it can't replace also linux-native system-shells ...

Ion-Shell - check!

We are near the end of this extensive presentation of the system i pieced up, and I hope you have the patience to notice my last post, covering coreutil-alternatives and possibly some cosmetics.
Then I can close this project, and enjoy my riced up, completely silent Odroid-N2+. 8-)

Have a good time and stay healthy until then...

EDIT: Typo

mad_ady
Posts: 9250
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 599 times
Been thanked: 622 times
Contact:

Re: My rice'd up N2Plus

Post by mad_ady »

I've stayed with bash for 22 years not because it's nice (I still have to look up syntax when writing shell scripts), but because it's everywhere. I mostly ssh into old servers anyway all day long, so using a different shell on my PC would lead to confusion...

Post Reply

Return to “Projects”

Who is online

Users browsing this forum: woodyl and 1 guest