Things we definitely need to do:

1. ensure all disks are in use
2. ensure user data integrity

First, backup:

1. from mudge: rsync -a --progress --exclude '/tmp/*' --exclude '/proc/*' / root@tumbo.cs:/fsys2/ (I've already verified that /fsys2 on tumbo has sufficient room to hold "all" of mudge.) This is to both have a backup and to have a "live" copy of the data from /etc so I can duplicate the old setup. For instance, mudge uses softbase as a mail handler... Except this isn't working because for some reason tumbo's decided to hate mudge. And after trying different methods three or four times apiece, it suddenly started working again. This is rather distressing. Logged in as mpatters, ran screen, then suw. Once that is complete, run it again to catch any files that have been changed.

Simultaneously with this, shut down unneeded machines in the mudge region (gooch, quadra). First do "dpkg --get-selections > quadrapkgs" on quadra, just to get latest package selections. Those will be over on tumbo due to the backup, so we'll be able to get at them when we restore files.

1. Now ensure synchronization of u. On tumbo: "umount /u" (just to be safe). Then on mudge: "rsync -a --progress u/ tumbo:/fsys2/u"

We got:

2>(root)@mudge[118]% rsync -a --progress u/ tumbo:/fsys2/u
         138 100%    0.00kB/s    0:00:00
        1920 100%    0.00kB/s    0:00:00
        1953 100%    0.00kB/s    0:00:00
        7724 100%    0.00kB/s    0:00:00
2>(root)@mudge[119]% 

That's a reasonable number of files to have changed, given that I was faffing about as my own user on several of the machines during the first rsync.

Now, I'll leave tumbo alive while mudge is reinstalled. That way I can refer back if necessary. It may be safest to leave tumbo's network off while I'm in the machine room and able to physically access the console.

Just to be sure I also put a copy of mudge's dpkg --get-selections on mpatters@torres.