[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg and older systems



> I've got a slackware 2.x system that I upgraded to ELF a while ago (1.2.13
> patched kernel and libc 5.0.9) that I'm going to slowly turn into a Debian
> system (a clean start unfortunately, is not an option).

Here's the first draft of a Mini-HOWTO I was working on that sort of covers what you want.  It is actually about doing this remotely, so you will not need to be as cautious as I was, and some of the stuff about SSH is irrelevant.

I was writing this when using Debian-1.2.7 so one or two things might be slightly different.

Cheers, Phil.

-------
            Upgrading to Debian Without starting from scratch.
                                   by
                              Philip Hands
                             phil@hands.com

--------------
FIRST DRAFT:
  This is halfway between being a description of what I did to upgrade a
  specific system, and a general guide to doing Debian Upgrades.  If I can
  turn it into the latter, it might be worth making into a mini-HOWTO.
  It would also be good if dpkg-nondebian could be tweaked to think that a few
  dependencies were installed, rather than needing all the force-depends stuff.
--------------

I recently had to upgrade a client's system to Debian over a remote connection (i.e. the target system was 200 miles away), and thought the procedure might be useful for others.

The system in question was running Slackware (1.2 I think --- 1.2.13 kernel 
mixed a.out and elf binaries).

First, it's a good idea to make sure there is a mirror of Debian as an NFS 
share available on the network (near the target machine).

Log into the target machine.  In my case I dialed into another machine on 
their network with PPP and used ssh to log in.  Install the non-debian tar of dpkg (available in project/experimental):

 tar -C / -xvzf dpkg_1.4.0.8_i386.nondebbin.tar.gz 

at this point dpkg was unable to run, because the c library was well out of 
date (was giving ``Unable to resolve symbol sysinfo'' errors), so I copied 
/lib/libc.so.5.4.20 from another system, and ran ldconfig.

 dpkg --clear-avail   (someone suggested this, so why not)

WARNING: DO NOT install ldso until you've got a recent kernel installed, 
otherwise you are likely to end up without any shared binaries --- I did this 
once, and I wouldn't recommend it ;-)

First we need a new lilo to ensure we'll be able to boot the most recent 
kernels:

 dpkg -i mbr_1.0.0-2.deb
 dpkg -i lilo_19-1.deb

Install a kernel, I suggest starting with one that you know supports a.out (built in, not as a module), since we are booting an old system here, until
we upgrade.  The one I used was tweaked for the target machine (network
card, serial ports etc built in), and built using make-kpkg.

make sure that you have a /vmlinuz.old lilo reference set up in /etc/lilo.conf,
so you can get someone at the target site to boot the old kernel if this step
goes wrong.  i.e. add the following to your /etc/lilo.conf:

  image=/vmlinuz.old
    label=Linux-old
    read-only

install the new kernel:

 dpkg --force-depends -i /tmp/perl-base_5.003.07-6.deb (fails:-)
 dpkg --force-depends -i /tmp/base/libgdbm1_1.7.3-11.deb
 dpkg --force-depends -i /tmp/base/libdb1_1.85.2-8.deb
 dpkg --force-depends -i /tmp/base/libreadline2_2.0.1-2.deb
 dpkg --force-depends -i /tmp/perl-base_5.003.07-6.deb (works this time)

 mkdir /boot
 mv /vmlinuz /boot/vmlinuz-1.2.13
 ln -s /boot/vmlinuz-1.2.13 /vmlinuz
 mv /System.map /boot/System.map-1.2.13
 ln -s /boot/System.map-1.2.13 /System.map

 dpkg -i /tmp/kernel-image-2.0.29_target.1.0_i386.deb

Check that /vmlinuz is now a symbolic link to the new kernel

# ls -l /vmlinuz*
lrwxrwxrwx   1 root  root  19 Mar  7 13:42 /vmlinuz -> boot/vmlinuz-2.0.29
lrwxrwxrwx   1 root  root  20 Mar  7 13:39 /vmlinuz.old -> /boot/vmlinuz-1.2.13

moment of truth #1 --- do a reboot

 shutdown -rft3 now

  .....

Phew -i reboots
 (If it doesn't, time for an sheepish phone call to your clients ;-)

Now that we've got a recent kernel we can risk installing ldso.  Once that's 
done the rest of the base system should go on fairly smoothly.

So after logging back in ...

First, make sure you are now running the new kernel:

  uname -a

otherwise you might be about to lose access to all your dynamic binaries.


get hold of a /usr/info/dir file from somewhere, and put it on this system 
(otherwise install-info will get upset in the next step).  The order I installed the packages is just as I did it --- I'm not saying this is the perfect or minimal order, just that I did this and it worked.  Any suggestions for improvements would be welcome:

 dpkg -i /tmp/base/ldso_1.8.8-1.deb

 mkdir /etc/rc0.d /etc/rc1.d /etc/rc2.d /etc/rc3.d /etc/rc4.d \
       /etc/rc5.d /etc/rc6.d /etc/init.d

 dpkg --force-depends -i /tmp/base/dpkg_1.4.0.7.deb
 dpkg -i /tmp/base/libc5_5.4.20-1.deb
 dpkg -i /tmp/base/tar_1.11.8-5.deb
 dpkg -i /tmp/base/ncurses
 dpkg -i /tmp/base/dpkg_1.4.0.7.deb
 dpkg -i /tmp/base/libdb1_1.85.2-8.deb
 dpkg -i /tmp/base/libgdbm1_1.7.3-11.deb
 dpkg -i /tmp/base/libreadline2_2.0.1-2.deb
 dpkg -i /tmp/base/findutils_4.1-14.deb
 dpkg -i /tmp/base/ae_962-11.deb
 dpkg -i /tmp/base/base-files_1.2.4.deb #probably should have done this earlier
 dpkg -i /tmp/base/bash_1.14.7-2.deb

replace /etc/inittab with one from an existing debian system

 dpkg -i /tmp/base/sysvinit_2.69-1.deb
 dpkg -i /tmp/base/bsdutils_3.0-2.deb
 dpkg -i /tmp/base/debianutils_1.3.deb
 dpkg -i /tmp/base/dialog_0.9a-8.deb 
 dpkg -i /tmp/base/diff_2.7-13.deb
 dpkg -i /tmp/base/e2fsprogs_1.06-3.deb
 dpkg -i /tmp/base/fdflush_1.0.0-4.deb
 dpkg -i /tmp/base/fileutils_3.13-4.deb
 dpkg -i /tmp/base/mawk_1.3.2-3.deb
 dpkg -i /tmp/base/getty_1.45a-3.deb 
 dpkg -i /tmp/base/grep_2.0-9.deb
 dpkg -i /tmp/base/gzip_1.2.4-14.deb
 dpkg -i /tmp/base/kbd_0.91-12.deb
 kbdconfig
 dpkg -i /tmp/base/passwd_1.0-5.deb
 passwd root
 passwd phil
 dpkg -i /tmp/base/login_1.45a-3.deb
 dpkg -i /tmp/base/modules_2.0.0-15.deb
 depmod -a
 modprobe nfs

I think I could have got away with running dselect at this point, but when I 
was doing it someone pulled a network cable out at the remote site, and made 
me think things were going badly when in fact everything was fine.  So 
paranoia made me do these too:

 dpkg -i /tmp/base/mount_2.5l-1.deb
 dpkg -i /tmp/base/makedev_1.5-4.deb
 dpkg -i /tmp/base/procps_1.11.1.deb
 dpkg -i /tmp/base/setserial_2.10-8.deb
 dpkg -i /tmp/base/shellutils_1.12-5.deb
 dpkg -i /tmp/base/sysklogd_1.3-13.deb
 dpkg -i /tmp/base/textutils_1.19-1.deb
 dpkg -i /tmp/base/timezone_7.48-3.deb
 dpkg -i /tmp/base/update_1.2-1.deb
 dpkg -i /tmp/base/util-linux_2.5-9.deb

open up telnet access (the machine in question was a firewall so normally does 
not allow anything but ssh)

 killall -1 inetd

now we install ssh, so that it should get started with the /etc/rc2.d/S* stuff

 dpkg -i /tmp/zlib1_1.0.4-6.deb
 dpkg -i /tmp/ssh_1.2.17-3.deb  (copying /etc/ssh*_config to /etc/ssh/
                                 is a good idea here)
 /etc/init.d/ssh start

The next thing to do is make sure that if the network packs up we can still 
get in via a modem:

mgetty wants to play with /etc/crontab so ...

 dpkg -i /tmp/cron_3.0pl1-38.deb

 dpkg -i /tmp/mgetty_1.0.0-1.deb

edit /etc/inittab to make mgetty run the modem, of course at this point you 
are not running the new initd, so you cannot actually test it, but at least 
you get two chances of getting back into the box this way.

[ mkdir /var/log/mgetty    looks like a bug in mgetty]

At this point I realised that about 10% of the mirror I was working of was 
missing, so I fixed that, got bored and thought I'd give the problem to 
dselect to sort out.

dselect

being a firewall, I only selected a few packages here.  I'd suggest doing that 
anyway and then adding all the extras in a second run through once you've 
booted a Debian system proper.

reboot, and away you go.

--
NOTES:

User IDs:

   daemon = 1, bin = 2 otherwise atrun will not work

   should probably try to change all user ID's to match Debian standard

ssh:

  Linking a static version of ssh before you start gives you the chance of recovering from upgrading ldso early, since you can copy an old /lib/ld.so back onto the machine if it's got a static version of ssh installed.

I recommend getting ppp and ssh installed on all the machines you want to 
remotely administer --- the ease with which this allows you to log in and 
transfer files is not really achievable any other way.

--
Philip Hands <phil@hands.com>




--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: