Category Archives: Systems

On Linux32 chrooted environments

Published July 3, 2015 / by mario / 2 Comments on On Linux32 chrooted environments

I have a chrooted environment in my 64bit Fedora 22 machine that I use every now and then to work on a debian-like 32bit system where I might want to do all sorts of things, such as building software for the target system or creating debian packages. More specifically, today I was trying to build WebKitGTK+ 2.8.3 in there and something weird was happening:

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!

Screen redrawing problems with the “nvidia” driver and Compiz

Published February 18, 2009 / by mario / 10 Comments on Screen redrawing problems with the “nvidia” driver and Compiz

Just in case you were experiencing, like me, some very annoying problems with your NVIDIA graphic card while using Compiz, here you have a very useful option to put inside the “Device” section in your /etc/X11/xorg.org file:

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

After following these steps, and the simple instructions on screen, by ubuntu hardy perfectly booted up with the nvidia driver v173.14, which seems not to present the same problem.

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

My Slug, my PS3 and me

Published January 27, 2009 / by mario / 6 Comments on My Slug, my PS3 and me

As Juan, I’m one of the proud owners of a Linksys NSLU2 (aka Slug) perfectly (and continuously) running the Debian/NSLU2 distribution for more than 6 months, currently featuring the following configuration (both sw and hw), after some slightly changes:

  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.

With the exception of the HD (which used to be a 3,5″ 120Gb HD since June to December, when I replaced with the 500Gb one), the rest of the configuration was amazingly working with no problems at all for more than 6 months, as I previously stated. This, along with the fact that this  device is quite small, noise-and-heat-free (no fans) and only needs 8W (it’s the 266Mhz, ‘underclocked’ version) to work, makes it one of my favourite devices I ever had :-).

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

This way, just by the moving the downloaded media files as explained in (3), and waiting a couple of minutes for the MediaTomb to index them, I have that media content available to be directly watched in the TV, which is really cool and very handy, by the way :-)

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.

Automatically mounting LUKS encrypted partitions with pam_mount

Published March 8, 2008 / by mario / 2 Comments on Automatically mounting LUKS encrypted partitions with pam_mount

Yesterday I’ve got my new Thinkpad T61 laptop and I had to spend some time installing a GNU/Linux distribution on it, so doing all those related tasks that are a must: partitioning, installing linux, installing emacs… and besides to all those tasks a very important one: encrypting some disk partitions.

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:

    4. 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):

    5. 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

    6. […]
    # 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:

    7. […]
    @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.