ZFS und Linux
Bis jetzt ja nur als FUSE “Plugin” … das hier könnte aber interessant werden:
http://insidehpc.com/2010/06/08/livermore-lab-bellies-up-to-native-zfs-linux-port/
Bis jetzt ja nur als FUSE “Plugin” … das hier könnte aber interessant werden:
http://insidehpc.com/2010/06/08/livermore-lab-bellies-up-to-native-zfs-linux-port/
When trying to compile a 2.6.33 kernel on Ubuntu nowadays, you’ll run into this problem:
The UTS Release version in include/linux/version.h
""
does not match current version:
"2.6.33-<appended-string>"
Please correct this.
This would not be soo bad, if it wouldn’t fail after compiling (and by that wasting a lot of cpu time …).
To avoid this error, fix the file /usr/share/kernel-package/ruleset/misc/version_vars.mk
And replace this code
UTS_RELEASE_HEADER=$(call doit,if [ -f include/linux/utsrelease.h ]; then \ echo include/linux/utsrelease.h; \ else \ echo include/linux/version.h ; \ fi)
with this one
UTS_RELEASE_HEADER=$(call doit,if [ -f include/generated/utsrelease.h ]; then \ echo include/generated/utsrelease.h; \ elif [ -f include/linux/utsrelease.h ]; then \ echo include/linux/utsrelease.h; \ else \ echo include/linux/version.h; \ fi)
(Source: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561569 )
It’s been a while since I unsuccessfully tried to use the camera of my Nokia E71 as a video-source for the Thinkpad T500 running Ubuntu 9.10. I did some test with smartcam half a year ago where I successfully got the picture transmitted via bluetooth to the T500 but Skype would not recognise it as a video-source. As I updated the kernel as well as Skype (now running 2.1.0.47) I recompiled the kernelmodule again using a patch from the ubuntu-forum (and not my own crapy fix) – and guess what – it works. The picture is all redish and you can only squeeze a 320×240 picture with roughly 9 fps through the bluetooth-”line” – but at least you get a picture. Nothing compared to the MacBook built-in cam I was testing it with – but way cooler as I can freely move the cam around without moving the notebook. And of course its way more geeky with all the kernelmodule patching and compiling involved.
Here’s the link to the patch with a short howto to get it working: ubuntu-forum-smartcam
Willi
Es ist wieder mal soweit die 12. Chemnitzer Linuxtage stehen ins Haus. Alle sind eingeladen am 13. und 14. März ins Chemnitzer Hörsaalzentrum auf der Reichenhainer Straße in Chemnitz zu kommen. Die zwei Tage stehen dieses mal unter dem Motto “Dienste und Dämonen“.
weitere Informationen unter: http://chemnitzer.linux-tage.de/2010/info/?cookielang=de

Die Aufgabe ist nicht besonders spannend: “Ein 32 Bit Debian Linux per USB-Stick auf ein Intel Atom 330 System (64 Bit) zu installieren”. Das das Ganze allerdings so viele Probleme machen kann, hätte ich nicht geglaubt. Vorab sei noch gesagt, das eine 64 Bit Version absolut Problemfrei funktioniert hat.
Wie man einen bootfähigen USB-Stick mit einer Debian Installation erzeugt, sei hier unterschlagen, dazu gibt es genügend Tutorials im Internet. Für Debian gibt es da eine Datei namens boot.img.gz was man mittels zcat auf den Stick überträgt. Beim booten stellt man recht früh fest, das der Installer kein Install-ISO findet.
Nun gut, sicher mein Fehler. Nach kurzer Recherche, um sicher zu gehen, einfach die mini.iso Datei mit auf den Stick kopiert – Neuversuch. Fail! Selber Fehler. Nach ein wenig rumprobieren stellt man also fest, das iso-scan zwar besagte Datei findet, aber meint das es sich nicht um eine Debian-Installation handelt. Blödsinn!
Also weiter rumprobieren mit diversen Versionen aller möglichen Dateien von Kernel bis hin zu Initrd … kein Erfolg. Als letzter Strohalm hab ich mir mal den Inhalt von mini.iso angeschaut und bis auf wenige Dateien sah das Bild genau so aus wie der Inhalt meines USB-Sticks. OK, also den Inhalt des ISOs auf meinen Stick kopiert und alles überschrieben. (Es dreht sich wohl sicher alles um die Dateien *isolinux*.) Siehe da, es geht!
Blöderweise hat das Zusammenspiel von Hardware und Software mir dann doch noch ein Bein gestellt. Beim ersten Reboot steht im GRUB hd(1,0) statt hd(0,0) und sdb3 statt sda3. Blöd nur, das dass eigentlich der USB-Stick wäre
Es hat dabei übrigens keinen Unterschied gemacht, ob der Stick angesteckt war oder nicht (Reihenfolge der Bezeichnung durch BIOS geändert, wäre plausibel für den Fehler) und wärend der Installation wurde auch korrekt auf sda instaliert…naja, Wayne… menu.lst und fstab angepasst und fertsch.
Das Ganze scheint wohl öffter aufzutreten, zumindest ist dieser BUG-Report meinem Problem sehr ähnlich, da auch bei mir das Unmounten Probleme gemacht hat.
In the life of an IT-guy you often shake your head and smile while wondering about the current problem or its solution. So after a while not much can realy surprise you. But last week there was such a rare moment.
The problem is an easy one: we could not execute binaries. We have a cluster here with an 32 bit head node and 64 bit compute nodes both x86 Debian GNU Linux. The stuff to be shared comes over a NFS. Heterogenouse clusters have some difficulties because you cannot execute binaries from one architecture on another. This will fail with the error message: “wrong ELF format”.
Our problem first appeared by using the Modules-tool. For testing we executed it directly:
./modulecmd -bash: ./modulecmd: no such file or directory
But OK, as everybody could see, it was. We checked and changed the rights for users, groups, owndership, parent directories etc. Nothing helped. Next we put an eye on NFS. No miss-configuration or other distinctive feature.
Now we use the bigger weapons and strace the command.
strace ./modulecmd
execve("./modulecmd", ["./modulecmd"], [/* 25 vars */]) = -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff4b4700000
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or dir"..., 40strace: exec: No such file or directory
) = 40
close(3) = 0
munmap(0x7ff4b4700000, 4096) = 0
exit_group(1) = ?
Also nothing surprising in here.
The further isolate the root of the behaviour, we code a short “hello world” in C and do compiling and execution and it worked. So here we got the main point which confused us. Self created binaries and all system tools worked properly, just the shared ones or let’s say “not system contained” executables failed.
OK, maybe it’s situated in a deeper level. We installed dash and try to execute it in there. No changes. Slowly but steady we ran out of ideas.
From the strace run we could see that execve backfired. This command overwrites the current forked process with the binary given by a path as an argument and executes it. So maybe the reason belongs to the execution context. We tried

instead. So WTF? After ignoring some charset ideas in mind, we arrived where we started. An obligatory file on a system executable and our binary shared over NFS told us the wrong ELF type. The installation of ia32-libs fixed the problem finally, but why there was a “no such file of directory” instead of a “wrong ELF type” we still do not know.
You are welcome to give us solution or hints.
The tiny tool time everybody should know, measures execution time of a given command. For example:
time echo "test"
prints time information to the console. But what if you want to collect these statistics in a file? Linux man page say “-o FILE” is the way to do so. This will look like
time -o file.log echo "test"
This FAILS not only on my machine with the error message “bash -o: unknown command” or equal. The key is to give the full path:
/usr/bin/time -o file.log echo "test"
The problem is, that “time” is used for different things. This leads to another cute tool called type. type gives information about the kind of a command.
type -a time time is a shell keyword time is /usr/bin/time
As you can see “time” not only means the command. If somebody knows more about the “Why the hell is this so?”, feel free to post
I think we all know the problem: a ssh session hangs for some reason, either because you are no longer connected to that wifi or because the remote host just crashed.
A more elegant solution than closing your local term (or killing the ssh client) consists of a well hidden feature:
by sequentially pressing the three keys Return ~ . you can exit the client and return to your local prompt.
[ctrl]+[alt]+[backspace] does not work anymore – to get it back add this to your xorg.conf:
Section "ServerFlags" Option "DontZap" "False" EndSection
Here are all the release notes: http://www.ubuntu.com/getubuntu/releasenotes/904
Recent Comments