KoBox, or how to run X.org and Firefox on your Kobo

[pazos]

Originally Posted by NiMa

Update:
KoBox is on a big overhaul now. After extensive testing on a Kobo Mini, it seems that the latest version (3.13) of the minirootfs segfaults BusyBox each time (probably due to kernel version) I try to run a command and therefore it is unusable.
To extend support to these devices, we've decided with @fermino and @Elektron to build a new rootfs from scratch, with custom (and natively!) built musl-libc and BusyBox so that it can run fine on the Kobo Mini (and probably Touch and Glo).

Also, I (and maybe others) will compile custom apk packages with optimized support for each device (yeah, we won't leave our Kobos sleeping at night )

Distribution images would be provided for each device, containing the optimized binaries and musl-libc/BusyBox. It will still include Xorg, a web browser and maybe some utilities (though the web browser may take some time to compile natively )
I'll also write a bootstrap script to build them automatically.
We could have went to the cross-compile route, but as BusyBox worked only when compiling it natively on the Mini, I'm not sure that it will work for other packages...

So if you have a Kobo, knowledge about Linux and compiling from source and would be willing to spent some hours sometimes building packages, you're welcome to do so!
We've created a GitHub organization here: https://github.com/Alpine-KoBox
And if it is possible for you, please join us over at Discord: https://discord.gg/FTAMN8wP6d in the Kobo Devs' corner.

Most of the stuff you're planing to do is useless. All kobos from Kobo Touch onwards (with fw: > 2) share the same ABI: armhf, which is already supported by alpine.

About building them natively instead of cross compiling: it is painfully slow and won't work for huge packages. The build system will require a few GB of RAM available to build them and will start to swap to disk a LOT wearing your internal storage or just go OOM if there's no swap enabled.

Building packages natively won't help to make them work if that's happen because a specific kernel in a specific FW for a specific device lacks a feature, like devtmpfs, that your rootfs is going to use.

My suggestion: update your Mini FW to latest tested version (4.x). It should have a "modern" kernel with features on par with other boards. Busybox shouldn't segfault there.

[pazos]

Originally Posted by NiMa

Then you're out of luck, like me :/
Now anything based on QtWebEngine won't work on your Aura H2O v2 and my Libra (i.e. chromium) so we're stuck with WebKitGTK
... or the buggy Gecko engine

If anyone has even an idea on how to solve this problem, please do say it!

( to be honest, webkitgtk is garbage on such a slow processor... believe me, when you've seen the performance of Falkon you can't even describe the slowness of Midori... )


and for touch, maybe I'll contact you on Discord for some tests. that could help me really know what to do.

Chromium/QtWebengine needs an OpenGl context to draw. You don't have one. On x86 it is possible to use a software renderer, like llvmpipe, without the user noticing it too much. Not possible on arm. You can still use a sw render but it will be as gargabe or more garbageish as webkitgtk.

If you want to try that use the package https://pkgs.alpinelinux.org/package...sa-dri-gallium, which contains the mesa swrast driver.

But seriously try netsurf or surf before. It will make the experience much less garbage

[NiMa]

Originally Posted by pazos

Most of the stuff you're planing to do is useless. All kobos from Kobo Touch onwards (with fw: > 2) share the same ABI: armhf, which is already supported by alpine.

About building them natively instead of cross compiling: it is painfully slow and won't work for huge packages. The build system will require a few GB of RAM available to build them and will start to swap to disk a LOT wearing your internal storage or just go OOM if there's no swap enabled.

Building packages natively won't help to make them work if that's happen because a specific kernel in a specific FW for a specific device lacks a feature, like devtmpfs, that your rootfs is going to use.

My suggestion: update your Mini FW to latest tested version (4.x). It should have a "modern" kernel with features on par with other boards. Busybox shouldn't segfault there.

I've already considered all of this stuff, upgraded my Mini and all, but the update doesn't bump the kernel, which is stuck at 2.6.35.3.
Building latest BusyBox doesn't cause a segfault when the natively-compiled version is run, and I wrote a bootstrap script (https://github.com/Alpine-KoBox/bootstrap) that permits you to do it right on your device, unattended.

For QtWebKit/Engine, strangely it works on some devices (like the Mini and the Glo HD) but fails on other devices (like Libra or Aura H2Ov2), probably due to the kernel version. As you can see here (https://www.youtube.com/watch?v=RsWvQx4QAEY), Falkon had no problem rendering a YouTube video on my Glo HD.
Any clue why? thanks

Also related to cross-compiling, I might shift to that for larger packages (like GCC), but most of the development (when possible) will be done directly on the device for optimization/compatibility reasons.
but thanks for your advice!

p.s.: I've tried NetSurf on my main Linux PC and it doesn't keep up with the current standards, making it difficult to display modern webpages.

[Elektron]

So what are the instructions to install it on the Mini? I'm not familiar with the term "bootstrap", sorry

[NiMa]

Originally Posted by Elektron

So what are the instructions to install it on the Mini? I'm not familiar with the term "bootstrap", sorry

Look at the README, it explains it all

[Elektron]

Can I bootstrap from the vlasovsoft console? I don't currently have a way to SSH/telnet to my eReader.

[NiMa]

Originally Posted by Elektron

Can I bootstrap from the vlasovsoft console? I don't currently have a way to SSH/telnet to my eReader.

yeah, it should be possible.
But this will only install a core base system, you won't be able to do much with it for now, until I (or you) compile the packages for the device
there's always apk.static, but I can't guarantee it will work for you

[Elektron]

Originally Posted by NiMa

https://discord.gg/FTAMN8wP6d

Just clarifying, did you configure the link correctly? Invites can expire after a few days if you don't configure them

[NiMa]

Originally Posted by Elektron

Just clarifying, did you configure the link correctly? Invites can expire after a few days if you don't configure them

yes, all good

[Elektron]

Just realized I can't connect to WiFi so no bootstrapping at school
Ah well, gonna wait. Just over 2 hours left...

[NiMa]

Originally Posted by Elektron

Just realized I can't connect to WiFi so no bootstrapping at school
Ah well, gonna wait. Just over 2 hours left...

but how do you access MR then?

[Elektron]

Originally Posted by NiMa

but how do you access MR then?

Chromebook. Kobo isnt connected.

Leaving!!

[NiMa]

Originally Posted by Elektron

Chromebook. Kobo isnt connected.

Leaving!!

Good! But if you can access MR, why couldn't you access Discord? There's a web app too...
or is it banned from your school's network?

[Elektron]

Originally Posted by NiMa

or is it banned from your school's network?

Yup, haha.

[NiMa]

We have moved from GitHub to a self-hosted Gitea instance to allow better control over the storage and a faster uplink for me to commit (on my local network!)

You can find it here: https://alpinekobox.ddns.net

I got a working instance running on a Kobo Glo HD and it could've worked, but the main problem was storage and wear, so I opted for a small thin client instead with a 40GB HDD. This should be enough to build the aports tree for the main repository, and I'll probably upgrade the storage soon.

I'll compile most of the packages on my Raspberry Pi and I'll post scripts to bootstrap a proper minirootfs of self-built Alpine Linux.
You can always help by compiling (on your Kobo, or Raspberry Pi, or with some cross-compiling fairy dust ) other packages from other repositories (I'll publish a guide for that) or come discussing over on Discord.
@fermino proposed to host a mirror website with faster D/L speeds, so we'll set that up soon. (btw, thanks)

Any questions? you can ask them on Discord (see Elektron's signature for the link or one of my previous posts in this thread) or here.