The easiest way to dig yourself out of the hole created by the RAIDgrowth gotcha is probably to use a live/rescue CD.But let us suppose that you don't have one handy, which was the casefor me yesterday. Further let us suppose that you have /boot as a separate filesystem , not as part of the rootfilesystem (if this is not the case, you absolutely need a rescue CD;sorry).

The basic goal is to rebuild a version of your current initrd that has

Suppose that you have a system with a mirrored root filesystem and,for some reason , you need to boot it withoutthe mirror being available. At one level, this is very easy; all youneed to do is to find the partition of one of the mirrors and specifyit as the filesystem root device on the kernel command line with' root=/dev/sdXX '.

This works because while software RAID embeds its own metadata in thepartitions, it puts the metadata at the end of the partition,

Suppose that you have a fully mirrored system and you want to expandyour available space by migrating to a pair of larger hard drives. Theobvious way to do this is fairly straightforward, assuming that youcan connect all of your drives at once: partition the new drives (withlarger partitions for at least some of your software RAID devices), addthe new partitions to the appropriate MD device, let things resync, andthen detach the old disks (and eventually physically remove them).

(Hopefully the obvious way

I was asked today if I thought that a disk-based backup system could do restores faster than a tape-based system. Mybest answer was a 'maybe', because it really depends on what thelimiting factor is in your restores. Let's look at all of the thingsthat have to happen in a restore:

1. you find and load the tape into the tape drive or tape library,if it's not already there.
2. if you have a tape library, it loads the tape into the