The Unofficial Gentoo Linux x86 uClibC stage3s’

Update:
The catalyst spec files are available here:
https://github.com/judepereira/gentoo-development/tree/master/x86/uclibc/catalyst

Following this Gentoo bug:
https://bugs.gentoo.org/show_bug.cgi?id=441976
We have official experimental uClibC for x86 and amd64 stages.
I will not be maintaining these unofficial ones any longer.

The link to the official archives is:
http://mirrors.rit.edu/gentoo/experimental/x86/uclibc/
and
http://mirrors.rit.edu/gentoo/experimental/amd64/uclibc/

The uclibc experimental stages on the gentoo mirrors are all outdated(they go back to years), so here are my stage3s’, which have been updated. They’re very similar to, and in fact can be considered to be the same stages that the Gentoo Community provides, only updated.

As of 27th August 2011, they are now built by catalyst.

The stages are built by catalyst now, and I’m looking for the possibility of hosting them on the Gentoo mirrors.

Follow my tutorial here, to get a basic ideology on working with it

stage3-uclibc-x86-26062012 is affected by bug #423491 sys-apps/findutils-4.4.2-r1 and sys-apps/coreutils-8.14 with sys-libs/uclibc – rpmatch.c:58:1: error: redefinition of ‘rpmatch’ /// /usr/include/stdlib.h:810:28: note: previous definition of ‘rpmatch’ was here

The workaround for it right now is to comment the entire function in stdlib.h and those packages will compile well. Also comment the _wur definition, just above the function rpmatch. This is a crude workaround, and it’ll be fixed when upstream decides what’s the solution.

Files:
26th June, 2012
stage3-uclibc-x86-26062012.tar.bz2
stage3-uclibc-x86-26062012.tar.bz2.md5sum

The above stage was not build by catalyst, as it could not deal with the rpmatch bug. This stage was created manually from the last release.

5th August, 2011
stage3-uclibc-x86-02082011.tar.bz2
stage3-uclibc-x86-02082011.tar.bz2.md5sum

7th July, 2011
stage3-uclibc-x86-07072011.tar.bz2
stage3-uclibc-x86-07072011.tar.bz2.md5

1st June, 2011
stage3-uclibc-x86-01062011.tar.bz2
stage3-uclibc-x86-01062011.tar.bz2.MD5

25th April, 2011
stage3-uclibc-x86-25042011.tar.bz2
stage3-uclibc-x86-25042011.tar.bz2.md5sum

For historic releases, post a comment, as to which one you require and why a specific version.
If you want the stage1 or stage2, drop a comment and I shall have them uploaded.

For those of you who would like to build these stages themselves, here are the spec files for catalyst:
stage1.spec
stage2.spec
stage3.spec

Update:
The catalyst spec files are available here:
https://github.com/judepereira/gentoo-development/tree/master/x86/uclibc/catalyst

In addition, I’ve taken down all the stage files that I used to host here, in favour of the official stages now available from the Gentoo mirrors:

Hacking your GoFlex Home, #3 Ideas

Well, first off the ability to just add one USB device is a little boring, I’ve been using a Belkin 4 port USB HUB, and the results are good. For cooling the GoFlex, you may want to remove the bottom cover and keep it on a laptop cooling fan or something similar, as the processor does tend to get hot slowly.

Maybe you could throw in a WiFi USB card, and turn your Goflex into a very powerful NAS, something that I’ve done is:

  • Have a DLNA/UPnP Server running, as I have it as my NAS
  • Internet Gateway
  • Torrent Station(I use transmission daemon with the Web UI)
  • FTP Server

There are way more applications of this tiny little plug computer, I’m using it for development.

Also, it’s preferably better to have Gentoo or Arch Linux on a USB stick, as when testing several times by hard power offs and resets, you don’t want the SATA drive spinning up for no reason.

Hacking your GoFlex Home, #2 UART Serial Console

Serial console? That’s beautiful when it comes to debugging. The following images are specific to the Seagate GoFlex Home, however, you may be able to figure out the connections for other Marvell SoCs.

On the board:
Notice that according to the picture, the bottom right last three pins are used.
Connections on the SoC

The junction:
I’ve used extra wires simply for convenience, the orange, yellow and black connect to these white, black and grey wires respectively.
The Junction

On the USB UART Adapter:
I’ve used a USB2.0 to RS232 TTL Converter Module PL2102(available on eBay easily)
On The USB Adapter

PIN Configuration:
On the GoFlex Home:

10 9 8 7 6
 5 4 3 2 1

1 => GND (Ground for the serial communication)
2 => RX  (Receiving bits)
3 => TX  (Transmitting bits)

Note: The RX and TX are interchanged at one end, this is because the RX of the GoFlex becomes the TX of the USB adapter, and vice cersa.

After you connect the USB end to your desktop/laptop, you can use screen to display the serial console:

# screen /dev/ttyUSB0 115200

The serial console is especially useful for debugging the kernel boot and setting the u-boot environment.

Hacking your GoFlex Home, #1 Build your KERNEL

It’s been quite sometime that I’ve got my GoFlex Home now, and it’s only recently that I’ve received my RS232 Serial USB UART Adapter.
The pin connections are simple and easy, I’ll post that as well. As I’ve already got Gentoo Linux running on the Marvell SoC, I was still using the Archlinux ARM kernel, for lack of better options. Building the kernel seemed to be a simple task, but apparently, if you have used the Archlinux ARM kernel config as a base to build your own, you won’t see the kernel debug messages, you only see the warnings, and those are few.

To get going:
Download the kernel sources, I’ve got a successful build with vanilla sources(patched with archlinuxarm patches) 3.1.10
After patching the kernel, you can quickly generate the default config, by

# make kirkwood_defconfig

That would generate the default configuration, then you could configure it via menuconfig, and set the required options.
I’ve attached my present kernel configuration, you could use that as a base, as it took me quite a while to get the kernel working right. This kernel does not support an initrd, as I don’t think embedded devices should need one. So, if your kernel says that it can’t mount the VFS, it’s likely that your U-boot is giving it an initrd to use, and that surprisingly, took me quite a while to figure out.

Goodluck hacking your GoFlex :)

[howto] grsecurity + NOUVEAU + Compiz + Seg Fault

Assuming that you have a grsec + PaX enabled kernel, you would realise that the nvidia-drivers are a bad choice. Quite a few applications will fail(the ones that use libGLcore.so). Use the nouveau driver for your card, as it’s pretty much stable and works with good 3D acceleration.

compiz under NOUVEAU + PaX

To get compiz working NOUVEAU under hardened linux, first enable the kernel DRM module for nouveau. Follow this link: The X Server Configuration HOWTO

Build the kernel, and install it. Edit the VIDEO_CARDS variable in your make.conf to say only nouveau, nothing more, nothing less.

Unmask the following packages: media-libs/mesa, x11-libs/pixman, x11-drivers/xf86-video-nouveau, x11-base/xorg-drivers, x11-base/xorg-server, x11-libs/libdrm, x11-drivers/xf86-input-evdev, x11-drivers/xf86-input-keyboard, x11-drivers/xf86-input-mouse

Install the above packages, make sure you’ve done a emerge -C nvidia-drivers nvidia-settings prior to the merge.

Reboot the system, it should all work out of the box, compiz will fail with a segmentation fault, look into your logs. You’ll see something like the following:

2011-05-11T17:22:24.760922+05:08 halcyon-82 kernel: [ 2026.893377] grsec: denied
 resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/b
in/compiz[compiz:20146] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[
bash:11847] uid/euid:1000/1000 gid/egid:1000/1000

2011-05-11T17:26:07.848848+05:08 halcyon-82 kernel: [ 2249.981362] compiz[20378]
: segfault at ffffffffffffffff ip 00000284c5f39fa1 sp 0000039c50e0ee00 error 6 i
n nouveau_dri.so[284c5cc3000+38b000]

Simply disable pax for compiz and emerald, do the following as root:

# paxctl -zm /usr/bin/compiz
# paxctl -zm /usr/bin/emerald

Now, start compiz as usual and your all set.
On a side note, flash player will show a similar issue too, so disable PaX for that too.

WARNING: Disabling PaX for compiz, emerald and flash is a security risk.

creating unique environments – chroot snapshots – using aufs2

What if you decided that you wanted to experiment and test within a chroot(ed) environment? And then something went wrong and you had to start all over again from scratch? Big headache, too much pain, especially with RPM based distributions.

Well don’t do that then, here’s an interesting approach. Use aufs2, a stackable filesystem. An actual filesystem with “RAID-like” support.

chroot layers, using aufs2

You can inherit different environmental settings from various bases, much like the concept of object oriented programming.

Aufs is a stackable unification filesystem such as Unionfs, which unifies several directories and provides a merged single directory.(from http://aufs.sourceforge.net/)

Setup aufs2. You need to patch your kernel. For gentoo, you can just merge sys-fs/aufs2 with the following flags: “fuse inotify kernel-patch kernel_linux ramfs -debug -hardened -hfs -nfs”. The patch will be automatically applied, you just need to recompile it after merging. For other distributions, take a look at the homepage of aufs2.

Setup your chroot as you normally do. Let’s say you’ve setup centos in a chroot environment, for developing. You’ve done yum groupinsall “Development Libraries” “Development Tools”. Let’s create a snapshot here of this environment.

# mkdir env1
# mount -t aufs -o br=/home/jude/env1/:/home/jude/centos-dev=ro none wor
k-dir
# chroot work-dir

 
What does this do? As you can see, your first centos-dev has been branched as RO, read-only. Which means, any changes now made, are transparently written into env1 directory, with the very same structuring. Say, you’ve structured env1 as you want it to be, now you need a second environment, based on the first env1, you can simple do:

# mkdir env2
# mount -t aufs -o br=/home/jude/env2/:/home/jude/env1/=ro:/home/jude/ce
ntos-dev=ro none work-dir
# chroot work-dir

 
Now, env1 is RO, any changes now are further written to env2, keeping the structuring of every little change intact, just as the first. If you want to suddenly use env1, don’t add env2 to the RW branch, any branch that doesn’t have anything in front of it, is assumed to be RW, read-write.

What happens when you delete a file/directory from a branch mounted as RO? A file called .wh.filename is created in the RW branch, indicating to the overlaying filesystem to NOT index that file anymore.

In this way, you could create several different environments, each being inheriting a base, and then depending on the needs, the other environments created.

You can comment if you get any errors, I’d be glad to help you out.

bootstrap CentOS from Gentoo (or any linux distribution)

To bootstrap CentOS in Gentoo, I did the following. It basically installs the essential CentOS components into the specified directory, and from there on, chroot into that directory and perform tests, etc. First off, you’ll need to unmask a few packages(replace ~amd64 with ~x86 if your on the x86 architecture), and enable the flag sqlite for rpm. Execute the following commands as root:

# echo sys-apps/yum ~amd64 >> /etc/portage/package.keywords
# echo dev-python/sqlitecachec ~amd64 >> /etc/portage/package.keywords
# echo app-arch/rpm sqlite >> /etc/portage/package.use

 
Now we’re ready to install the primary packages required to bootstrap CentOS. Merge the following atoms: sys-apps/yum app-arch/rpm dev-python/m2crypto as

# emerge -avuDN sys-apps/yum app-arch/rpm dev-python/m2crypto

 
In this example, we’ll bootstrap CentOS 5(x86_64). Download the stage2(sounds like gentoo now, huh?) from any CentOS mirror. The minimal stage2 does not work with this process.

# wget http://mirrors.seas.harvard.edu/centos/5.6/os/x86_64/images/stage2.img

 
You need to extract the contents of this squashfs image file, so make sure you have =sys-fs/squashfs-tools-3.1 installed. The latest one in portage is broken. Execute the following:

$ unsquashfs-3.1 -d /devel/centos5 stage2.img

 
Now we have a working CentOS 5.6 installation. Install bash and yum into it before you can finally chroot.

# yum --installroot /devel/centos5/ --nogpgcheck install bash
# yum --installroot /devel/centos5/ --nogpgcheck install yum

 
The –nogpgcheck is so that yum doesn’t check the gpg keys which are currently missing on your host gentoo system, or any other non-rpm distribution. chroot into /devel/centos5 and perform some cleaning:

# chroot /devel/centos5
# mkdir /old
# mv /var/lib/rpm /old
# yum install yum

 
What did you just do? Well the RPM DB generated by your host distribution’s RPM, will certainly not match CentOS’s yum, hence we remove the stale RPM database. Everything in the stage2 comprises only of the dependencies of yum and yum itself. Doing a yum install yum will fix everything.
 
Congratulations, you now have the base CentOS installation in /devel/centos5 These instructions are not limited to Gentoo alone, but to any distribution. Any questions may be posted as comments, and I’ll be glad to help you out.

binpkg: a Gentoo Masterpiece

If you were running a cluster of Gentoo driven machines, would you actually compile source for each of them?

Or rather use binary packages?

Gentoo’s masterpiece is binpkg, when you compile for one machine, you don’t have to recompile throughout, use quickpkg to build binary packages. Such packages can be hosted over a central server and each system downloads just the binary package.

You can use this even if your not running a cluster, but frequently reinstall certain packages. Use the -b flag with emerge to install and build the package as well.

Setting the PKGDIR in /etc/make.conf
Add the following directive in make.conf

PKGDIR=”/var/cache/portage/binpkg”

Building binary packages is easy.

quickpkg $(qlist -IC)

That goes on your main server.

You can add the parameter –include-config=y , it’s not reccommended because then you’ll bascically be cloning the host. Your IP addresses, etc. are installed as is. Deploy an instance of puppet.

Now your binary packages are built, you can symlink them and make them available on the webserver for production purposes.

Adding BINHOST to your sister machines, add the following directive in your make.conf, make the necesssary changes:

PORTAGE_BINHOST="http://your.server.repo/path/to/binary/packages"
PKGDIR="/var/cache/portage/binpkg"

 

Options
–getbinpkg Fetch binary source if available, else, fetch source
–getbinpkgonly Fetch binary source ONLY
–usepkg Use binary package for merge if available, else resort to source compile
–usepkgonly Use binary package ONLY

 

Note: If you specify to fetch/merge using ONLY binary packages, if certain dependencies are missing, emerge will simply abort. Hence, its not advisable to do so.

Coloured /var/log/messages at tty12

Reading logs could never become any more easier, at just a keystroke, you have your logs displayed where you want, in some fancy colour. They look great too.

CCZE colourized logs

TTY’s can be accessed by pressing Alt + Ctrl + F[1 – 12] simultaneously. In the following, you’ll get a decent, colourized log display of /var/log/messages when you press Alt + Ctrl + F12

First install ccze, most distributions have it in their repositories. CCZE is a robust and modular log colorizer with plugins for apm, exim, fetchmail, httpd, postfix, procmail, squid, syslog, ulogd, vsftpd, xferlog, and more. It brightens up the log view.

To quickly test it, try tail -f var/log/messages | ccze -A

The -A switch prevents ccze from starting itself in a curses window.

Create a file cclm in /usr/local/bin(you have to be root to be able to do so), with the following contents:

#!/bin/sh
file="/var/log/messages"
where="/dev/tty12"
tail -f $file | ccze -A >> $where

Add the following line to /etc/inittab
c12:123456:respawn:/sbin/agetty -n -l /usr/local/bin/cclm 38400 tty12 linux
That’s all that there is to be done, either reboot to get it working, or execute the following in a terminal with privileges:

/sbin/agetty -n -l /usr/local/bin/cclm 38400 tty12 linux

This can be used on any ttys’. The most obvious ones to use would be tty8 to tty12.

Lazy System Admins – Bash Completion

Let’s admit it, we’re all lazy system admins. The bash completion in any other distribution is incomplete, and not as powerful as the one in Gentoo. It just does not work the way it works so brilliantly in Gentoo Linux. Ofcourse, you can port that same source to other distributions. To enable bash completion in gentoo, first enable the global flag bash-completion:

euse --enable bash-completion

Now remerge all packages that have that flag:

emerge -avuDN world

You can now see that eselect bashcomp list lists all the completions available, but are not enabled. To enable them all at once, for the current user(in the following, “jude”), do:

mkdir ~/.bash_completion.d
ln -s /usr/share/bash-completion/* ~/.bash_completion.d/

Now disable the following two sets:

eselect bashcomp disable Makefile.am
eselect bashcomp disable Makefile.in

Re-login, and your all set, cheers!

visual basic 6 revisited – linux – wine

Earlier this year, I had written an article on running Visual Basic 6 on linux under wine, this is an update for it, the prior one is deprecated

Getting Visual Basic 6 to work on linux is pretty easy, not much trouble, all the basic things work, as of what I’ve tested.

Here’s how you get that damn thing to work:

Copy over the contents of OS/SYSTEM/ from the CD root to your wine system32 directory

$ cp -r /media/cdrom/OS/SYSTEM/* ~/.wine/drive_c/windows/system32/

Since we are only concerned about Visual Basic 6, copy over the folder VB98 from the CD root to your Program Files

$ cp -r /media/cdrom/VB98/ ~/.wine/drive_c/Program\ Files/
# for the sake of convenience, let's rename this folder as Visual Basic 6
$ mv ~/.wine/drive_c/Program\ Files/VB98/ ~/.wine/drive_c/Program\ Files/Visual\ Basic\ 6/

Register the two dynamically linked libraries essential to run Visual Basic 6 smoothly

$ cd ~/.wine/drive_c/windows/system32/
$ wine regsvr32 comcat.dll
$ wine regsvr32 MSSTDFMT.DLL

Easy, eh? Your all done, now, let’s create an optional launch command with the following contents
File: vbasic

#!/bin/bash
cd ~/.wine/drive_c/Program\ Files/Visual\ Basic\ 6/
wine VB6.EXE

Make our launcher executable and place it in the right place

$ chmod +x vbasic
# following command must be issued as root
$ mv vbasic /usr/local/bin/

Now you can just issue the command vbasic, and all should work well, using this launcher, you can create entries for your panel, etc.

Deployed with a fresh install of wine version 1.2-rc2

CPU scaling governors and you

What is your CPU being governed by? Should it be governed by it? Why? How?
Here’s an outlook on the various CPU frequency governors, namely conservative, ondemand, powersave, userspace, and performance, that steps up and steps down the CPU:
conservative
Pros:

  • very much alike the ondemand governor
  • gracefully increases the stepping, unlike ondemand which sets it to maximum when there is any load
  • more suitable for battery powered environments

ondemand
Pros:

  • the best of all
  • sets the speed to what is required
  • saves power
  • doesn’t hinder CPU power, as it scales to what is required

powersave
Pros:

  • sets the CPU statically to use the lowest possible frequency supported
  • you save power

Cons:

  • if you use resource hungry software, your machine may start to lag

userspace
Pros:

  • another application can be used to specify the frequency
  • lets you manually specify the frequency your CPU should run on

Cons:

  • mostly useless!
  • external application may set it low, you save power, but less performance
  • external application may set it high, you consume more power

performance
Pros:

  • statically sticks to the highest possible CPU scaling available, regardless of the available ones
  • your system will run as fast as possible

Cons:

  • takes the most power that you CPU is able to consume
  • not very suitable for battery powered environments, or even to save more power your machine consumes

embedded gentoo [uclibc] | nothing beats this

A few uclibc embedded gentoo facts:

  • the compilation of the box takes around 15 minutes
  • at boot up, takes less than 3 megabytes of RAM
  • disk space: 17 megabytes
  • boots in under 8 seconds on a pentium3

link to stage3 tarballs archive
HTOP - Displaying System Statistics
# this is my make.conf, it should be the same in the stage3, if installing anything in the stage3, and even before updating, comment the line INSTALL_MASK=”*.h HACKING.gz TODO.gz”

CFLAGS="-Os -mtune=i386 -pipe"
CXXFLAGS="-Os -mtune=i386 -pipe"
CHOST="i386-gentoo-linux-uclibc"

FEATURES="strip"
MAKEOPTS="-j3"
GENTOO_MIRRORS="http://mirror.bytemark.co.uk/gentoo/ http://www.ibiblio.org/pub/Linux/distributions/gentoo"

USE="-ipv6 -python3 -cracklib -minimal"

LINGUAS="en"
VIDEO_CARDS=""
ACCEPT_KEYWORDS="~x86"
INSTALL_MASK="*.h HACKING.gz TODO.gz"

# download my stage3, from the previous post links, and then prepare to chroot

mount -o bind /dev stage3-*/dev
mount -o bind /proc stage3-*/proc
chroot stage3-*

# update the system, and create the necessary path, if you come across any errors, post them here, and expect a reply soon

emerge -avuDN world
mkdir /mounted

# begin the installation
# install necessary packages

ROOT=/mounted/ emerge -auvND baselayout uclibc bash dropbear pam udev iptables coreutils nano util-linux shadow kbd net-tools grep procps gzip sed findutils mawk htop
mkdir /mounted/proc
mkdir /mounted/dev

Continue reading “embedded gentoo [uclibc] | nothing beats this”

noCD? |boot from usb| Sabayon Linux

I had a pen-drive lying around, and so I decided to try out a new distribution of linux, Sabayon Linux.

Why Sabayon?

  • On a base install, everything is there and just works perfectly
  • For a newbie, the hard part is often getting playback codecs, well, Sabayon has them pre-installed
  • Sabayon has focused on the base theme too, it looks great
  • Entropy, their package manager, is really awesome, ‘man entropy’ to see more

Let’s mount and copy the contents of the live image, it can be downloaded here. As super user, do

mkdir /media/sabayon
mount -o loop /path/to/iso/file /media/sabayon

Plug in you pen-drive, wait for the device to settle down first, then copy whatever is important to you from the pen-drive to a hard-disk, and format it after you’ve successfully backed up your previous data

mkfs.ext3 /dev/sdyx

Replace sdyx as per your needs, i. e. the partition where you will be booting the live image from, in my case it was sdc1. You can choose any filesystem type you want to, but let’s just stick to ext3 for now.
Now copy the contents of the live image which you previously mounted to this drive after mounting it

mkdir /media/target
mount /dev/sdyx /media/target
cp -r /media/sabayon/* /media/target/

The parameter ‘-r’ indicates that it should copy recursively, and not just the files present in the top level directory
Now we’ll need to setup that device to boot correctly, you may not want to end up with a few errors and be done with it, do you?
Continue reading “noCD? |boot from usb| Sabayon Linux”