Linux mdadm superblock question.
in [Kernel]
|
Prev: [patch v3 0/2] updated ptrace/core-dump patches for supporting xstate - v3
Next: [PATCH 3/3] mm: Debugging of new livelock avoidance
From: Frans Pop on 17 Feb 2010 08:30 Rudy Zijlstra wrote: > 1/ distro tools assume that the kernel being build will run on that > machine. For servers this is often not true. There are very valid > security reasons to exclude compilation capability from many servers. That's simply not true, at least not for Debian. If you actually use the distro tools [1] the only assumptions are made at kernel *installation* time, not at kernel build time. I've been using initramfs-tools generated initrds for years without problems, and that includes "root on LVM on LUKS encrypted partition" and "root on LVM on RAID" setups. Cheers, FJP [1] I.e. if you build and install the kernel as a .deb package using e.g. the deb-pkg target or kernel-package. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Bowler on 17 Feb 2010 09:30 On 23:18 Tue 16 Feb , Volker Armin Hemmann wrote: > On Dienstag 16 Februar 2010, Nick Bowler wrote: > > I put a complete set of recovery tools into my initramfses so that when > > the system is completely fucked up, I have a kernel that is able to boot > > until rdinit=/bin/zsh (or /bin/bb, if you prefer) takes over. > > > > This has the added advantage of working when the root filesystem cannot > > be mounted at all: a scenario which does not seem too far-fetched when > > the filesystem is located on a raid array. > > and what do you do if you have to boot from a cd/usb stick and need to access > the raid? > > Simple with auto assembling. Not so much without. The same initramfs can be used on a CD or USB stick. If you were referring to using someone else's CD or USB stick, then obviously mdadm will need to be available. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kyle Moffett on 17 Feb 2010 11:30 On Wed, Feb 17, 2010 at 04:38, Rudy Zijlstra <rudy(a)grumpydevil.homelinux.org> wrote: > Kyle Moffett wrote: >> On Tue, Feb 16, 2010 at 21:01, Neil Brown <neilb(a)suse.de> wrote: >>> I will not be removing 0.90 or auto-assemble from the kernel in the >>> foreseeable future. >>> None the less, I recommend weaning yourself from your dependence on it. >>> initramfs is the future, embrace it. >>> >> >> What are people's reasons for pushback against initramfs? I've heard >> lots of claims that "it's not trustworthy" and "it breaks", but in 7 >> years of running bootable software RAID boxes on weird architectures >> (even running Debian unstable) I have only once or twice had initramfs >> problems. >> >> As a software capability, initramfs makes it possible to use >> *anything* as a root filesystem, no matter what is necessary to set it >> up. For example, I have seen somebody use DRBD (essentially network >> RAID-1) as a root filesystem with a few custom hook scripts added to >> the initramfs-tools configs. Other examples include using Sun ZFS as >> a root fs via an initramfs FUSE daemon, a feat which even Solaris >> could not accomplish at the time. Encrypted root filesystems also >> require an initramfs to prompt for encryption keys and decrypt the >> block device. Multipath block devices are another example. > > We are looking at 2 different use-cases i think. > > for the power-user system manager, who manages all his servers and has > knowledgeable backup, initrd may indeed work as above. > > I have to keep in mind, that when there is a problem while i am travelling > (and that happens), there is no sys-admin present. Also, i am supporting > systems remote where no-one has the knowledge to debug using a initrd. In > such cases, initrd is an additional step. And each additional step is an > additional source of mistakes. Actually, a properly built initramfs gives you far more reliable behavior even without a local sysadmin. For example, most graphical-boot tools are designed to be built into an initramfs; I have seen some prototype initramfs images which provide end-user accessible GUI boot menus and other tools which function reliably even when your root filesystem is inaccessible. > 1/ distro tools assume that the kernel being build will run on that machine. > For servers this is often not true. There are very valid security reasons to > exclude compilation capability from many servers. As Frans Pop states, this is entirely untrue for (at the very least) Debian. The "initramfs-tools" package present there works regardless of where I obtain my kernel. If I use the "make-kpkg" Debian tool when building my kernel (regardless of where it is built), then the resulting package will automatically generate an appropriate initramfs image when installed. If for some reason I install a kernel by hand I can very trivially build the necessary initramfs with this command: update-initramfs -c -k 2.6.32-mykernel01 In the event that you need to "customize" the initramfs for some reason, you can simply do so. When the "update-initramfs" tool is next run, it will report that the user has customized that image and avoid modifying it. If you wish to return to the autogenerated initramfs you can simply run this command: update-initramfs -u -t -k 2.6.32-2-amd64 > 2/ For most small shops, there is need for RAID (disks are fallible, shop > cannot do without server), the RAID should work without being visible. If > there is a problem with the RAID that causes auto-assemble to break, it > means i need to travel (>100KM) to trouble shoot. The simpler the setup, the > more i like it. This is also why i almost always use HW raid for the system > partitions. The ones i use have userland tools in Linux which warn on disk > failure, ensure auto rebuild, etc... > Still, for large storage needs it is SW RAID over SATA. > > 3/ for my home systems, if i need to remote-support to get things working > again (i am often travelling for my work), the added layer of initrd is an > added layer of possible mistakes. You are actually just setting yourself up for problems. RAID autoassembly has bad corner cases when disks disappear between reboots (which happens with failing disk head assemblies). In that case it will fail to find its root filesystem or wait forever for the last disk to show up. I have had even *worse* problems (including corruption of unrelated logical volumes) with many hardware RAID controllers, even those from big-name server vendors such as HP and Dell. To contrast, an initramfs is configurable to prompt the user, automatically degrade the array after a small delay, or even play a kazoo if desired :-D. One of these days I may get around to building myself a small GUI wrapper around mdadm on an initramfs which allows a user to manually recover from RAID problems. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 17 Feb 2010 12:50 On Wed, 17 Feb 2010, Kyle Moffett wrote: > On Wed, Feb 17, 2010 at 04:38, Rudy Zijlstra > <rudy(a)grumpydevil.homelinux.org> wrote: >> Kyle Moffett wrote: >>> On Tue, Feb 16, 2010 at 21:01, Neil Brown <neilb(a)suse.de> wrote: >>>> I will not be removing 0.90 or auto-assemble from the kernel in the >>>> foreseeable future. >>>> None the less, I recommend weaning yourself from your dependence on it. >>>> initramfs is the future, embrace it. >>>> >>> >>> What are people's reasons for pushback against initramfs? I've heard >>> lots of claims that "it's not trustworthy" and "it breaks", but in 7 >>> years of running bootable software RAID boxes on weird architectures >>> (even running Debian unstable) I have only once or twice had initramfs >>> problems. Kyle, for a distro that is trying to make one kernel image run on every possible type of hardware features like initramfs (and udev, modeules, etc) are wonderful. however for people who run systems that are known ahead of time and static (and who build their own kernels instead of just relying on the distro default kernel), all of this is unnessesary complication, which leaves more room for problems to creep in. David Lang
From: Nick Bowler on 17 Feb 2010 13:20
On 09:41 Wed 17 Feb , david(a)lang.hm wrote: > for a distro that is trying to make one kernel image run on every > possible type of hardware features like initramfs (and udev, modeules, > etc) are wonderful. > > however for people who run systems that are known ahead of time and > static (and who build their own kernels instead of just relying on the > distro default kernel), all of this is unnessesary complication, which > leaves more room for problems to creep in. Such people can easily construct an initramfs containing busybox and mdadm with a shell script hardcoded to mount their root fs and run switch_root. It's a ~10 minute jobbie that only needs to be done once. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |