Pen drive with SD/MMC card reader on Linux

Today, I was backing up some old data from a another laptop to a USB pen drive (SD/MMC card reader) using Ubuntu 10.10 LiveCD. This pen drive was no SD card, or else, it had only itself capacity (128 MB =P).

When I tried to mount this pen drive on my Gentoo Linux, I was getting the error:

mount: unknown device

But what ?! dmesg, udevadm and lsusb were showing me that it was there:

lsusb:

Bus 002 Device 004: ID 0bda:0103 Realtek Semiconductor Corp. USB 2.0 Card Reader

dmesg:

usb 2-2: new high speed USB device using ehci_hcd and address 4
scsi4 : usb-storage 2-2:1.0
scsi 4:0:0:0: Direct-Access     Generic  2.0 Reader   -SD 1.00 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg1 type 0
sd 4:0:0:0: [sdb] Attached SCSI removable disk

After looking carefully to output messages on Ubuntu 10.10 LiveCD, I realized that only the card reader was being recognized, the internal storage was not.

Well, in order to resolve this problem I had to recompile the kernel and activate the option CONFIG_SCSI_MULTI_LUN:

Device Drivers -> SCSI device support

[*] Probe all LUNs on each SCSI device

After reboot the system with my new kernel I could see the expected output message from dmesg:

usb 2-2: new high speed USB device using ehci_hcd and address 4
scsi4 : usb-storage 2-2:1.0
scsi 4:0:0:0: Direct-Access     Generic  2.0 Reader   -SD 1.00 PQ: 0 ANSI: 0 CCS
scsi 4:0:0:1: Direct-Access     Generic  2.0 Reader   -FD 1.00 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg1 type 0
sd 4:0:0:1: Attached scsi generic sg2 type 0
sd 4:0:0:1: [sdc] 256000 512-byte logical blocks: (131 MB/125 MiB)
sd 4:0:0:1: [sdc] Write Protect is off
sd 4:0:0:1: [sdc] Mode Sense: 03 00 00 00
sd 4:0:0:1: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdb] Attached SCSI removable disk
sd 4:0:0:1: [sdc] Assuming drive cache: write through
    sdc:
sd 4:0:0:1: [sdc] Assuming drive cache: write through
sd 4:0:0:1: [sdc] Attached SCSI removable disk

Now, I could mount the device /dev/sdc and transfer the whole backup to my homedir.

To the curious the pen drive model with 128MB is showed bellow:

My 2 cents

The strlen problem of Valgrind on Gentoo

Everybody knows that Valgrind is the best open source tool to detect memory bugs on Linux OS.

Recently, I updated valgrind through emerge and a problem began to occurred:

==23796== Memcheck, a memory error detector
==23796== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==23796== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==23796== Command: /bin/echo
==23796== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

How do you see, the glibc package has been stripped. There is a bug opened to this. But, for a while, I need of the tool and I can’t wait for a solution…

Here comes a little trick to permit valgrind operates again over the glibc. Just add to your make.conf the line bellow:

FEATURES="splitdebug"

Just a little explanation about stripping on Gentoo:

There are two ways to stop stripping from interfering with debugging and useful backtraces. The first is to tell Portage to not strip binaries at all, by adding nostrip to FEATURES. This will leave the installed files exactly as gcc created them, with all the debug information and symbol tables, which increases the disk space occupied by executables and libraries. To avoid this problem, in Portage version 2.0.54-r1 and the 2.1 series, it’s possible to use the splitdebug FEATURE instead.

With splitdebug enabled, Portage will still strip the binaries installed in the system. But before doing that, all the useful debug information is copied to a “.debug” file, which is then installed inside /usr/lib/debug (the complete name of the file would be given by appending to that the path where the file is actually installed). The path to that file is then saved in the original file inside an ELF section called “.gnu_debuglink”, so that gdb knows which file to load the symbols from.

After modify your make.conf, re-emerge glibc:

emerge glibc

And now, be happy:

==21886== Memcheck, a memory error detector
==21886== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21886== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21886== Command: /bin/echo
==21886==
==21886== HEAP SUMMARY:
==21886==     in use at exit: 0 bytes in 0 blocks
==21886==   total heap usage: 30 allocs, 30 frees, 3,681 bytes allocated
==21886==
==21886== All heap blocks were freed -- no leaks are possible
==21886==
==21886== For counts of detected and suppressed errors, rerun with: -v
==21886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

VirtualBox and the bridge problem on Gentoo

In this post I’ll show how to configure a VirtualBox appliance with bridge network on a Gentoo linux.

First, we’ll need tunctl to create a TUN/TAP device and brctl to setup a ethernet bridge:

emerge sys-apps/usermode-utilities

emerge net-misc/bridge-utils

Now, just add the lines bellow to your /etc/conf.d/net:

####################
# VirtualBox Bridge
####################
config_eth0="null"

tuntap_vbox0="tap"
tunctl_vbox0="-u <user>"
config_vbox0="null"

rc_need_br0="net.vbox0"
bridge_br0="vbox0 eth0"
config_br0="172.16.1.2/24"
routes_br0="default via 172.16.1.1"

brctl_br0="setfd 0 sethello 0 stp off"

• Change “<user>” by the your user, i.e., the user that will use the VirtualBox.
• The host machine (your Gentoo linux) will assume the IP address 172.16.1.2
• If you have more than one vbox appliance that you want to use in bridge mode, just create an additional interface (vbox1, vbox2, etc)  configuration to each vbox host and include these interfaces to the variable bridge_br0

Create a symbolic link to these new interfaces (vbox0 and br0):

ln -s /etc/init.d/net.lo /etc/init.d/net.vbox0

ln -s /etc/init.d/net.lo /etc/init.d/net.br0

Start the new interfaces:

/etc/init.d/net.vbox0 start

/etc/init.d/net.br0 start

Check if the following lines are included in /etc/modules.autoload.d/kernel-2.6:

vboxdrv
vboxnetflt
vboxnetadp

After all infrastructure configuration, now we’ll configure the vbox appliance. Open the VirtualBox program, select the appropriate appliance, go to “Settings“  and change its newtork settings:

Attached to: Bridged Adapter

Name: vbox0

It’s exemplified in figure bellow:

click to enlarge

Now, you can boot the appliance and configure its IP address inside the range (172.16.1.3-172.16.1.254) and access it from the host machine (your Gentoo linux).

Note: this procedure was tested only on VirtualBox 3.1.6

Emerge easter egg

Today I’ll post just a little easter egg inside the emerge command (Gentoo linux):

Say hello to Larry, the cow!

Compiling Google Chromium with GCC-4.4

These days I began to develop a new feature to Google Chromium and fix some ones (certain problems in Chromium gets me angry…very angry!!! =P).

I resolved to write this post because in the official build guide there is not mention how to workaround the problem with gcc-4.4 and the WebKit bug (you can see it here).

The problem resides in the file:

$CHROMIUM_ROOT/src/third_party/WebKit/WebCore/WebCore.gyp/webcore.target.mk

If you don’t apply this patch you will see various erroneous lines saying that there are undefined references into file libwebcore.a as these bellow:

undefined reference to findColor

undefined reference to findEntity

undefined reference to findValue

Pay attention: you have to apply the patch after synchronize your code with the remote repository and run the command “gclient runhooks –force” inside $CHROMIUM_ROOT/src or else the changes will be overwritten!

To apply the patch, just do it:

cd $CHROMIUM_ROOT

patch -p0 < /path/to/patch.doc

Some informations:

• ccache statistics:

• time compilation:

~  1h56m08s

• target machine:

2.6.32-gentoo-r4-fx #1 SMP PREEMPT x86_64 Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz

tools:

gcc 4.4.3 / ccache 2.4

Extra informations:

• if you desire compile the code with ccache just change the Makefile inside $CHROMIUM_ROOT/src
• all object code and binaries are put into directory $CHROMIUM_ROOT/src/out, if you wanna run a “make distclean” just remove this directory…this Makefile (from h3ll) does not have a distclean target!!!

In the next article I will explain how to compile Google Chromium with LLVM/Clang

Boosting your Kernel on Gentoo

Everybody knows that Gentoo is a performance-architeture-oriented Linux. You can optimize your entire system changing the compiler (gcc) flags to attend the hardware specificities.

Example: I have a Sony VAIO with Intel Core 2 Duo processor, then I can use this flags on my make.conf (I unmasked sys-devel/gcc to use gcc-4.3.3 that have native support to core2 technology)

CFLAGS="-O3 -march=core2 -pipe -fomit-frame-pointer -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3"

Then, all binaries in your system will be optimized…but and the kernel ???

Well, when you compile the kernel it uses itself compiler flags. And how to optimize it ?

Good news to you…If you have a Intel processor and use Gentoo Linux in your machine you are a lucky man. You must know the LinuxDNA project. The idea of the project is optimize the kernel to Intel architecture using the icc (Intel Compiler).

Currently, I’m working on Gentoo ebuild to linuxdna package. You’ll have more news about it soon…