On Sat, 2011-04-02 at 18:31 -0400, R P Herrold wrote: > > You forgot: /boot/ which should not live on a raided or LVM > device, in the interest of reducing potential points of > failure
Well I run /boot on a raided drive (HP array), because thats handled at a lower level. As far as the kernel is concerned its just a regular device. But I would not put it on LVM for obvious reasons. > I speak here, 'wearing the tee-shirt', having spent time > doing just such a recovery where a end customer took the > Red Hat approach as to LVM'ing, and ended up with a > non-bootable system -- I have been there as well, when first migrating partitions like /usr over to lvm. Also at times when not using LVM and a partition is hosed. Its quite a different experience, when you are sitting there at a terminal with a machine that won't boot :) > the hardware had a motherboard from > Intel, calling for a hardware raid driver, 'not yet in > anaconda', and thus not on the rescue disk image either -- > anaconda called for the driver disk [it could 'see' no drives > until such was used], but that disk was long forgotten, when > the recovery was needed Thats another issue entirely and I had the same problem long ago when first getting a 64bit system. Any livecd I could get my hands on did not have support for the ServerWorks SATA chipset in the machine from SuperMicro. They had a kernel patch (created from a Gentoo kernel) which I had to apply. But that meant making my own kernel, and doing a netboot. After I cross compiled a 64bit kernel on a 32bit system. Thankfully Gentoo had tools for that such as crossdev. Made my life easier, though was not an ideal situation. I could easily see that happening time and time again as new hardware comes out. Which drivers might exist for in newer kernels. But if your boot media does not have that driver, your SOL :) > Another common mistake, to my thinking, is to have /boot/ on > raid, rather than on a native partition. Providing the raid array does not present a native partition to the kernel. > If one fails to > update all members, and the array fails and cannot 'bootstrap' > itself together (think Linux' MD software raid) one is again > 'up a creek. In ancient times under SunOS, a cautions > sysadmin would have an 'A' '/' partition on one spindle, and a > 'B' '/' partition on a separate spindle, each containing the > initial boot image. When updating the kernel, one would > update only the 'A' side, and test; cone satisfied, one would > then transfer that image over to the B side as well I did that long ago when using Linux raid. Boot was raid 1 as well as the rest of the system. But technically it booted using ext2 and from one disk, not both. Raid was not active till the kernel booted. > These are of course, matters of sysadmin taste, but in an > 'enterprise' environment, I think most would prefer a faster > mean time to repair, and a dull and predictable path to > recovery when a failure occurs. Oh yes, and a recent level 0 > backup in hand, just in case ;) Time is of the essence when your dealing with recovery :) -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
