The following CMake snippet was not properly recognizing my 32bit chroot:

string(TOLOWER ${CMAKE_HOST_SYSTEM_PROCESSOR} LOWERCASE_CMAKE_HOST_SYSTEM_PROCESSOR)
if (CMAKE_COMPILER_IS_GNUCXX AND "${LOWERCASE_CMAKE_HOST_SYSTEM_PROCESSOR}" MATCHES "(i[3-6]86|x86)$")
    ADD_TARGET_PROPERTIES(WebCore COMPILE_FLAGS "-fno-tree-sra")
endif ()

After some investigation, I found out that CMAKE_HOST_SYSTEM_PROCESSOR relies on the output of uname to determine the type of the CPU, and this what I was getting if I ran it myself:

(debian32-chroot)mario:~ $ uname -a
Linux moucho 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

Let’s avoid nasty comments about the stupid name of my machine (I’m sure everyone else uses clever names instead), and see what was there: x86_64.

That looked wrong to me, so I googled a bit to see what others did about this and, besides finding all sorts of crazy hacks around, I found that in my case the solution was pretty simple just because I am using schroot, a great tool that makes life easier when working with chrooted environments.

Because of that, all I would have to do would be to specify personality=linux32 in the configuration file for my chrooted environment and that’s it. Just by doing that and re-entering in the “jail”, the output would be much saner now:

(debian32-chroot)mario:~ $ uname -a
Linux moucho 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015
i686 i686 i686 GNU/Linux

And of course, WebKitGTK+ would now recognize and use the right CPU type in the snippet above and I could “relax” again while seeing WebKit building again.

Now, for extra reference, this is the content of my schroot configuration file:

$ cat /etc/schroot/chroot.d/00debian32-chroot
[debian32-chroot]
description=Debian-like chroot (32 bit) 
type=directory
directory=/schroot/debian32/
users=mario
groups=mario
root-users=mario
personality=linux32

That is all, hope somebody else will find this useful. It certainly saved my day!

Option         "UseCompositeWrapper" "true"

After activating this option (available for nvidia drivers >= 169.xx) I found that the problems redrawing windows I was suffering, specially when scrolling (very annoying, for instance, when chatting through pidging), just dissapeared. And it was indeed a very annoying problem, since it used to happen very often and in almost any window (although not in Emacs ;-)) in my system, in a way so any information on it just got screwed up so it was completely unreadable… and the only “manual” workaround I had found so far was just to re-scroll the window or select the text I was trying to read, which seemed not to be a very good idea.

Needed to say that I started to see this odd behavior since I “downgraded” my Ubuntu 8.10 down to 8.04 last week (because of some very specific needs), and this strange problem never happened when using Intrepid, so if you’re now using that version perhaps you can just throw this post away to the trash, because then it would not useful at all for you.

But just in case, here you are my two cents, and to make them even more useful, here you are the full configuration of my “Device” section in /etc/X11/xorg.conf, which allows me to use a fully accelerated desktop with no problems at all:

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro NVS 140M"
    Option         "AllowGLXWithComposite" "true"
    Option         "UseCompositeWrapper" "true"
    Option         "XAANoOffscreenPixmaps"
    Option         "NoLogo" "true"
    Option         "backingstore" "true"
    Option         "TripleBuffer" "true"
    Option         "AddARGBGLXVisuals"  "true"
EndSection

Hope this will be useful for you as well :-).

Update: If you’re still suffering these problems even after adding these lines to xorg.conf, you could try to install the nvidia driver through Envy. These steps worked for me (at the end, the annoying problem appeared again, although not so often than before):

1. Uninstall any other driver you had installed before (through the ubuntu "restricted drivers" manager, or the .run script downloaded from nvidia.com).
2. Install Envy: apt-get install envyng-core
3. Shutdown X and install the nvidia driver from a tty terminal: envyng -t

Let’s see if these new advice helps you too :-)

1. Attached 500Gb 2,5" HD (powered through its USB2.0 connector).
2. MediaTomb uPnP media server, to keep a nice "media center" running always available.
3. Samba filesharing server (to easily share files with any device connected to the LAN)
4. rtorrent bitTorrent client, to use the Slug as a dedicated machine always up and ready to download whatever you want.
5. The 'screen' command line utility (useful to easily keep the rtorrent app always running and "detachable" ;-)).
6. OpenSSH server (ssh port forwarded in the router to access the Slug from the Internet), to easily manage my Slug from anywhere in the world.

But all this was kind of “incomplete” stuff until I got a PS3, as a present from my girlfriend during last Christmas holidays, which gave it a new dimension to the Slug, since the PS3 bundles a nice uPnP client for pictures, audio and video which works perfectly with the MediaTomb server installed in this cute device.

The point now is that I no more need to copy the video files I download with my Slug to another device (a desktop PC, a laptop…) to watch them, either in such a device or in the TV (with the help of a multimedia HD)… all I need to do is just:

1. Have the MediaTomb server continuously running in the Slug, watching (through its inotify feature) to the /storage/videos directory for new videos (I want it to index them whenever I copy new downloaded videos under that path).
2. Have the PS3 connected to the local network, either through it's wired or wireless interface.
3. Move the video files, as soon as they get fully downloaded, from my /storage/downloads path into /storage/videos

Of course, you can also do the same with regular pictures or audio files (which is very nice also if you have, like me, the PS3 audio output also plugged into a Hi-Fi), but I think you’ll agree with me that watching video files seems to be the best way to make the most of the Slug+Ps3+TV combo :-).

And that’s all, I think… just to mention I’ve written this post while I was listening to a nice Thin Lizzy album ("Dedication") stored in the Slug, through the PS3 and my Hi-Fi equipment. It sounds good, doesn’t it? :-)

PS: One of these days I’ll post more in detail how to set up the configuration for all the components I’m currently using in my Slug (rtorrent, Samba, MediaTomb…), just in case someone found it useful.

To do that, I just followed the instructions that Berto had posted some months ago in his blog, either for encrypting full regular partitions with LUKS as for encrypting temporary filesystems, say, /tmp and swap partitions.

So, once I got those tasks done (quite easy if you follow the steps Berto’s explained in his posts), only one more task was still left: to make those LUKS encrypted partitions to be automatically mounted when logging into the system with my username.

The idea behind this is just that you use the same password both for logging into the system with your username as for decrypting those LUKS partitions before mounting them. To do this, I’ve just used the pam_mount module so it took care of using the user password to automatically mount those partitions right after the user gets identified in the system. And of course, that pam module also takes care of unmounting those partitions right after you log out and no open sessions with your username remains active.

So, I’d like to share with you a recipe to get all this stuff easily working:

1. Follow the steps in Berto's post to encrypt a full partition with LUKS.
2. When you add a LUKS password for that encrypted partition, use the same password you use to log into your system with your username. LUKS allows you to add more than one password for your partitions, so at least one of them should be the same than your user password.
3. Install the pam_mount module:

sudo apt-get install libpam-mount

4. Edit your /etc/security/pam_mount.conf file and append there a line like the following one (one for each encrypted partition you'd like to automatically mount):

volume USERNAME crypt - DEV_FILE MOUNTPOINT - - -

For example, to mount a encripted partition present in /dev/sda6 under a /encrypted folder whenever the user 'mario' logs into the system, you should append the following line:

volume mario crypt - /dev/sda6 /encrypted - - -

5. Edit /etc/pam.d/login so it looks as follows at the end of the file

[...] # Standard Un*x account and session @include common-account @include common-session @include common-pammount @include common-password

6. And, if you use GDM (as me), you should also edit /etc/pam.d/gdm in a similar way:

[...] @include common-account session required pam_limits.so @include common-session @include common-pammount session optional pam_gnome_keyring.so auto_start @include common-password

7. At last make sure that you have removed (or commented) some lines in /etc/fstab and /etc/crypttab, in order to avoid both asking for the LUKS password at startup (because the crypttab file) as trying to mount a not decrypted partition (because of fstab). For instance, this is how those files would look for the example given:
• /etc/crypttab:

#encrypted /dev/sda6 none luks,check=ext2 cswap /dev/sda8 /dev/urandom swap ctmp /dev/sda9 /dev/urandom tmp

• /etc/fstab:

[...] #/dev/mapper/encrypted /encrypted ext3 defaults 0 2 [...]

Once you have followed all those steps, you should be able to reboot and see how the encrypted partition gets mounted right after you login in your system, either by using GDM as by using a text-mode terminal.

And that’s all. I hope you find it useful.

]]>