You are not logged in.

#1 2010-03-22 01:12:30

soloport
Member
Registered: 2005-03-01
Posts: 442

[SOLVED] Upgrade Old Remote Box

Managing a box that's 1400+km away.  It was built with Arch circa 2007-03-28, so, needs an update.  Its version of pacman runs into issues, like current vs core and package content, etc.  The current version of pacman is dynamic, so, there's a cascade-of-dependencies to be sure:

ldd /usr/bin/pacman
        linux-gate.so.1 =>  (0xb77c3000)
        libalpm.so.4 => /usr/lib/libalpm.so.4 (0xb7777000)
        libfetch.so => /usr/lib/libfetch.so (0xb7769000)
        libarchive.so.2 => /usr/lib/libarchive.so.2 (0xb772a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7722000)
        libattr.so.1 => /lib/libattr.so.1 (0xb771c000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb75ca000)
        liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb75a9000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7598000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7583000)
        libc.so.6 => /lib/libc.so.6 (0xb743c000)
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb73f2000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb73cc000)
        libdl.so.2 => /lib/libdl.so.2 (0xb73c8000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb73af000)
        /lib/ld-linux.so.2 (0xb77c4000)

What strategy would you recommend to resolve?  Is there a static version of pacman?

Thanks

[Edit:] Marked [SOLVED]

Last edited by soloport (2010-04-13 23:13:23)

Offline

#2 2010-04-12 23:19:28

soloport
Member
Registered: 2005-03-01
Posts: 442

Re: [SOLVED] Upgrade Old Remote Box

Some background:  There are actually several boxes that need help.  Each box is 1,000-3,000km away, so it's virtually impossible to bring them all in for proper upgrade.  The boxes were last updated years ago - some in 2006 and others in early 2007.  Many of the boxes are upgrade-broken.  That is, I tried to see what would happen if I just entered packman -Suy and when that failed tried other brute-force upgrade steps -- those failed as well, to the point where pacman is seriously nuked.

Here's what I've done to successfully recover some of the boxes (/dev/sda3 is the root partition):
* disable swap partition /dev/sda2 (about 1GB)
* switch /dev/sda2 to ext3 format
* mount /dev/sda2 to /mnt
* download and expand core.db.tar.gz to /mnt/core
* grab list of essential packages
* look up each file format in /mnt/core/<package>/desc
* download and expand each package into /mnt
* mount /proc, /sys, /dev and /boot to /mnt
* update /etc/resolv.conf, /etc/hosts.allow (e.g. sshd) and /etc/pacman.c/mirrorlist under /mnt
* chroot into /mnt and run: pacman -Sfy --noconfirm $list
* update /etc/resolv.conf, /etc/hosts.allow and /etc/pacman.c/mirrorlist under /mnt (again because pacman -Sfy will have wiped them out)
* chroot into /mnt to initialize root user's password
* unmount /proc, /sys, /dev, /boot and /mnt
* edit /boot/grub/menu.lst and switch to root=/dev/sda2
* reboot

Note: Un-tarring files into /mnt resolves pacman dependencies, but running pacman -Sfy --noconfirm $list properly sets up the package database, etc.

When the system reboots, rootfs is now /dev/sda2, so the same steps are repeated but with /dev/sda3.  On the final reboot /dev/sda3 is again the root partition, /dev/sda2 goes back to being swap, the system has been upgraded and all is well in the land.

[Edit:] Marked [SOLVED]

Last edited by soloport (2010-04-13 23:12:36)

Offline

Board footer

Powered by FluxBB