Encrypted rootfs on MeeGo 1.1 netbook

I promised my scripts to encrypt the rootfs on my Lenovo Ideapad running MeeGo 1.1. It's currently just a dirty hack but thought it could be nice to share it with you.

My scripts uses cryptoloop. Unfortunately MeeGo 1.1 netbook stock kernel didn't support md_crypt so that was a no go. Of course I could compile the module myself but I wanted out-of-the box solution.

Basic idea is to create custom initrd and use it. My solution needs Live USB stick to boot and do the magic. Also another USB drive is needed to get the current root filesystem in safe while encrypting the partition. I don't know if it's possible to encrypt "in place" meaning to use two loopback devices. However this is the safe solution.

For the busy ones, just boot the MeeGo 1.1 Live USB and grab these files:

http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/crypt_hd.sh
http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/mkcryptrd.sh

Then:

chmod a+x crypt_hd.sh mkcryptrd.sh
su
./crypt_hd.sh

And follow the instructions.

The ones who have more time and want to double check everything, please follow instructions at: http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/README

This solution has at least one drawback. Once the kernel updates you have to recreate the initrd. For that purposes I created a tiny script than can be run after kernel update:

http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/update_initrd.sh

That script also needs the mkcryptrd.sh script above.

Of course that may break your system at any time, so be warned.

For my Lenovo Ideapad S10-3t and MeeGo 1.1 netbook it worked fine. My test case was to make very fresh installation first from the Live/installation USB. Boot again and setup the cryptoloop from Live USB. After that I could easily boot my crypted MeeGo 1.1. It asks password in very early phase of boot process. After it's written correctly the MeeGo 1.1 system should boot up normally.

This worked for me, and I give no guarantee that this works for you. However you're welcome to send patches and improvements.

UPDATE 29.11.2010:
Some people have reported problems when they have different kernel version than on Live USB. The're unable to boot back to their system. I try to figure out solution for this issue.

My presentation at MeeGo Conference 2010

Finally they uploaded videos of MeeGo Conference 2010 presentations. Here's my presentation, enjoy:
http://conference2010.meego.com/session/meego-system-integration-hardware

Also please note the slides as PDF.

MeeGo on Lenovo Ideapad S10-3t

I was one of the lucky people that received Lenovo Ideapad S10-3t in MeeGo Conference 2010 at Dublin. Of course I'm using MeeGo on that and now I have been playing with it a while.

Unfortunately I needed to reinstall the MeeGo 1.1 and I used the image available at http://meego.com/downloads/releases/1.1/meego-v1.1-netbooks

After some time and multiple reboots the WLAN and Bluetooth stopped working. Little googling revealed that there's something wrong with BIOS/settings. This helped a lot: http://forum.meego.com/showthread.php?t=2011

So just go to BIOS (F2 at boot), reset factory default and save.


Thought that this could be nice machine to take with me when traveling. So In order to use it more productive way I installed LibreOffice.

Actually I downloaded the GNU/Linux 32 bit tar.gz and found RPM:s under that. I was a bit adventurous and created a repository for them.
So did:

tar xzvf LibO_3.3.0_Linux_x86-64_install-rpm_en-US.tar.gz
sudo mkdir -p /usr/local/repos/libreoffice
sudo cp -r LibO_3.3.0beta3_20101115_Linux_x86_install-rpm_en-US/RPMS/* /usr/local/repos/libreoffice
cd /usr/local/repos/libreoffice
sudo zypper install createrepo
sudo createrepo .

After that set up zypper repository for that. Created file /etc/zypp/repos.d/libreoffice.repo:

[libreoffice]
name=libreoffice
enabled=1
autorefresh=0
baseurl=file:///usr/local/repos/libreoffice
type=rpm-md
gpgcheck=0

After that just:

sudo zypper refresh
sudo zypper install libreoffice3-* libreoffice3.3-freedesktop-menus

So this far it has been quite nice to play around with this Ideapad and MeeGo. Another idea was to have the whole rootfs encrypted to protect my data in case I lost the machine. I actually accomplished that and will post scripts and instructions soon!

Inner Qt

Lately I have played a lot with Qt. Generally it's nice and I think it's easy to adapt and get things done. Also the development of Qt have been blazingly fast, new features are implemented and it's going into good direction.

I have taken a closer look to the inner design of Qt. First note was that Qt is just one big collection of code. Of course it's divided into modules like QtCore, QtGui, QtNetwork, QtOpenGL, etc. But when you look the sources you'll see one big drawback: you really can't compile one module without compiling first almost all other modules. Also compiling only few classes or widgets is not possible.

The main reason for Qt being just a big pile of code is heavy usage of private members. In generally private members and classes are good. But somebody has led this into very wrong direction. Totally separated Qt classes uses each others private members/classes directly. That achieved by making the private members protected and listing other classes as friend classes. This leads to degeneration of the code. An extreme example is that QWidget, the very basic class in Qt. Let's see it's sources: qwidget.h. Total number of friend statements in qwidget.h is about 50. However not all of them are really used, but 50? Are you kidding? Then it hits me, what the heck does implementation of QPixmap::fill in qwidget.cpp ?

Another thing that does not fit in my mind is use of QApplicationPrivate. There's lot of use of it in qwidget.cpp. And I really don't get the point why? Why are these not public functions and members in QApplication or QCoreApplication? Of course there's some aspects which supports this kind of approach, but this was just an example. Such usages of private classes and members can be found all over the Qt. For example there's clean cases where private is used even if there's public member which does the same thing.

My point was that Qt is great, but could be even better if the inner design is reviewed and proper modifications made. I mean: using public members, avoiding usage of privates and friend classes and cleaning off all the stupidity. A good test could be: if you take a source files of a widget and compile it outside Qt source tree (compile with public API), does it compile without modifications? For most widgets and classes this should be true. Currently most of the classes fails this test. Of course using privates is ok when it's really needed. But I see no reason using privates so heavily as Qt currently uses.