Fix missing eth0 after changing network cards
After changing hard drives out of one server machine into another and booting, the network interface didn’t come up correctly. eth0 didn’t exist and gave an error when I tried to start it manually using ifup eth0. At first I suspected that the correct driver module wasn’t installed because the OS had been installed on another system with a different NIC; so I verified that the correct module was installed.
What in fact had happened is that udev has a feature where it remembers NICs by their MAC address and remembers which device name they’ve been assigned. So the hard drive (and the OS it contains) were running in a machine with another NIC that had been assigned to eth0, so when booted inside the new machine it assigned the new NIC to eth1. Unexpected!
This would often be pretty fantastic. Many years ago when I upgraded from a 2.4 to a 2.6 kernel I had an issue where the order of network devices changed - eth0 and eth1 had swapped. This caused some frustration when remote administering the upgrade from another country on Christmas day.
So you can either take what you’ve been given and change your network interface configuration to use eth1. Which wouldn’t be stupid. Or you can modify the udev rules to forget the original NIC and therefore assign eth0 to your new NIC on reboot…
Edit the /etc/udev/rules.d/70-persistent-net.rules file. At or near the bottom will be lines beginning SUBSYSTEM, which declares the MAC address and the assigned device name. Comment out or delete lines for NICs you no longer have. Then either comment out or delete your current NIC (otherwise it will stay with eth1 after reboot) or simply change the device name it has been assigned to eth0. Then reboot.
I had to discover this in a time critical situation - thank goodness for Google and for this post.
Restore the Linux console messages on boot
When I installed Ubuntu Lucid on a physical server for the first time I was unnerved by seeing a startup progress indicator when I’m used to seeing all the console messages scrolling by. If something is taking a long time, I want to see what it is. I know you can switch to VT-7, but I want them back on the main screen where they’re easy to see (and easy for someone else to see if I’m calling on the phone in an emergency).
It’s of course a simple configuration change.
Edit /etc/default/grub and change GRUB_CMDLINE_LINUX_DEFAULT. For the progress indicator it’s set to “quiet splash”. For the console messages just change that to “”. Source.
Installing 32 bit PostgreSQL on 64 bit Linux
During an emergency server upgrade last week I was faced with a problem. I’d installed 64 bit Linux to replace a 32 bit Linux box, copied across the PostgreSQL data directory, then installed the identical version of PostgreSQL, but 64 bit. It turns out that the data file format is incompatible between 32 and 64 bit PostgreSQL.
PostgreSQL is my favourite RDBMS, but it’s worth noting that MySQL had no such problem and automatically updated the data files. Thanks MySQL!
The 32 bit server install was dead, so I couldn’t do a dump from the 32 bit system. I needed to install 32 bit PostgreSQL on my 64 bit box.
First you need to install ia32-libs using apt-get install. This gets you the base libraries necessary to run 32 bit apps.
Then you need to manually download the 32 bit .deb files for PostgreSQL. You’ll find them under /ubuntu/pool/main/p/ in your local Ubuntu archive. Try doing an install of PostgreSQL as per normal to see which packages are required. The postgresql-common packages are architecture independent so you can install those using apt-get.
After you’ve downloaded the .deb files you must install them using dpkg -i —force-architecture <debs>.
After doing this I was able to start PostgreSQL. It said it failed during startup! But it did actually start. I wasn’t able to use psql, as the libreadline library wasn’t 32 bit, but I was able to use pg_dump, which was the critical bit.
Once I’d dumped the databases I quickly uninstalled the 32 bit PostgreSQL, moved the data directory and installed the 64 bit version and sat through the lengthy reload.
Installing Dimdim on Debian Lenny
I found these instructions for installing DimDim on Debian Lenny. They’re pretty good: http://niteshrijal.com.np/installing-dimdim-in-debian-lenny-stable/
However, there appear to be existing packages for some of the Python modules that are installed from source, so perhaps try those first. Also when setting permissions, look out for the commands to set permissions on your /usr/bin and /usr/lib and /usr/local/share directories; those are a bit wide-reaching for me! When installing swftools I suggest putting them into the /usr/local hierarchy rather than /usr. Make sure you have the psmisc package installed to get killall, which is used by StopDimdim.sh
Installing Debian Lenny on Windows Virtual PC
Create a new Virtual Machine, put the Debian Lenny CD in the drive, boot the machine. It should boot from the CD. At the Install prompt press TAB to edit the Install command.
Just before the vga= argument add a noreplace-paravirt argument, then change vga=normal to vga=791. Then press Enter to boot.
I got these instructions from http://wiki.debian.org/MicrosoftVirtualPc2007/lenny
You’ll need to make the same change to the grub configuration / launch string after installation. Press ‘e’ to edit the boot command, edit the kernel boot and add those options, then press ‘b’ to boot. That will get you to the first boot, then edit /boot/grub/menu.lst and add those options to the kopt= line, remember you don’t have to uncomment that line! Then run update-grub to update grub and reboot to check your work.
Debian Sarge to Lenny upgrade
This morning I have upgraded a non-production but important server from Debian Sarge to Debian Lenny. Figuring it was about time that I did the upgrade I took some advice that Lenny is very stable and could buy me a longer support period by skipping Etch altogether. Time will tell. This post itemises the steps I went through for posterity and prosperity if I ever need to refer to them again. I’m writing this up from my notes so it is possible that I’ve missed something; if you do attempt a similar upgrade yourself and something turns up, please feel free to suggest it in the comments. I started by reading (skimming) the release notes for Lenny on upgrading, which are currently in draft as it is in testing. In the future Lenny will obviously become the release version so that URL will become invalid. If you’re upgrading I suggest you to the same; furthermore if you’re upgrading from Sarge read over the Etch release notes for upgrading too. My process is based on and pretty much identical to the process described therein.
Make sure you’ve backed up the important stuff before trying anything like this. In particular postgres is very rude in upgrades (I upgraded from a backported 8.1 I think) and you lose all your data. Make sure you’ve done a dump. First update your /etc/apt/sources.list. Unless you have special sources for some packages you’ll probably just change sarge to lenny and end up with:
deb http://ftp.YOURMIRRORHERE.debian.org/debian/ lenny main contrib deb http://security.debian.org/ lenny/updates main contrib
Note that you need to find the URL for your local mirror, it’s probably already in your sources.list. Refresh the sources list:
aptitude update
Upgrade aptitude (I use aptitude rather than apt-get). The Lenny aptitude apparently is better at conflict resolution. This will upgrade a number of other packages at the same time, but not as many as later!
aptitude install aptitude
My next step was to install the Debian keyring so that future packages are trusted. Followed by another update to apply the change:
aptitude install debian-keyring aptitude update
Now we’re ready to upgrade some packages. During the upgrade process you get asked about changed configuration files a lot. My strategy was to always accept the new maintainer’s version, but to note down each time it occured and to later go back and compare the config I had (it saves a backup in each case). The release notes recommend a safe upgrade first, so that’s what I did:
aptitude safe-upgrade
This went smoothly with no problems that I recall; certainly no problems that I had to address at this point. The release notes go on to recommend a kernel upgrade so that the system remains a working one. I’m not sure this was necessary as I was already using the 2.6 kernel. In fact, if you were on 2.4 I wouldn’t start following what I did - you’ll likely have to do more and be much more careful.
aptitude install linux-image-2.6-686
That installed smoothly and updated my grub. Next we do the full upgrade with all of the changed dependencies. Look out for packages that it says it must remove, as you may want to add those later. For me it removed dokuwiki; I let it do it and reinstalled it once the upgrade was complete.
aptitude full-upgrade
I had to repeat the full-upgrade numerous times, each time seeing problems, correcting them and then repeating and getting a little further. Each problem was usually solved by forceably removing a conflicting package or changing some configuration files; Googling for error messages helped. These are the ones I encountered: Error:
trying to overwrite `/usr/sbin/add-shell', which is also in package passwd
Resolution:
dpkg -r --force all passwd
Error:
Something about phpmyadmin not being able to find a directory
Resolution:
mkdir /var/lib/phpmyadmin
Error:
configuration error - unknown item 'FAIL_DELAY' (notify administrator)
Resolution: I commented out all unknown items from /etc/login.defs. It later installs a new version of this file; I guess the error wouldn’t occur if the file was updated earlier. Ah well, easy fix. Error:
/usr/sbin/make-ssl-cert: line 1: mktemp: command not found
Resolution: I couldn’t get aptitude to install mktemp because too many other things were broken and it wanted to do them first. Instead I found the downloaded mktemp package and installed it directly with dpkg. Thinking about it now, mktemp might not be downloaded unless you try to install with aptitude so perhaps resolve it like this:
aptitude download mktemp aptitude install mktemp_1.5-9_i386.deb (of course this package name may have changed)
Error:
dpkg: error processing /var/cache/apt/archives/libcups2_1.3.8-1lenny4.1_i386.deb (--unpack): trying to overwrite `/usr/lib/libcups.so.2', which is also in package libcupsys2-gnutls10
Resolution:
dpkg -r libcupsys2-gnutls10
Error:
dpkg: error processing /var/cache/apt/archives/ntp_1%3a4.2.4p4+dfsg-8_i386.deb (--unpack): trying to overwrite `/etc/ntp.conf', which is also in package ntp-server
Resolution:
dpkg -r ntp-simple ntp-server
That was the end of the problems I encountered. I probably ended up running the full-upgrade 20 times as I worked out the solutions to each of these. Simply keep running it until it does nothing. Before rebooting be sure to check the release notes for any last instructions. I had to review my mdadm setup; I read the readme, checked my setup, made some tweaks and all went smoothly. Reboot! You definitely want to have physical access to the machine at this stage. I’ve upgraded a few machines across continents and it was really scary and in fact required physical intervention. This time the box just came back up like a charm so I was very pleased. To finish it off I reinstalled packages that had to be removed (that included dokuwiki and vim) and started to check all of the essential services; most of them required some tweaking. There may be some dependencies that are still not satisfied. We ask aptitude to do a general check and it will try to resolve them; you’ll have to confront this sooner or later so why not sooner. I ended up with a few python packages which couldn’t be installed so I removed them all - fixed.
aptitude install
Also there may be some obsolete packages left. If you start aptitude in interactive mode (just type aptitude) then you can view the obsolete packages and decide what to do with them. I removed all of them apart from the libraries; I wasn’t sure as there are some 3rd party pieces of software (oracle) that I didn’t want to try my luck with. Postgresql 8.3 also ended up in a state where the locale wasn’t good - it had en_NZ and wouldn’t accept UTF-8 encodings. Removing and reinstalling postgres fixed that so I guess it was installed at a point in the process where the locale wasn’t right. That’s all that was required for me. It took less than 3 hours and was pretty satisfying. Good luck with your upgrade.
