Any interests in Kernel 4.0 on My book live?


In the original MBL, the disk partition layout is as follows:

  • sda1: ext2 root/boot filesystem (defined as volume 1 in soft raid group)
  • sda2: ext2 root/boot filesystem (defined as volume 2 in soft raid group)
  • sda3: swap space
  • sda4: ext4 filesystem for user shares

So if you kept the original disk layout, swap space is on sda3. If so, put this in /etc/fstab

/dev/sda3 swap swap defaults 0 0

and execute: swapon -a and verify with swapon -v



My disk is not original, I use Toshiba 6Tb Nas disk.

With 4.9x kernel it run well, but with 4.19 kernel don’t find swap partition.

My fstab is like this:

/dev/sda1 / ext3 defaults,noatime,nodiratime,barrier=1 0 0
/dev/sda2 swap swap defaults 0 0
/dev/sda3 /DataVolume ext4 exec,rw,noatime,nodiratime,data=writeba$
/DataVolume/cache /CacheVolume none defaults,bind 0 0
/DataVolume/shares /shares none defaults,bind 0 0
/DataVolume/shares /nfs none defaults,bind 0 0

And fdisk -l:

Disk identifier: F7833EA7-3BBF-9240-B669-8B7B7CB16BD3

Device Start End Sectors Size Type
/dev/sda1 2048 20973567 20971520 10G Linux filesystem
/dev/sda2 20973568 23070719 2097152 1G Linux swap
/dev/sda3 23070720 11721045134 11697974415 5,5T Linux filesystem


Kernel 4.9.x has 64KB page size, while 4.19.x has 16KB page size (for now) due to a defect in the kernel which I have not fixed yet. Hence, you need to re-initialize swap space to match the new page size.

mkswap /dev/sda2

Sorry for the confusion and time lost. I will make sure to update the readme’s on the GitHub.


No problem, I fun with test an error :slight_smile:

Someone has tried with btrfs of XFS filesystems?

I test both with 4.9.161 and I not sure that de cpu have problem to move. The options would be many with BTRFS on this device.



Jessie powerpc repository no longer works :frowning:
Any other opcion?

there were no updates, but at least keep the repository

Best regards


Debian move the repository to archive. It works with new sources.list:

deb jessie main contrib non-free


You are free to test btrfs and XFS, can’t see why they would not work I have been tracking the performance of these file systems, but so far concluded that for our older HW and mostly SATA drives, EXT4 delivers the best overall and, above all, consistent/predictable performance. Also, you can read your EXT4 drive on Linux/Windows in case something goes wrong.
Take a look here. XFS and F2FS are becoming solid alternatives, but btrfs not there yet IMHO for general purpose use.

My bigger worry though is that more recent versions of Linux seem to waste more CPU cycles in low level code like block/BIO drivers which are used by all file systems. Lots of constructs with x calling _x, calling __x etc, often not inlined and sometimes at each level the parameters are being validated again or a BUG statement is inserted.
On a quad core Intel/AMD that is no big deal, but on older HW this can be quite costly.


High performance kernel 4.19.29 for evaluation:here

As promised, an attempt to fine tune the performance of kernel 4.19 and port some tuning work from earlier versions to 4.19. This kernel has not gone through full torture test, nor is it available in source/patch format (yet). The goal is to get some feedback of whether any of you are seeing improved results and good stability.
Compared to standard OpenWRT kernel, this kernel should deliver ~70% performance increase on Samba write (~80 MB/s sustained) and 20% on Samba read (~112 MB/s read). It should give around 5 to 10% improvement over 4.19.24.
The biggest issue is that I’m unable to achieve the 170MB/s file system read that was giving me on the same drive, not with the dwc_460ex driver, nor with the sata_dwc_nqc driver. Somewhere ATA/SCSI code has slowed down, but I can’t seem to find where.
Unfortunately, there is limited “perf” tracing support for ppc_4xx hardware in the kernel, despite good HW support for PMU and tracing. Maybe write a performance counter driver… Not easy with just net console…


High performance kernel 4.19.33 with patch set to compile your own kernel : here .

Samba read improved to 115MB/s and writes at 82 MB/s. Patches updated for 4.19.34 validated, but it’s a bit slower due to some code changes.
First builds of 4.20 look promising, lots of kernel cleanup and some tests run 20% faster.


i am following guide to update my WDL but i am stuck at “debootstrap --arch powerpc jessie /newsys/
/usr/share/debootstrap/functions: line 1591: cannot create temp file for here-document: No space left on device” can someone help me?


@majorshock try googling the error


Is it possible to compile version 2.6.32 kernel source from RHEL with patch for WD MBL?
RHEL Source
I think that this version contains backported patches and should be more safe. Is this correct?



@majorshock, haven’t done the full install for a long time but never saw this error. An additional challenge is that Debian Jessie is no longer supported on PowerPC 32. Install from scratch is a long and painful process and leaves you with an unpatched version since Debian shut down the security patches depot. Then you will have to struggle through dependency nightmare to e.g install GCC 8.3 or 7.4 if you want to compile a kernel. That is why I made a pre-patched Debian 8.11 available on the github page (


Not sure I fully understand the question… Yes, given the proper PowerPC 32 cross compiler and version (e.g. 7.4 or 8.3) you can take the official kernel source, apply the patch set posted on my github and cross compile a kernel. Running RHEL on my book live is a quite another challenge, which is not worth the effort IMHO. Hopefully that answers your question.


Hi Ewald,

Thanks formulier your answer! You understood me correct! So you think it must possible to cross compile the kernel. Do you think there is any advantage in doning this? An perhaps also for the 4.1 kernel?




No run-time performance advantage in cross compiling as you are using the same gcc compiler (e.g. 7.4 or 8.3). Massive difference in compile time though. On a 16-core Intel CPU and NVRAM drive I was able to do a full build in under 12 seconds (make -j 24) ! It easily takes 2 hours on the MBL, … if it even finishes the build. I had to debug the gcc linker for 7.4 since it kept crashing with Out of Memory error or getting killed by OOM Killer. I have posted a section on cross compiling. Practically I only build loadable kernel modules locally on the MBL. Those complete in just a few seconds with no need to relink the kernel.
If you can share your experience on compiling on RHEL, I am happy to add your installation steps to the README on GitHub. So far I only used/documented Debian/Ubuntu/Linux Mint.
Hope this helps.


Glad to see great work have been done to this little machine. Debian still has powperpc port available with very updated packages. You can make clean installation with debootstrap, the problem and quirk is mentioned here:


Latest qualified kernels: 4.9.169 and 4.19.44 on github.
Patches updated for 4.19.44. Stress tests for these kernels are currently in progress.
Open issues: disk activity led for 4.19 kernels