One bootx64.efi to rule them all

Barry recently blogged about gummiboot, which contains an interesting link to a feature of gummiboot that I overlooked previously. Barry linked to a phoronix article, which linked to a blog post from Harald.

TL;DR: gummiboot has a feature to build a single UEFI binary that contains Linux kernel, initrd, and the kernel command line. One UEFI file that contains the entire OS.

Yes, with this, you can have one bootx64.efi (bootloader) that actually contains the entire operating system (kernel, initrd, etc). While the idea is not new - Rob Landley pushed for ability to embed initrd into vmlinuz a long time ago - this is one step even better: embedding into the bootloader!

Why would we even bother? For one thing, it enables you to carry a stick with FAT32 partition in it, and a single file strategically located and named in /EFI/boot/bootx64.efi which contains the entire operating system for recovery and rescue purposes. It also means the return of boot-time virus - this time in the form of boot-loader virus (instead of boot-sector) from the days past if you are not careful.

Another thing is - if you run an embedded system with UEFI bootloader, after your OS are loaded entirely into the RAM, you can happily replace/upgrade your OS ("firmware") in one swop - there are no transactions needed to check if the bootloader update works ok, if the kernel update works okay, if the initrd works okay ... you just replace one file, if that one file update is okay (checkum matches etc) then all is good.

Harald has the code here, but it's somewhat tied to Fedora and systemd. Here is the extracted code that does the actual magic.
#!/bin/sh

echo your kernel cmdline > cmdline.txt
objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline="cmdline.txt" --change-section-vma .cmdline=0x30000 \
--add-section .linux="/path/to/your/vmlinuz" --change-section-vma .linux=0x40000 \
--add-section .initrd="/path/to/your/initrd" --change-section-vma .initrd=0x3000000 \
linuxx64.efi.stub "$1"


The only catch is this - where does this "linuxx64.efi.stub" come from?

This EFI stub is built as part of the gummiboot bootloader. Gummiboot is "obsoleted" as its content are "absorbed" into systemd (and renamed to systemd-boot or something); but the code still exists and still works nicely here: https://cgit.freedesktop.org/gummiboot/ - you just need to checkout one commit before the final one (the final commit deletes everything to persuade people to move to systemd-boot).

I tested this with Fatdog64's initrd, with and without basesfs in it. Without basesfs - I ended up with 61MB bootx64.efi. With basesfs, I ended up with 366MB bootx64.efi. Both works as expected when launched from qemu as long as I have 2GB of RAM or more.



Posted on 19 Apr 2016, 11:09 - Categories: Linux General
2 Comments - Edit - Delete


Fatdog64 FatdogArm double release

FatdogArm Beta4 is released.
Release Notes
Downloads

Fatdog64 710 alpha is released.
Release Notes
Forum announcement
Downloads.

As usual you can find them on ibiblio's mirrors too:
uoc.gr, nluug.nl, aarnet.edu



Posted on 16 Apr 2016, 23:31 - Categories: Fatdog64 FatdogArm Linux
No comments - Edit - Delete


FatdogArm on Odroid-XU4

A kind gentleman who goes by the nickname of "pjf" on Puppy Linux forum gave me an Odroid-XU4 to play with.

As a result, FatdogArm now supports Odroid-XU4. The support is pre-eliminary - it's mainly kernel supports; the usual hardware acceleration stuff aren't supported yet.

The kernel package for Odroid-XU4 (and also XU3 - these two are software-compatible with each other) is here: http://distro.ibiblio.org/fatdog/arm/releases/beta4/kernel-packages/, or on any of ibiblio's mirrors.

This work is still in flux, though, as I'm still tweaking the kernel. It's now my 3rd compile. It may change. And while you can find beta4 SFS there, I haven't really released it and I may still make some changes soon.

Odroid-XU4 is a little machine that could. The SoC is Samsung Exynos 5422. It comes with 8 cores (ARM BIG.little architecture - 4x 2GHz cores, and 4x 1.7GHz cores), *ALL( of which can be run simultaneously under HMP mode.

It is so powerful that:
---
a) I can decode h.264 1080p video and render it to 1080p, with AAC audio, using software only (no hardware acceleration).
b) I can watch youtube using html5, with audio, without any stutter.

I've never been able to do this in my previous board. It is the fastest little board I've ever used, bar none.

It comes with a cost though. All those speed doesn't come from nothing. It is no longer fanless like Odroid-U2; XU4 comes with a fan. The power supply now can provide juice up to 4A - but this probably to support 2 USB3 ports on its board too.

PS: I used 3.10.y kernel. The 4.2 kernel is marked as EXPERMENTAL by hardkernel and currently lacks many of the fine improvements you can find in 3.10, like sound, and HMP support. It was created to be able to boot Debian server, but I find that even for server work, this is no good because it lacks the ability to schedule the cores properly. And furthermore, it seems to have been abandoned (last update is Aug 2015, while 3.10 is updated just a week ago).

PPS: An oh, on the same URL, you can find official Raspi2 kernel packages too. This is my official kernel packages, which I built from source, and of which I can also supply its kernel source SFS. The berryboot-based kernel are still available in its old link but I'm going to take it down soon.

Posted on 6 Apr 2016, 00:11 - Categories: FatdogArm Linux Arm
No comments - Edit - Delete


Can a FOSS contributor retracts his/her contributions?

Another aspect of Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet” is from the comments I've read on-site: is it okay for a FOSS contributor to retract his/her contribution from a public site? Some says yes (contributor has rights) and some says no (once open it is open forever).

I would think the answer is obvious, if we separate the contribution and the publishing.

An author of an FOSS contribution has full rights to his contribution - he can retract, remove, destroy, change, or even change the license of his work. There is no question about it.

But due to the nature of FOSS, once the contribution is published, anyone can take it and re-publish it (with attributions as needed). The original author has no say about it and can't demand that they be taken down; because when he/she published the code he/she gave the world irrevocable right to do just that.

That does not mean the author cannot revoke his/her work, of course they can. It's just that he can't demand that everyone else must also take down the copy of his/her work.

Now, when author publishes his/her work through a 3rd party, however, he/she has to obey the terms of this 3rd party publisher. Some will give the rights to retract and delete, some do not. The point is, the publisher must make the terms and conditions clear.

Github for example allows you to retract and delete anything you publish on it - no trace will be left on its site if you choose to remove your work. Facebook is at the opposite - although at the beginning they didn't make it clear, nowadays it is pretty obvious that while you can delete your account and logins, whatever you submit to Facebook will live forever, and they can even use it long after you've removed your account. You give them that rights when you join Facebook. If you don't agree - well, don't use the Facebook. Simple.

Now back to npmjs.com. They should have made it clear that they allow (or disallow) contributors to remove their contributions; and the stand by that. If they allow authors to remove their contributions, people who use the service knows that anything on npmjs should be considered ephemeral and can disappear at anytime - thus they can take mitigative actions (or choose not to use the service at all). If they don't allow removals, authors who contribute to the service knows that anything they choose to publish through npmjs.com is perpetual and can then choose whether or not they want to contribute. But npmjs.com can't have it both ways - because in the end you will irritate both the authors, and the end users.



Posted on 27 Mar 2016, 23:41 - Categories: General
No comments - Edit - Delete


Fatdog64 710 builds 32-bit/64-bit wine

Fatdog64 710 passed its ultimate test this weekend: the ability to build wine that supports running 32-bit and 64-bit Windows applications.

To support 32-bit Windows apps, wine must be built in 32-bit mode. To support 64-bit Windows apps, wine must be built in 64-bit mode. To build wine that can support both, it must be built in both 32-bit and 64-bit mode. That requires multilib support.

And that's the new, major feature of Fatdog64 710: Fatdog64 now supports multilib natively. Building wine in 32-bit and 64-bit mode is the final test that its multilib capability is complete, working, and correct.

Happy Easter everyone.

Posted on 27 Mar 2016, 21:38 - Categories: Fatdog64 Linux
No comments - Edit - Delete


Local copy anyone?

I just read this:
Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”
.

There are too many interesting aspects to consider from the article, but the one that surprised me the most is this: somebody removed their contribution from a public repo, and everything broke? Really? Haven't anyone heard of "local copy"?

Posted on 27 Mar 2016, 21:25 - Categories: General
No comments - Edit - Delete


Fatdog64 710 enters testing stage

Fatdog64 710 is the next generation of Fatdog64. It is still part of 700 series but considered as another branch; because it has a new build system (both for system and user packages) as well has other infrastructure changes which I prefer not to disclose for now. It share the common base as 700 thus many software packages will be largely backward and forward compatible between 700/710 although some may not, due to the usage of many newer libraries in 710.

710 has been in the works for about a year, since the first 700 release went final, but it got stuck there as real-life priorities took over. Most recently, I have 710 ready for testing since early Feb this year but I had to postpone it because I need my laptop to be stable and can't affort running a test OS at that time.

Yesterday, however, I took the plunge and migrated my savedir to 710. The testing process has begun.

Posted on 13 Mar 2016, 15:41 - Categories: Fatdog64 Linux
No comments - Edit - Delete


Fatdog702 ISO re-uploaded

Due to the CVE-2015-7547 scare that hits glibc recently, plus the fact that it is not easy to update glibc, I've decided to re-upload Fatdog64 702 that was uploaded a few days ago with a new set of ISO, devx, and nls SFS that contains a new patched glibc.

The CVE patch itself comes from the Debian team (since the official patch only applies cleanly to latest glibc - not to glibc 2.19 that 702 uses). Thank you Debian.

The new packages md5sums are as follows:
---
c7bff729fc3a6100246020466e94e6af Fatdog64-702.iso
54cc4ef28741e9e9844ab6f5ca66d41c fd64-devx_702.sfs
975d127442a8a336ec14dc743d51ad61 fd64-nls_702.sfs


Posted on 18 Feb 2016, 00:23 - Categories: Fatdog64 Linux
No comments - Edit - Delete


FatdogArm on Raspiberry Pi 2

There were some interest in running FatdogArm on Raspberry Pi 2 (raspi2 for short). While FatdogArm will never run on the original Raspberry Pi for many reasons (the biggest one: unsupported ARMv6 architecture), raspi2 has a modern quad-core Cortex A7 (=ARMv7 architecture) CPU running at 900 MHz, and comes with 1GB RAM standard. Not stellar, but not bad either.

Thanks to the help of forum member "mories" and the berryboot 2.0 kernel/modules, it was possible to get FatdogArm on raspi2: http://murga-linux.com/puppy/viewtopic.php?p=878960#878960. It's available here: http://distro.ibiblio.org/fatdog/arm/releases/raspi2/.

But I could not test it myself since I didn't own a raspi2 myself. Now, a kind gentleman who prefers to remain nameless has given me a raspi2 board, together with a very nice cover.

Though I am very busy these days, this inspired me to get the basics going on. I've just built a kernel directly from Raspi's official kernel source distribution (branch 4.1.y). Together with the closed-source bootloader (also from Raspi's official firmware distribution), I've managed to get it to boot to desktop.

This is still a long way to get raspi2 to become a tier-1 supported platform (we need to configure various hardware acceleration modules), but at least it is now running under its own kernel.

When things is a bit more stable I'm going to prepare a proper raspi2 kernel package, replacing the berryboot-based package we have right now. And perhaps publish beta4.

Posted on 15 Feb 2016, 23:25 - Categories: FatdogArm Linux Arm
No comments - Edit - Delete


Fatdog64 ISO builder is released

Fatdog64 ISO Builder is a tool to make custom Fatdog64 ISO.

It's similar to Puppy Linux "woof", except that this builder specifically builds from Fatdog64 self-built packages only. Since it works with Slackware-style packages (.txz), you may be able to tweak it to work from Slackware packages as well, though that has never been tested.

Announcement

Posted on 14 Feb 2016, 21:28 - Categories: Fatdog64 Linux
No comments - Edit - Delete


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