Making VirtualBox Guest Addition for Fatdog64, the easy way

The articles I have written in in my archives usually are generic ones. But today I am inspired to write one specifically for Fatdog64, so here it is. Enjoy.

Posted on 5 Apr 2015, 04:18 - Categories: Fatdog64 Linux
Comments - Edit - Delete

Fatdog64 700 on Acer Iconia W500

Micko, also known by his nickname 01micko in the Puppy Linux Forum), managed to install Fatdog64 700 on Acer Iconia tablet W500 and got it to run quite smoothly. Here is his original announcement with pictures, and here is his step-by-step instructions to do.

Thanks Mick!

In case you wonder who Micko is: he is the prolific developer of Puppy Linux Slacko (the official Puppy Linux releases based on Slackware) - and has been holding the the torch for a couple of years now. He is also the co-maintainer of Woof-CE, the build system for Puppy Linux; as well several small desktop utilities. His latest work, Puppy Slacko6 beta is what gets re-packaged as 32-bit compatibility library package for Fatdog64.

He took a break for a few months but has just recently come back and we hope he will stay for a while

Mick has a blog here.

Posted on 3 Apr 2015, 5:07 - Categories: Fatdog64 Linux
Comments - Edit - Delete

FatdogArm on Nexus 7

A kind gentleman who prefers to remain anonymous gave me an Asus Nexus 7 2012 ("grouper") last year so that I could put FatdogArm on it. Due to various circumstances, I was not able to look into it until very recently.

The same gentleman informed me that most of the works should have been done since Ubuntu team has managed to boot Ubuntu on it as early as 2013, and there was a development called Multirom that enables dual/multi-booting of various OS on Nexus 7, making it even more convenient.

Well, I was late to the game, but late is better than never. I finally had the chance to try to get it going. The Nexus 7 given to me was in a pristine condition, stock firmware, not rooted. So I upgraded it to Android Lollipop 5.1, rooted it, installed Multirom on it (manually). Perhaps I will write the steps a little later.
Then I grabbed Ubuntu Nexus 7 kernel and modified it for FatdogArm, and after some little tinkering, here is an image.

Framebuffer, framebuffer console, wifi, sound, touchscreen, USB-OTG all works thanks to Ubuntu hardwork of porting mainline kernel to support Nexus 7. I have not tested other devices (accelerometer, camera, compass, etc).

It is still early days but I hope I can upload a beta3 version of FatdogArm with basic support for the Nexus 7 (and the recently rebuild SMP kernel for XO-4) soon.

Posted on 1 Apr 2015, 0:59 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Updated 32-bit compatibility SFS

Fatdog64 is a 64-bit operating system so it cannot run 32-bit programs by default. To run 32-bit programs, the kernel must be compiled to support such and 32-bit version of the libraries are needed.

Both have always been provided since Fatdog64 launches back in the day. The 32-bit libraries are compiled together in an SFS called 32bit compatibility library.

Compiling libraries are time consuming (not to mention the testing) and we have our hands full taking care of 64-bit libraries (and ARM for me). So we have always out-sourced the job of making 32-bit libraries to someone else: instead, we usually take an existing, known good, and widely used version of Puppy Linux and re-package it.

The very first version of 32bit compatibility (for Fatdog64 500 series) was based on Puppy Linux Wary 5.0. The second version of 32bit libraries (for Fatdog64 600 series) was based on Puppy Linux Slacko 5.3.1, and for a while this was the only available 32-bit libraries for Fatdog64 700 too.

I have just compiled a new 32bit compatibility library based on Puppy Linux Slacko 6 beta (5.9.3), accounting for a new directory layout in Fatdog64 700 which has a clean separation between 64-bit and 32-bit libraries. All 32-bit libraries now lives in /lib and /usr/lib, as it shoud be (in 600 series this was still a bit mixed, forcing us to use /lib32 and /usr/lib32 instead). The non-shared configuration still lives in /etc32, and a "start32" is still provided for compatibility purposes.

The name of the new 32bit library is 32bit-slacko6.sfs and it is available from ibiblio and its mirrors with immediate effect.

Posted on 1 Apr 2015, 1:01 - Categories: Fatdog64 Linux
Comments - Edit - Delete

SMP-enabled kernel for OLPC XO-4

I had known even before I received the laptop over a year ago that the Marvell Armada PXA2128 Soc used in XO-4 featured a dual-core CPU, but for some reason the kernel didn't support that.

I recently got tipped by forum member mavrothal, my partner in development of FatdogArm for the OLPC, that the OLPC kernel for XO-4 finally got dual-core capability, who had built the latest git master from the kernel and got SMP kernel working.

I didn't have the time back then, but yesterday I finally got the chance to play with it. I built the kernel myself too, and I needed to update the OFW firmware to at least q7c04 for the dual-core kernel to run, but everything is smooth - new kernel booted and worked flawlessly with both cores enabled. All the existing functionalities continue to work, but the rc.platform will require a little patch because the ID code that I used to identify XO-4 has changed.

I will upload the new kernel, with update instructions (mainly pointing back to OLPC on how to update the firmware etc), and a new FatdogArm sfs with the required rc.platform change.

It has been a long time since the last FatdogArm beta2 release, so I may as well update some of the other packages too and call it beta3. Watch this space for further announcement.

After updating the OLPC firmware, the old original Fedora/Sugar in XO-4 will stop running. The fix is to download a newer build of the OS and install it to the laptop.

I need to say that I continue to be impressed and amazed of how OLPC implements these processes (both updating firmware and updating the internal OS). They are simple, easy, foolproof and very informative.

This is a far cry from similar processes of other commercial offerings. Especially since I had to deal with UEFI recently - if only UEFI implements half of what OLPC does with its Open Firmware, it would have been immensely more useful. Something's got to be better than BIOS, but UEFI isn't the one - OpenFirmware certainly is.

I applaud the engineering that went into the design and implementation of these features. There must have been a lot of thinking, and a lot of effort to examine of how the processes on standard PC broke down or failed in one way or another - and they made it really better.

This is of course on top of other excellent features of OLPC laptop - and I don't even mean the advertised educational benefits - but things like physical robustness, ease of maintenance, quality selection and durability of its components. Sure, this does not make it the lowest cost laptop (or even a lower cost tablet), but quality has its price and an investment of an OLPC laptop will far out-weight its cost and last far longer than any other laptops (or tablets) designed for similar purposes.

Personal note - I still think that a laptop is a far more useful for education than a tablet, regardless of the recent fad. If you are a decision maker and considering to get some sort of tablets or OLPC laptops, I'd highly recommend you go with OLPC XO-4. As a bonus, an XO-4 with touch screen (XO-4 touch) can function as a tablet too - just flip its screen. That is how versatile it is.

Disclaimer: I am saying all the above not because I am affiliated with OLPC (the only indirect relationship I have with OLPC is that I am doing a non-commercial community project for the OLPC XOs - that is, FatdogArm). I really like the OLPC laptop, I really like OLPC mission, and I really wish and hopeful that OLPC as an organisation will succeed and continue to focus on these quality offerings.

Posted on 28 Mar 2015, 19:30 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Dual-boot Windows/Linux on Sony laptop with UEFI and Secure Boot

I haven't written an article for a very long time, so here is one: Dual-boot Windows/Linux on Sony laptop with UEFI and Secure Boot

Posted on 26 Mar 2015, 16:55 - Categories: Fatdog64 Linux
Comments - Edit - Delete

xannonate/xscreenshot updated

Minor update to xannotate/xscreenshot: the hotkey can now be given in either symbolic form (e.g. "Print") or in numeric form (107). This is necessary because sometimes the same key name (e.g. Print) can have multiple key codes (e.g. 107, 218); and hotkey selection inside X works based on keycodes. I found this out because the "Print" button on my (newish) laptop doesn't work; it turns out that this particular laptop dish out 218 for the Print button; while the standard mapping is 107 (which gets used), so as far as the program is concerned it never gets triggered.

As a convenience, if you give it a numeric keycode, it will try to find the other standard keycode that represents the same key, and grab it too.

Posted on 1 Mar 2015, 15:39 - Categories: Linux General
Comments - Edit - Delete

Fatdog64 700 is released

Linux 3.18.7 and many enhancements and bug fixes over the 700rc release.

Release notes
Forum announcement

Get it as usual from ibiblio or one of its mirrors: aarnet,, and

Posted on 25 Feb 2015, 3:10 - Categories: Fatdog64 Linux
Comments - Edit - Delete

Fatdog64 700rc Release

Linux 3.18.6, Seamonkey 2.32, flash player and other bug fixes.

Release notes
Forum announcement

Get it as usual from ibiblio or one of its mirrors: aarnet,, and

Posted on 13 Feb 2015, 4:13 - Categories: Fatdog64 Linux
Comments - Edit - Delete

Maximum size of initramfs

Well, I'm still around .

Just want to document this often asked problem: what is the maximum size allowed, for an initramfs? Obviously this will be related to how much RAM you have, but what is exactly the relationship?

I have answered the question here, but I didn't explain why the numbers are what they are. This post attempts to correct that, if you're interested.

When considering this question, there are two things to remember:
a) initramfs will be uncompressed to memory during boot-up, so the amount of RAM needed would be the size of the initial initramfs + size of uncompressed initramfs
b) how much RAM the kernel will want to allocate for holding initramfs.
For the system to successfully boot, (a) must be the same or less than (b).

(a) is easy - by rule of thumb, it is twice the uncompressed size of initramfs. It is exact for uncompressed initramfs, and approximate for compressed initramfs; in either way it will give you the upper bound.

(b) is a bit more complicated. Traditionally the kernel will use "ramfs" for initramfs (that's why it is called init-ramfs ... ), and it will happily allocate all of your RAM for it, which is unwise, so you should at least subtract about 0.5GB from your RAM size if you want a usable system (unless your idea of fun is dealing with kernel OOM-killer that kills your important system services right after boot - not me).

But somewhere around kernel 3.x (circa 2012), the kernel merged "inittmpfs" patch from Rob Landley (of busybox and toybox and aboriginal Linux fame). It means that from that day onwards, initramfs will use "tmpfs" as opposed to "ramfs" by default (you can still switch back to using ramfs by specifying "rootfstype=ramfs" on your kernel command line). In case you're not familiar with the difference, "tmpfs" is "ramfs" with a size-limit (among others); and by default the limit is 50% of your RAM.

But wait, you say, doesn't "tmpfs" come with knobs to specify the maximum size? Yes, it does, but not at boot-time, no. Sure, you can re-mount it and changes it size, but we're talking here the situation during initramfs loading, *before* any code in initramfs itself is started ...

Rob actually has a patch to do exactly this, using "rootfsflags", but don't count on it going to mainline kernel soon.

But I digress. So, to come back to the subject, with "ramfs" you get all of your RAM (minus your 0.5GB), and with "inittmpfs" you get 50% of your RAM. This is (b). And since (a) is twice the size of your initramfs, it means that the maximum allowable size of your initramfs is 1/2 of (b).

Which means, if you use "inittmpfs" (which is the default in modern kernels), your initramfs size is limited to 1/2 of 50% of your RAM, or 25% of your RAM. If you use "ramfs" by specifying "rootfstype=ramfs" in your kernel boot command line, when this limit can increase to 1/2 of your RAM (minus 0.5GB), or, about 40%-45% of your RAM (depending on how big it is). Q.E.D.

Posted on 5 Feb 2015, 5:46 - Categories: Linux General
Comments - Edit - Delete

Pages: ... [6] [7] [8] [9] [10] [11] ...