I encountered this error while trying to mount an image created using qemu. The command from the docs says to run the following command to mount it on the loopback device.
mount -o loop,offset=32256 debian.img ./mntpoint
This is completely wrong because the data start is not 32kb into the image file. To figure out where it starts you need to use the following commands:
]$ fdisk -ul debian.img
you must set cylinders.
You can do this from the extra functions menu.
Disk debian.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00077ccb
Device Boot Start End Blocks Id System
debian.img1 * 2048 5785599 2891776 83 Linux
Partition 1 does not end on cylinder boundary.
debian.img2 5787646 6141951 177153 5 Extended
Partition 2 does not end on cylinder boundary.
debian.img5 5787648 6141951 177152 82 Linux swap / Solaris
Once you have this output you can see that the data starts at sector 2048 and since sector size is 512 on my image I need to set the offset to 512*2048. So the final working command is:
mount -o loop,offset=$((512*2048)) -t ext3 ./debian.img ./mntpoint
and we now have a mounted image file.
I recently had an issue where my keyboard when using synergy was inserting a double arrow instead of the usual greater than or less than sign also known as guillemotleft and guillemotright.
To fix this annoying bug I added
keycode 53 = x X greater greater greater greater
keycode 52 = z Z less less less less
keycode 24 = q Q at at at at
to a .Xmodmap in my home directory. If you are wondering how to find the keycodes etc you can use xev. To start it without restarting X use
I have no idea when or why this started happening for me but I started getting Unrouteable address appearing for any external address.
I’m a huge fan of Debian but there are some things that really piss me off. One is the way they have completely screwed the exim4 configuration. Exim4, if you are not an administrator or mail guru is not the simplest thing in the world to configure, it’s config file is fairly involved and you can do anything in it. Add DEBCONF variables to this and you have a complete nightmare configuration.I spent two days tracking this error down to the following:
That was all I had to add to /etc/exim4/exim4.conf.template
Why this changed I have no idea. The setting I am using in /etc/exim4/update-exim4.conf.conf is
I really cannot make head nor tail out of this at all. I sometimes wish I had started learning Postfix instead of Exim but part of me thinks that it’s not Exim but rather the way it has been packaged up thats compicated.
If you get the above erro then check the following file
$ grep vo_driver $HOME/.mplayer/gui.conf
vo_driver = “xmga”
It should read:
vo_driver = “x11”
I started getting the following error when trying to ssh into a chroot on a debian machine.
stdin: is not a tty
I fixed it using the following entry in /etc/fstab
devpts /dev/pts devpts mode=0620,gid=5 0 0
I’m positive this is not the way I should have fixed it but it works!
The alternaitives system in Debian is a pain in the arse! It’s one of those things that when you need to use it you spend twenty minutes trying to figure out why various paths etc have changed and then you need to figure out the syntax to change to the path that was working before you installed Tomcat or some other related system that downloads a bunch of stuff and sets itself up as default for the rest of the system. It’s a tad irritating.
I am not saying I know a better way to do it but it still pisses me off. Anyway to use a sane version of java I had to run the following command to get eclipse working again.
$:~# update-alternatives –install /usr/bin/java java /usr/local/sdk-5_05/jdk 1
$:~# update-alternatives –list java
$:~# update-alternatives –remove java /usr/lib/jvm/java-gcj/jre/bin/java
I now have eclipse working again and tomcat installed. I was going to use jetty6 over tomcat but because Debian comes bundled with a binary tomcat distribution I have decided to use it. This decision may cost me dearly later.
If you ever run the set command and get any of the function definitions listed at the bottom of this entry then check your .bashrc file for the following entry.
# enable programmable completion features (you don’t need to enable
# this, if it’s already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
If it is not commented out then it is likely that name completion has been activated elsewhere. Comment it out and start a new shell to see if it helps.
Debian have just released sarge as the new stable distribution which means I need to start upgrading my machines. Before I upgraded the main machine though I decided to run through it on a UML machine first to see where the gotchas are.
Things to watch out for
1. The sshd config file gets an extra parameter added to it ie.
When I tested ssh after the upgrade I was unable to log into the machine and I found that I had to remove this option or set it to “no” to get ssh to work. This surprised me because I was not expecting Debian to modify config file without my knowledge.
2. The RECORD option is no longer valid
xinetd: Bad log_on_failure flag: RECORD [file=/etc/xinetd.conf] [line=13]
xinetd: A fatal error was encountered while parsing the default section. xinetd will exit.
this prevents xinetd from starting up. This was also noticed while testing the machine after the upgrade.
What follows is roughly the files the upgrade offered to update to new versions. Since I had modified most of these I selected the default option which is “N” ie do not upgrade to the maintainers version. This may have been the reason the ssh upgrade wasn’t too smooth. However I would not recommend taking the maintainers version if you have customized the files.
Configuration file `/etc/pam.d/login’
Configuration file `/etc/securetty’
Configuration file `/etc/pam.d/passwd’
Configuration file `/etc/bash.bashrc’
Configuration file `/etc/init.d/sysklogd’
Configuration file `/etc/services’
Configuration file `/etc/init.d/bind9′
Configuration file `/etc/bind/named.conf’
Configuration file `/etc/bind/db.root’
Configuration file `/etc/init.d/xinetd’
Configuration file `/etc/xinetd.conf’
During the upgrade you may also be asked to add any users and groups that are
missing from the default debian lot. The following bits are just the output of some other configurations options and warnings of things that have changed between the woody and sarge.
Environment options on keys have been deprecated This version of OpenSSH
disables the environment option for public keys by default, in order to avoid
certain attacks (for example, LD_PRELOAD). If you are using this option in an
authorized_keys file, beware that the keys in question will no longer work
until the option is removed. To re-enable this option, set
“PermitUserEnvironment yes” in /etc/ssh/sshd_config after the upgrade is
complete, taking note of the warning in the sshd_config(5) manual page.
This version of man-db is incompatible with your existing database of manual
page descriptions, so that database needs to be x rebuilt. This may take some
time, depending on how many pages you have installed; it will happen in the
background, possibly slowing down the installation of other packages. If you do
not build the database now, it will be built the next time
/etc/cron.weekly/mandb runs, or you can do it yourself using ‘mandb -c’ as user
‘man’. In the meantime, the ‘whatis’ and ‘apropos’ commands will not be able to
display any output. Incompatible changes like this should happen rarely. Should
mandb build its database now?
So far I have upgraded two machines and had the same trouble with ssh and xinetd both times. If I encounter any mmore trouble I will add more here.
I have never seen the oom-killer before. I had heard stories from battle hardened veterans about their tussles with the beast but these stories where all just myths to me, until today, when the beastie raised its head in my logs.
Dec 20 18:08:50 debian kernel: oom-killer: gfp_mask=0x1d2
59071 Dec 20 18:08:51 debian kernel: DMA per-cpu:
59072 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 2, high 6, batch 1
59073 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 2, batch 1
59074 Dec 20 18:08:51 debian kernel: Normal per-cpu:
59075 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 32, high 96, batch 16
59076 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 32, batch 16
59077 Dec 20 18:08:51 debian kernel: HighMem per-cpu:
59078 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 14, high 42, batch 7
59079 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 14, batch 7
59080 Dec 20 18:08:51 debian kernel:
59081 Dec 20 18:08:51 debian kernel: Free pages: 1040kB (112kB HighMem)
59082 Dec 20 18:08:51 debian kernel: Active:253987 inactive:249 dirty:0 writeback:5 unstable:0 free:260 slab:2326 mapped:254 013 pagetables:680
59083 Dec 20 18:08:52 debian kernel: DMA free:16kB min:16kB low:32kB high:48kB active:12296kB inactive:0kB present:16384kB
59084 Dec 20 18:08:52 debian kernel: protections: 0 0 0
59085 Dec 20 18:08:52 debian kernel: Normal free:912kB min:936kB low:1872kB high:2808kB active:873984kB inactive:996kB prese nt:901120kB
59086 Dec 20 18:08:52 debian kernel: protections: 0 0 0
59087 Dec 20 18:08:52 debian kernel: HighMem free:112kB min:128kB low:256kB high:384kB active:129668kB inactive:0kB present: 131008kB
59088 Dec 20 18:08:52 debian kernel: protections: 0 0 0
59089 Dec 20 18:08:52 debian kernel: DMA: 0*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096k B = 16kB
59090 Dec 20 18:08:52 debian kernel: Normal: 0*4kB 0*8kB 1*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*40 96kB = 912kB
59091 Dec 20 18:08:52 debian kernel: HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4 096kB = 112kB
59092 Dec 20 18:08:52 debian kernel: Swap cache: add 848298, delete 845230, find 151472/187493, race 0+3
59093 Dec 20 18:08:52 debian kernel: Out of Memory: Killed process 6332 (postmaster).
It would appear I was being a bit greedy with Postgres.
I lost my internet connection at the weekend and was at a bit of a loss as to what I could do so I decided to take a pop at writing a simple module for the Linux kernel. I have a copy of
Beginning Linux Programming
Authors: Richard Stevens and Neil Matthew
so I turned to the back of it and started my foray into the Kernel. Now you need to remember that I am not a C programmer by trade and turning to the back of this book was a keen reminder of just how rusty my C is getting, not that it was ever rust free.
Luckily for me I have another book that is considered the C bible ie K&R and it deserves its reputation, it is a classic and I would recommend any programmer regardless of language choice to have a flick through it. When I was looking at some odd construct that those pointy hats had invented I had a flick through K&R and soon sorted it out.
Anyway back to the kernel. I was quick to discover that writing a module for the 2.6 kernel is not quite as straight forward as copying from the book and trying to understand what was going on. Things have been changing and I was getting all sorts of weird (or at least to me) and wonderful errors when trying to compile the kernel.
I eventually started to have a read at the recent modules in the source for 2.6.5 which I am running on this box. I also have the source for a 2.4 kernel on here so I opened 2 character drivers and compared notes between them. This is where I started to notice things that had changed. I made the changes I thought where necessary and I managed to get most of the “Hello World” module compiling but I was still getting errors.
I had a hunt around and I found a reference to some new build procedures for 2.6.5 so off I went in search of kbuild documentation and found some more stuff that had changed in the kernel. Namely the build procedure. This part was actually harder than the C that I had been struggling with.
After much swearing (I hate Makefiles and adding some more sugar is a pain in the ass) I managed to get the module compiling and I was on my way.
After a days work I now had a module that, on load would say
and on removal
time well spent or not? I haven’t decided yet. I wonder how often changes like this take place in the kernel and how much porting takes place because of it.
Where to go from here. I asked a few friends who know more about this stuff than I do and I got mixed advice about continuing. Some of them think the kernel is a mess because they are always changing the driver API among other things. I cannot comment because my knowledge of the Linux kernel is limited to spelling it and I sometimes get that wrong.
I did get some useful pointers though. The following is the best book I have found so far for someone like me who is just starting out in the kernel.
Linux Device Drivers, 2nd Edition
It is written for the 2.4 kernel but has a wealth of information that is still valid today. I have started porting the scull drivers from this to the 2.6 kernel I am running and it is proving very interesting. I printed off chapter 2 and 3 yesterday and have have almost finished them (40 mins from Luton to London on the train each way helps). So far it seems to be moving along at a fair old pace, I am just hoping I can keep up.
I could have done with the following at the weekend. This tells me what I needed to know about moving from 2.4 to 2.6. I can see myself using this a lot in the next few weeks.