My final /etc/networking/interfaces file looks like (this is for Debian)
auto lo eth0 tap0 br0
iface lo inet loopback
iface br0 inet dhcp
bridge_ports eth0 tap0
iface eth0 inet manual
iface tap0 inet manual
pre-up tunctl -b -u
<my_user_name> -t tap0
pre-up ifconfig tap0 up
post-down tunctl -d tap0
I stole this from the following site joost.damad.be
Beware the username enttry above needs to be changed to your username… You will also need to install uml-utilities. Once I had this running I could start my image as follows:
qemu -net nic -net tap,ifname=tap0,script=no -hda debian.img
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 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.
I always get this error when I am working i a chroot trying to use screen. In the past I have fixed it using the following command.
mount -t devpts devpts /usr/CHROOT/dev/pts
When this fails another alternative is the following:
Its a bit of a hack but it gets the job done.
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.
I got a new Dell Vostro 400 this week and have been trying to get Debian Etch stable on it. This has proved a bit of a pain.
The following facts might help.
- Dell are using a new Intel Ethernet Controller
- They are also using a modern SATA controller
- The stock Debian netinst cd does not have the correct drivers for these.
To get it all to work you will need to get the Backported Images. The point to note for etch is the addition of the E1000E Intel Ethernet Driver. This is not currently in the latest kernel (220.127.116.11) so no point going to kernel.org to get the latest kernel, this may be fixed by the time you read this.
Thanks to Kenshi Muto I was able to get Debian installed but this is where it all went bad.
My next job was to get Gnome running on the machine. I have a Nvidia card installed so I went to the Nvidia Unix Driver Page and got the latest driver. I tried to install this but it is incompatible with the rivafb and nvidifb modules so if I stick with Kenshi’s kernel I cannot have a desktop but if I install a new kernel I cannot have networking.
At this point you are probably hoping there is some smart fix for this problem. Unfortunately I didn’t find one. I ended up installing a separate network card to get the system running. I would imagine in the near future that the Linux Kernel will have support for E1000E and when it does I will recompile the kernel.
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.