Try a rescue partition. was: Re: I broke it - again.
aon.912411198@aon.at (Michael Moerz) writes:
> nice suggestion, but did you ever try to downgrade
> something when dpkg doesn't work ?
My two cents worth:
Put essential software in a place where it is likely to
continue to work, even if lilo, the kernel, libc, or what
have you, all break.
To do so, simply set aside a small hard disk partition as a
rescue partition, and install a second Linux on that.
Then, when your regular lilo, kernel, libc, dpkg, or what
have you break, as in the example under discussion, you can
calmly boot up your rescue partition and do from there
whatever needs to be done to restore your regular system to
some healthy state.
In the example under discussion, dpkg's --root switch and a
potoato binary CD number 1 would do the trick.
If this sounds like a new, interesting thought to you, here
follow more details.
Such a rescue partition needn't be a big thing. Just a
basic plain vanilla Linux system. You certainly want an
editor you're comfortable with. Perl can also come in *very
handy* in many kinds of emergencies - if you know perl, that
is. If you want to get fancy, throw in X, some small window
manager (like fvwm95 or icewm), and whatever software you
need to get out into the internet.
I've been using rescue partitions routinely for years.
"Using" is a little exagerated: A rescue partition mostly
sits there and does nothing. I have only rarely needed to
actually use them. But when, occasionally, the need arises,
such a rescue partition comes in very handy indeed.
In case you wonder: No, I don't do regular backups of my
system. Howerver, having a rescue partition set aside
greatly enhances my "goof recovery capability".
Actually, even if you do backups: Doing a backup is nicer if
the system is quiet while you do the backup. While you're
running off a rescue partition, the regular system will be
quiet indeed. You can even mount it all read only, with the
additional advantage that your backup does not mess up all
your precious "last access timestamps". (Do you ever do "ls
-ult" or similar?)
Also, another use case sometimes strikes me when a partition
on my regular system is running full. I will then simply
shift a large directory subtree from that partititon to
another, not so crowded, partition. I delete the tree at
the original spot, and put a symbolic link to the new copy
in the place where the tree used to be.
It's much nicer to live off a rescue partition while doing
manipulations like that. E.g., I can be pedantic and do
"find . -type f -exec md5sum {} \;", and no process will
mess up any files under me. I can even - luxery of luxeries
- perserve my beloved "last access" timestamps of all files
through the copy, with the help of a little perl.
If you want to follow this advice, grab some spare hard disk
space, mke2fs, install potato base on that, throw in
additional software as you see fit, and briefly check it all
works.
For additional safety, glue, with adhesive tape, to the back
of your computer, a properly labled write protected floppy
disk with some kernel on it, that can boot off that rescue
partition. After that's been done you may mess up lilo with
confidence.
If you are not able to, or don't want to, pull another
partition out of your hard disk, you can alternatively use a
partition that you already have, and make it also serve as
your rescue partition as its new, secondary job. This is
second choice to a dedicated rescue-only partition, but a
lot better than none at all.
For an easy example, if /dev/hda3 is /home on your regular
system, install a second Linux that uses /dev/hda3 as / .
But be very carefull not to erase that partition (mke2fs)
during the installation process, or you'll loose all your
/home data!
After that's been done, you'll see, under the regular Linux,
a few extra directories such as /home/etc, /home/bin,
/home/lib, /home/dev, /home/boot, /home/usr, /home/var, even
/home/home, and the like. Those don't hurt.
Under the rescue Linux, you'll see toplevel directories with
the names of your users. Those don't hurt, either.
However, quite a bit of extra care is required if you want
to put your regular /usr partition to a double use as the /
(and only) partition for a rescue system. You *don't* want
the rescue system's /lib and /bin directory messing up the
regular system's /usr/lib and /usr/bin, neither vice versa.
The same is true, to a lesser extend, with /var, as there is
a directory /var/lib which should not be messed up with the
rescue system's /lib.
It can all still be done, but with some tricky symbolic
links. You may, at your own risk!, try something along
these lines:
telinit 1 # go into single user mode, then:
umount /usr
mkdir /usr-regular
mount -t ext2 /dev/your-usr-partition /usr-regular
cd /usr-regular
for d in *
do
mv $d $d-regular
ln -s /usr-regular/$d-regular /usr/$d
done
# fix /etc/fstab to mount on /usr-regular what used to be /usr
# go back into regular system mode, briefly test it all works.
# Install potato on /dev/your-usr-partition
# without deleting the regular /usr - data that's
# already there.
I've been using a similar setup when I upgraded from SuSE
Linux to Debian years ago. Debian's /usr was SuSE's /, and
vice versa.
Many an emergency is much less problematic if you don't need
to live off a Debian CD or rescue floppy, but have a
prefabricated rescue partition to support you. If nothing
else, typing away at a real bash prompt, as opposed to ash,
is worth a lot - to me, at least. The potato install manual
says you need 64 MByte to get a minimal Debian system up and
running. 100-200 MB can certainly go a long way, if wisely
used.
Regards,
Andreas
andreas.krueger@online.life.de
Reply to: