The official Debian kernel building tools are a thing of wonder. But, it didn’t do what I wanted, which was to build the exact version of the kernel that I’m running. I guess it is only ever used to build the latest version.
Also, reportbug failed (it was unable to get the list of open bugs for this package from the Bug Tracking System) — I used debian-bug in debian-el package (as noted at the bottom of this page). To actually send the mail, use ctrl-c ctrl-s in the mail buffer (or ctrl-c ctrl-c if you want to send the email and exit emacs).
Maybe I misunderstood … maybe the -5 is not the patch level I’m aiming for. We shall see.
No, the -5 is the “ABI” level, and has nothing to do with the Debian patch level. So there was no bug. I was supposed to build with all the patches. Live and learn …
X starts and promptly exits.
But only under the Xen Hypervisor.
This time the keyboard device is there even under the hypervisor, but xinit “cannot invoke xkbcomp” under the hypervisor. It’s there in /usr/bin/xkbcomp, but xinit cannot “invoke” it under the hypervisor while it can invoke it when it’s not running under the hypervisor. Mysterious.
If you want to have an identd that can talk IPv6, you can choose oidentd.
If you are running it from inetd, you should configure your inetd to respond to IPv6 as well. I’m using openbsd-inetd, and the lines in /etc/inetd.conf to make it listen on both IPv4 and IPv6 for the auth service are:
auth stream tcp4 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I auth stream tcp6 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I
Note the protocol, which specifies IPv4 or IPv6. Also note the -I option to oidentd, to make it read from stdin and write to stdout and to exit after answering one request (needed for inetd operation).
I briefly considered nullidentd, but the description made it sound like it would only ever return one static string. Not quite what I was looking for, and I didn’t investigate further.
I found this procedure for starting to use IPv6 on a home network. It is specific to Debian and the SixXS tunnel broker. Many thanks to Martin Krafft for this very nice description that starts with the firewall rules and moves on from there.
I’m trying to run xen 4.0 but it’s not working, It seems that the input devices (keyboard and mouse) are not being supplied to the linux kernel from the xen hypervisor.
I’m keeping this here for easy reference.
I apt-get upgraded, and then apt-get using apt-cacher didn’t work any more. It seems if you have a perl IPv6 library installed (IO::Socket::INET6), apt-cacher will assume you have deployed IPv6 and it will make an IPv6 only connection for listening.
To make all your services obtain IPv4 address along with IPv6 ones, as root “echo 0 > /proc/sys/net/ipv6/bindv6only” and edit /etc/sysctl.d/bindv6only.conf to contain 0 rather than 1. Then restart your service(s).
Or if you do have IPv6 running locally, you can change your apt sources.list file (/etc/apt/sources.list) to refer to ipv6-localhost instead of localhost:
deb http://ip6-localhost:3142/debian.mirror.iweb.ca/debian/ unstable main contrib non-free deb-src http://ip6-localhost:3142/debian.mirror.iweb.ca/debian/ unstable main contrib non-free
(other distro’s might use another name like localhost6. Look in your /etc/hosts file for the right name.)
Another gotcha: If you install apt-cacher-ng, and you already have apt-cacher running, then apt-cacher-ng will attach to the remaining free interface (the IPv4 one) and apt-cacher will still be running on IPv6. The two packages don’t conflict. Yeargh. I can’t wait to see the cache corruption … Ah, no cache corruption. It starts its own cache — from scratch. Well better that than corruption I guess. But, even better to be running only one of them on all listening ports.
And another gotcha: Installing apt-cacher-ng might end up adding a proxy config to your apt config like so:
/etc/apt/apt.conf: Acquire::http::Proxy "http://aa.bb.cc.dd:3142";
so then if you use urls as above, you would have specified the proxy twice: once in the url and once in the apt.conf file. Apt then complains with:
Failed to fetch http://aa.bb.cc.dd:3142/volatile.debian.org/debian-volatile/dists/lenny/volatile/contrib/source/Sources.gz 403 URL seems to be made for proxy but contains apt-cacher-ng port. Inconsistent apt configuration?
The fix is to remove the proxy either from apt.conf or from the sources.list entries. Note that the proxy might have been put in /etc/apt/apt.conf.d/01proxy or something like that instead.
Well that was a lot more exciting than I’d hoped for.
I created a new django app on my development machine running Debian SID (updated Aug 14-ish) and wanted to run it on my server machine running Debian stable (lenny). It didn’t work:
machine | devel server ---------------------------------------------------------- Debian | sid (Aug 14) stable (lenny) django | 1.2 1.0 python | 2.6 2.5
There were complaints about missing modules, missing middleware, etc etc. Commenting out those bits resulted in more complaints about other things. So I figured I’d just have to run a “private” copy of django for that application.
To figure out what to copy, I looked at the python-django package contents using
dpkg -L python-django
and that pointed me to this directory full of django implementation files:
So I copied that over to the stable machine next to the little application, told the application to use that django by inserting that directory at the beginning of PYTHONPATH in the wsgi script, and ran the application.
It couldn’t find the module core.handlers.wsgi
That file was there …. but no __init__.py file in core/handlers.
It turns out there were lots of missing __init__.py files … and it turns out that although Debian installs the django python implementation files in /usr/lib/pyshared/django, it uses them from another directory /usr/lib/pymodules/python2.6/django, which is a mirror directory structure with a bunch of links to /usr/lib/pyshared/django for the files in /usr/lib/pyshared/django, plus some other files (like the missing (and usually empty) __init__.py files, plus a pile of .pyc files).
My guess is that Debian makes the mirror directory so that the .pyc files will not mess up the “source” install directory.
The upshot is, that if you’re going to run another django by copying django to a directory local to the application and altering the PYTHONPATH, copy the /usr/lib/modules/python2.6/django directory and not the /usr/lib/pyshared/django directory.
But, the better solution is to use python virtual environments (venv). My app is a tiny thing that only uses django and nothing else (django was really overkill for my app) but it’s a Bad Idea to solve the “wrong-django” problem this way. For example, any time a file disappears from the new version of django, my app would still find it in the old path (which didn’t get removed when I altered PYTHONPATH).
08/16: Happy 17th Birthday Debian!
06/18: grub update broke boot
I run Debian Sid on my laptop. Sid is the unstable or “Still in development” release of Debian. Just recently (on Jun 14, likely) grub was updated in a way that broke my boot. The symptom was that my laptop passed the BIOS, but printed something like “unaligned pointer 0x4c19a146” and then stopped. No grub menu, no graphics, no console, nothing. And of course, no response when you type stuff.
The (short-term, non-participative) solution is to downgrade grub until the problem is fixed. I got a question as to how to do the downgrade when your system won’t boot. So ….
First you find a CD that you can boot from. I used the Debian netinst CD. I had an iso image lying around for Debian 5.02, but pretty much any live CD that lets you have a shell will do. Stick the CD in the machine and reboot. If necessary, change the BIOS settings to boot from the CD first (not the hard disk).
The Debian netinst CD wants to do an install. Press Ctl-Alt-F2 to get another console, and press enter to get a prompt.
If you have one of those fancy-pantsy live CD’s that mounts your disks for you, you might have to unmount them first. At least you’ll know what the names are, in that case …
umount /dev/sda1 umount /dev/sda5 umount /dev/sda6 umount /dev/sda7 umount /dev/sda8
Now you want to mount your hard disks onto the running system and chroot to the root of the hard disk hierarchy. In my case, I have several partitions. I can never remember what the partitions are called — are they hda, hdb, sda, sdb or something else? So I look for disk-related entries in the output from dmesg:
dmesg | egrep '[sh]d'
dmesg | grep disk
dmesg | grep '<'
Don’t forget to quote the angle-bracket on that last one.
It turns out my partitions are:
/dev/sda1 /boot /dev/sda2 / /dev/sda5 /usr /dev/sda6 /var /dev/sda7 /home /dev/sda8 /srv
So I created a directory /mnt/target, and mounted the partitions:
mount -t ext3 /dev/sda2 /mnt/target mount -t ext3 /dev/sda1 /mnt/target/boot mount -t ext3 /dev/sda5 /mnt/target/usr mount -t ext3 /dev/sda6 /mnt/target/var mount -t ext3 /dev/sda7 /mnt/target/home mount -t ext3 /dev/sda8 /mnt/target/srv
Then chrooted to the top of the disk hierarchy:
cd /mnt/target chroot .
Then mount the proc partition (needed for dpkg later)
mount -t proc proc /proc
I looked in the logs to see what version was broken and what version it replaced. Looked in /var/log/dpkg.log … found that grub-pc_1.98-20100614-2 was the one that had just been installed and it was replacing grub-pc_1.98-20100602-1 which used to work just fine. I have been running apt-cacher on the laptop, and looked in the cache to see if the old package was still there — it was.
Then I was able to run dpkg to install the older version of grub. I found it with
because that directory has a _lot_ of files in it and I was only interested in grub packages.
grub-pc depends on grub-common so I installed them both:
cd /var/cache/apt-cacher/packages dpkg -i grub-pc_1.98-20100602-1-686.deb grub-common_1.98-20100602-1-686.deb
That command took care of the grub-install command for me ….
Then I rebooted and when it came up again, I saw a nice grub, and grub started up Linux and all was good. This way of rebooting will unmount the disk partitions nicely. It doesn’t matter that the netinst disk thinks you’re still in the middle of an install.
shutdown -r now
The last step is to tell dpkg and apt and the whole package management chain not to ever install a different grub version. Edit /etc/apt/preferences to contain:
Package: grub-pc Pin: version 1.98-20100602-1-686 Pin-Priority: 1001 Package: grub-common Pin: version 1.98-20100602-1-686 Pin-Priority: 1001
You’ll have to remember to change that at some time in the future so you’ll get grub updates. Personally, I’m not in a rush for that.
Note that I wrote this mostly from memory so paths and version numbers might not be exactly correct. Keep your eyes open, if you’re following these instructions!
$ sudo invoke-rc.d apache2 reload