Back in 2008 I wrote a small article about resizing LVM physical volumes. I had to do something similar, but slighly more complicated, recently. My /usr logical volume (LV) was getting full on my laptop disk, thus I wanted to shrink another LV and move some of that space to /usr. Here's one way you can do that.
Requirements: a Live CD containing all required utilities (cryptsetup, LVM tools, resize2fs), I used grml.
Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!
First, shutdown the laptop and boot using the Live CD. Then, open the dm-crypt device (/dev/hda3 in my case) by entering your passphrase:
$ cryptsetup luksOpen /dev/hda3 foo
Activate all (newly available) LVM volume groups in that encrypted device:
$ vgchange -a y
(maybe you also need a vgscan and/or lvscan, not sure)
Check how much free space we have for putting into our /usr LV:
$ vgdisplay | grep Free Free PE / Size 0 / 0
OK, so we have none. Thus, we need to shrink another LV (/home, in my case) and put that newly freed space into the /usr LV. In order to do that, we have to check the current size of the /home LV:
$ mount -t ext3 /dev/vg-whole/lv-home /mnt $ df --block-size=1M | grep -C 1 /mnt $ umount /mnt
(if you know how to find out the size of an ext3 file system without mounting it, please let me know) Update: See comments for suggestions.
Write down the total amount of 1M chunks of space on the file system (116857 in my case), we'll need that later. Now run 'fsck' on the /home LVM logical volume, which is needed for the 'resize2fs' step afterwards. This will take quite a while.
$ fsck -f /dev/vg-whole/lv-home
Next step is resizing the ext3 file system in the /home LVM logical volume, making it 1GB smaller than before (of course you must have >= 1 GB of free space on /home for that to work). We use fancy bash calculations to do the math.
Note: I'm not so sure about the sizes here, in my first attempt something went wrong and resize2fs said "filesystem too small" or the like. Maybe I'm confusing the size units from 'df' and 'resize2fs', or the bash calculation goes wrong? Please leave a comment if you know more!
$ resize2fs /dev/vg-whole/lv-home $((116857-1024))M
Then, we can safely reduce the LV itself. Note: order is very important here, you must shrink the ext3 filesystem first, and then shrink the LV! Doing it the other way around will destroy your filesystem!
$ lvreduce -L -1G /dev/vg-whole/lv-home
Now that we have 1 GB of free space to spend on LVs, we assign that space to the /usr LVM logical volume like this:
$ lvextend -L +1G /dev/vg-whole/lv-usr
As usual, we then run 'fsck' on the filesystem in order to be able to use 'resize2fs' to resize it to the biggest possible size (that's the default if resize2fs gets no parameters):
$ fsck -f /dev/vg-whole/lv-usr $ resize2fs /dev/vg-whole/lv-usr
That's it. You can now shutdown the Live CD system and boot into the normal OS with the new space allocations:
$ vgchange -a n $ cryptsetup luksClose foo $ halt
I've been planning to write about building custom ARM toolchains for a while (I used stuff from gnuarm.com in the past, but I switched to the lastest and greatest upstream versions at some point). Among other things, recent upstream versions now have ARM Cortex support.
First you will need a few base utilities and libs (this list may not be complete):
$ apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential
Then you can use my tiny build-arm-toolchain script, which will download, build, and install the whole toolchain:
$ cat build-arm-toolchain #!/bin/sh # Written by Uwe Hermann <email@example.com>, released as public domain. [...]
The final toolchain is located in /tmp/arm-cortex-toolchain per default, and is ca. 170 MB in size. I explicitly created the build script in such a way that it minimizes the amount of disk space used during the build (ca. 1.2 GB or so, compared to more than 3 GB in the "naive" approach).
Using the "-j 2" option for make (see script) you can speed up the build quite a bit on multi-core machines (ca. 30 minutes vs. 60 minutes on an AMD X2 dual-core box). Also, you can change the script to build for other target variants if you want to (arm-elf or arm-none-eabi, for example).
Oh, and while I'm at it — does anybody have any idea why there are no pre-built toolchains for embedded (microcontroller) ARM targets in Debian? There are some toolchains for other microcontroller architectures (avr, m68hc1x, h8300, z80) but not too much other stuff. Is there some specific reason for the missing ARM toolchains (other than "nobody cared enough yet")?
I have heard about Emdebian, but from a quick look that seems to be more intended for toolchains with Linux/libc, not for microcontroller firmware (i.e. no MMU, no Linux, no libc etc.), but maybe I'm wrong?
Just as a reminder for myself, as I'll probably need this more often in the future (and maybe it's helpful for others):
Per default, if you use a big xterm (232x74 in my case) where you start minicom, the $COLUMNS and $LINES environment variables will be 80x24 nevertheless, and those applications which honor them (vim, for example) will be too small and not use the full xterm size of 232x74.
$ minicom $ echo $COLUMNS; echo $LINES 80 24
You can fix that like this:
$ eval `resize` $ echo $COLUMNS; echo $LINES 232 74
After you do eval `resize` the variables are updated and vim will use the full xterm size. That's all.
I have no idea how such a great open-source game as Teeworlds has been able to exist without me hearing about it until recently.
Teeworlds is a fast-paced realtime multiplayer shooter. You control a small "Tee" which can hold various weapons (hammer, gun, shotgun, laser-rifle, rocket launcher, ninja-sword) while running and jumping around frantically on the map, trying to frag as many other Tees as you can before you're killed by some other guy. Easy, eh?
There's are many game servers to choose from, as well as various game modes (death match, team death match, capfure the flag and some unofficial "mods"). You can join servers on the Internet, or create your own server, be it a public one or a LAN server.
Usually I would suggest apt-get install teeworlds, but for now the packages in unstable are an older 0.4.x version, whereas upstream released a much-improved 0.5.1 version. I have already filed a bug and I'm optimistic there'll be a new version in unstable soon.
In the mean-time however, you can manually build the game from source via:
$ apt-get install zlib-dev libsdl1.2-dev (maybe also libgl, libglu, and python, if not already installed) $ wget 'http://teeworlds.com/trac/bam/browser/releases/bam-0.2.0.zip?format=raw' -O bam-0.2.0.zip $ wget http://teeworlds.com/files/teeworlds-0.5.1-src.zip $ unzip bam-0.2.0.zip $ unzip teeworlds-0.5.1-src.zip $ cd bam-0.2.0 $ ./make_unix.sh $ cd ../teeworlds-0.5.1-src $ ../bam-0.2.0/src/bam release
You'll obviously need a working OpenGL/DRI setup (check if "glxinfo | grep direct" says "Yes"), otherwise the game will be way too slow. In case you experience graphics glitches and distortions, first exit the game, then:
$ vi ~/.teeworlds/settings.cfg
Change the "gfx_noclip 0" option there to "gfx_noclip 1" and restart the game.
If you use a local firewall as I do, you need to open at least ports 8300-8303 (UDP), even better 8300-8310 for more choice in game servers:
$ iptables -A OUTPUT -m state --state NEW -p udp --dport 8300:8310 -j ACCEPT
Stuff I didn't expect I'd had to type today:
$ dpkg-repack dpkg-repack