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
No comments - Edit - Delete

Never mind. I found one.

I am a subscriber of Mikey's Funnies, and has been for a very long time.

Today this came into my mailbox, and since Easter is coming in two week's time, I find that this is especially appropriate and I couldn't resist to re-post it here.

Paddy was driving down the street in a sweat because he had an important meeting and couldn't find a parking space. Looking up to heaven, he said, "Lord, take pity on me. If you find me a parking space, I will go to Mass every Sunday for the rest of me life and give up me Irish whiskey!"

Miraculously, a parking space suddenly appeared.

Paddy looked up again and said, "Never mind. I found one."

[forwarded by Adon Brownell]

How many times do we act like that ourselves?

Posted on 25 Mar 2015, 2:35 - Categories: General
No 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
No 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, uoc.gr, and nluug.nl.

Posted on 25 Feb 2015, 3:10 - Categories: Fatdog64 Linux
No 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, uoc.gr, and nluug.nl.

Posted on 13 Feb 2015, 4:13 - Categories: Fatdog64 Linux
No 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
1 Comment - Edit - Delete

jamesbond3142.no-ip.org no longer used.

I have relinquished control over the old domain of this blog and wiki, which was "jamesbond3142.no-ip.org". I have put a notification here but apparently I still have a few links pointing to the old domains.

I am informed today that the old domain has been taken over and is being used to distribute malware. Please avoid that domain from now on.

Because of that, I have urgently changed all links that I know to point to the new domains. If you still know some old links to the no-longer used domain, please let me know and I will update them if it is under my control.

Posted on 17 Dec 2014, 4:22 - Categories: General
No comments - Edit - Delete

Fatdog64 700 beta2 is released

Linux 3.17.1 and other updates, fixes problem with missing fonts on opera/chrome and others.

Release notes
Forum announcement

Get it as usual from ibiblio or one of its mirrors: aarnet, uoc.gr, and nluug.nl.

Posted on 28 Oct 2014, 18:22 - Categories: Fatdog64 Linux
No comments - Edit - Delete

FatdogArm Beta2 sfs re-uploaded

The main change is that xorg-server is now built with these two patches: http://forum.odroid.com/viewtopic.php?p=37553&f=7#p37553 and http://forum.odroid.com/viewtopic.php?p=35833&f=7#p35833 for better performance and stability. Thanks Daniel (aka dsd). This change only improves Odroid, and has no impact in other platforms as only Odroid uses DRI2 interface at the moment (Allwinner: fbdev, OLPC/Marvell: DRI1, Cubox-i/Freescale: DRI1).

Coupled with a few updates in the repo and youtube-dl, it is now possible to write a simple script that will stream video and play it fullscreen on Odroid/Cubox-i directly from youtube. Perhaps I'll share that script later.

Posted on 8 Oct 2014, 5:33 - Categories: FatdogArm Linux Arm
3 Comments - Edit - Delete

3D hardware acceleration for cubox-i

I have finally managed to get 3D acceleration working on cubox-i. This has been long-time coming.

Initial testing of the 3D acceleration always caused a hard lock-up on Xorg. System was still alive, and was still responsive (if you use SSH), but Xorg completey died, you can't even switch VT anymore.

Today I have finally found the solution - Freescale provided a patch for libdrm, *and* Xorg must be re-compiled against this patched libdrm. This was found as early as March by forum member "notwa", but I didn't take this seriously because:
a) it was intended for kernel 3.0.35 while I used 3.10.30 kernel
b) I actually patched libdrm but didn't rebuild xorg-server as I thought it was unnecessary (I reviewed xorg-server source to find where exactly the patched change could have impact, and couldn't see it).

Today I found that another forum member "catwich" had the same problem I had, and confirmed that "notwa" solution worked - if followed in full. I decided to have a go myself on FatdogArm, and look and behold - it worked! es2gears, glmark2 and glmark2-es2 all worked. What a joy!

The updated drivers will be in the repository as usual. As a closing note, I also built gst-plugins-gl (containing "glimagesink" - see my earlier post about hardware accelerated video playback pipeline), and it works well as an alternative to mfw_v4lsink.

With this, support for cubox-i platform is now considered complete (apart from bluetooth support, but that's minor stuff ... may be later). All these work with FatdogArm beta2. I updated the release note to reflect this fact but if you have already downloaded the SFS and the kernel package, there is no need to download again as there is no change there: all the drivers are in the repository and those are the ones that got updated.

Posted on 6 Oct 2014, 1:23 - Categories: FatdogArm Linux Arm
No comments - Edit - Delete

Pages: ... [10] [11] [12] [13] [14] [15] ...