technikhaufen

dd can not count

nospam@example.com (Michael Gebetsroither) — 2008-06-15T16:36:43Z

How much is 5*1kB?

128Byte as of dd.

% strace -e read,open dd if=/dev/random of=foo bs=1k count=5

open("/dev/random", O_RDONLY|O_LARGEFILE) = 0
read(0, "\347P\203\355\206O;\362f\263v{s\327\206\354\302{\21\5\203"..., 1024) = 96
read(0, "U\16ee\330\304\264@", 1024)    = 8
read(0, "\316\26\363\\\26j\377\10", 1024) = 8
read(0, "K\331.\273,\200\4\234", 1024)  = 8 
read(0, "\2312\323/\304\376\n\261", 1024) = 8
0+5 records in
0+5 records out
128 bytes (128 B) copied, 2.85809 seconds, 0.0 kB/s

Seems 128bytes are quite less than the requested 5kB.

% man 2 read

RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of
file), and the file position is advanced  by this  number. It is not an
error if this number is smaller than the number  of  bytes  requested; ...

dd_rescue to the rescue

% dd_rescue -m 1k /dev/random foo

Summary for /dev/random -> foo:
dd_rescue: (info): ipos:         1.0k, opos:         1.0k, xferd:         1.0k
                   errs:      0, errxfer:         0.0k, succxfer:         1.0k
             +curr.rate:        0kB/s, avg.rate:        0kB/s, avg.load:  0.0%

% ls -la foo

-rw-r----- 1 einstein einstein 1024 2008-06-15 18:35 foo

At lest dd_rescue is able to count correct.

When svn really hates you

nospam@example.com (Michael Gebetsroither) — 2008-06-13T09:04:13Z

As my colleagues don't know either git or mercurial, we decided to use subversion for our collaboration. This was a big mistake as it seems.

We have a strict deadline to meet and the following is something you really don't want to read a few days before the deadline.

I'm normally using git-svn, but this time i have to check in quite a few files, so i thought about using svn directly.

And this is the result:

svn: REPORT request failed on '/svn/eegs08/!svn/vcc/default'
svn: REPORT of '/svn/eegs08/!svn/vcc/default': 200 OK (https://svn.tugraz.at)

After that i can't commit new files anymore, nor checkout another revision.

Even a complete new checkout doesn't help:

% svn co

...
A    AG01/RaytracerG01/RaytracerG01/TokenCmdCreateDirLight.h
svn: REPORT request failed on '/svn/eegs08/!svn/vcc/default'
svn: REPORT of '/svn/eegs08/!svn/vcc/default': 200 OK (https://svn.tugraz.at)

and thats it, the repository is dead.

This is where git-svn comes in:

So i've just deleted this damn svn repository on the server and repopulated it with the default layout (trunk, tags, branches).

% mv repo repo~
% git svn clone -s <REPO> repo
% cd repo
% git fetch ../repo~ master:old
% git rebase master old
% git svn dcommit

After that i had a working repository on svn again :)!

Installing chrooted scponly on debian64

nospam@example.com (Michael Gebetsroither) — 2008-05-01T20:41:20Z

Install

apt-get update
apt-get install scponly

Configure

Reconfigure scponly to do chrooting.

dpkg-reconfigure scponly

Setup chroot

Debian has a script to help you with this task, but it's not without problems.

cd /usr/share/doc/scponly/setup_chroot
gunzip setup_chroot.sh.gz
sh setup_chroot.sh
> maybe use in/ instead of incoming/ ;)

Fixing chroot made by the script

And there are the problems:

The chroot is not working
Chroot is not updated as setup_chroot.sh just use cp

The first is not that hard to fix:

cp /lib64/ld-linux-x86-64.so.2 /home/scponly/lib
ln -s lib /home/scponly/lib64
mkdir /home/scponly/dev
cp -a /dev/null /home/scponly/dev

Fix for Winscp and some other clients

Compile this small programm to groups and copy it to /home/scponly/bin.

#include <string.h>
main()
{
        const char out[] = "root users\n";
        write(1, out, strlen(out));
        return 0;
}

diet gcc -O2 -s groups.c -o groups
cp groups /home/scponly/bin

Done

There is now a fully working chrooted scponly environment.
To upload something:

scp <FILE> scponly@<HOST>:in/

In my next post i'll descibe a possible solution for a chroot setup without any hassels and need to keep it in sync with the host-system.

Installing gitosis on debian

nospam@example.com (Michael Gebetsroither) — 2008-03-31T18:09:18Z

ATTENTION:

current gitosis debian package does a chmod -R git:git /var/cache/git, if you allready have a git repository setup be c arefully! #473574

Install

apt-get update
apt-get install gitosis

This creates a user git with /var/cache/git as $HOME (which is also the default directory for git-daemon to serve). I've changed this to the normal /home/git as i want gitosis only for non-public projects.

Initialise

% su git
$ gitosis-init </tmp/id_rsa.pub 
Initialized empty Git repository in ./
Initialized empty Git repository in ./

Configure

% git clone git@localhost:gitosis-admin.git
% cd gitosis-admin

see gitosis documentation if you need further help on configuration or http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Problems:

ssh git@localhost:
```
Mar 31 14:27:06 god sshd[27051]: User git not allowed because account is locked
```
If you encounter something like this then you should update your adduser packet because it is broken. #433639
Fix: change the ! in /etc/shadow in the line of your git user to *.
gitosis config is not updated after push:
```
chmod 755 $(readlink ~git/repositories/gitosis-admin.git/hooks/post-update)
```
The post-update hook is not executable and is a link on debian (#473613), the above should temporarily fix this.

Create a bootable FreeDOS usb-stick

nospam@example.com (Michael Gebetsroither) — 2008-03-27T14:44:05Z

I needed to upgrade the bios of my Computer (Intel).

But how to do it without windows?

In my case, Intel has many options for bios upgrading and one is the plain old DOS method. This is the best and fastest way to upgrade your bios with linux.

Create a FreeDOS based bootable usb-stick

Download a FreeDOS image, i'll use Balder for now.
Prepare the usb-stick
- check partition (e.g cfdisk /dev/sda)
- mkfs.msdos /dev/sda1

Commands

qemu -boot a -fda balder10.img -hda /dev/sda
A:\> sys c:
A:\> xcopy /E /N a: c:

Check with

qemu -hda /dev/sda

All GRML uses should also take a look at http://wiki.grml.org/doku.php?id=biosupdate which provides a nice overview.

That's it!

Intel 965 board with 8GB Ram and Linux

nospam@example.com (Michael Gebetsroither) — 2008-03-27T13:19:26Z

I thought upgrading from 4 to 8GB would be painless, as i am allready using 64bit GRML (debian).

But i was wrong!

System

Board: Intel DG965WH
Memory: 4x 2GB Kingmax DDR2 800
OS: GRML, 2.6.23-grml64 (which is based on 2.6.23.16)

Installation and memtest went fine (4 runs without errors) and as soon as i boot into linux the computer speed went to a crowl.

The problem is a wrong memory mapping from newer Intel bioses:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size=   1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 (bogus)

After some fiddling and searching i've found a reasonable solution:

64MB ram are lost because we would need one more mapping.
Special bootparameter is needed
Manual adjusting of /proc/mtrr

Quick and dirty

For 8GB ram append mem=8832M to your boot cmdline.

Adjust memory mapping as soon as possible in your boot process (should be done before udev starts, /etc/init.d/bootlocal.first if it's available on your system, don't forget to mount /proc if it's not allready mounted).

echo "disable=7" > /proc/mtrr
echo "base=0x220000000 size=0x8000000 type=write-back" > /proc/mtrr

This creates the missing 128MB mapping at the end. There would be another mapping with 64MB right after our new one, but that is disabled through our special mem= boot cmdline option.

The corrected mapping

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size=   1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg07: base=0x220000000 (8704MB), size= 128MB: write-back, count=1

Con

After some time searching for a solution and a not really helpfull intel tech support these provided me with a now again useable system. Now with 8GB ram!

Let the fun begin

nospam@example.com (Michael Gebetsroither) — 2008-03-27T00:58:20Z

This is my first entry.

From now on i'll post all interesting problems i've solved. Beside all of my thoughts which might also find the way into this blog ;).