> > >> problem. This method does require that I update the two backups by > > >> hand once in awhile. That's OK by me. > > > > > > Define, "once in awhile [sic]". > > > > Every 2-3 months I make sure each drive is up to date. > > I was having to update one server or the other every week or so, > sometimes more than once a week. I could have written scripts to do it, > or > used rsync, I suppose, but I opted for RAID1. > > > > It's certainly possible to do it, > > > but the very reason I went with boot arrays rather than boot > partitions > > was > > > it was getting to be a pain to update the backup drives all the time. > > > > All the time vs once every 2-3 months. > > > > Even an out-of-date boot drive will allow me to boot the machine and > > get things fixed. > > > > > Almost every time a package is added or deleted, /etc gets updated. > > Keeping > > > different copies of the configuration files in /etc in the initrd and > > the > > > root partition is not the best of ideas, although if course it can be > > done. > > > > As I said I don't using an initrd. I've never learned how to build one > > and didn't need it if I didn't use RAID on /boot. > > Most distros these days employ an initrd. One re-builds it by > running whatever application is included with the distro for that purpose. > In the case of Debian and Debian derivatives, it is currently > `update-initramfs`. It's built the first time by installing a Linux > distro. > It's not that difficult to do by hand, however. Most are built using cpio > and gzip. Once one has the directory structure one wishes, one simply > creates a compressed tarball (cpioball?) from the structure. It includes > a > copy of /etc, with some special scripts to allow the system to work prior > to > the existence of the "real" /. > > > I don't understand your comments about /etc as it's not kept in /boot. > > /etc, /, /home, and all other directories are on RAID. Only /boot > > isn't, so it needs only a kernel and grub. > > The initrd has a copy of /etc - especially the boot configuration > files such as mdadm.conf, fstab, etc. Oh, I almost forgot. It may be of notable mention an array with a 1.0 superblock can be read as if it were an ordinary partition. This means one can build a 1.0 superblock array containing a file system (ext2 may be the best choice in this case), but boot from the partition just as if it were not an array. Once the system is booted, the array can be assembled and then /boot can be mounted. This is because: 1. The 1.0 superblock is at the *END* of the array. 2. The file system when created only uses up the front part of the partition, leaving the superblock intact. 3. GRUB does not require the file system to be mounted in order to read the kernel and the initrd. (Actually, it could be made to work even if it did mount the partition, but since it does not, it makes it much easier.) Indeed, this is the only way of which I know to boot to an array using GRUB legacy. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
