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: Nick Bowler on 18 Feb 2010 09:20 On 04:33 Thu 18 Feb , Goswin von Brederlow wrote: > Nick Bowler <nbowler(a)elliptictech.com> writes: > > > On 09:41 Wed 17 Feb , david(a)lang.hm wrote: > >> 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. > > Except when mdadm, cryptsetup, lvm change you need to update it. > Esspecially when you set up a new system that might have newer > metadata. I meant "once per system". One typically doesn't _need_ to update the mdadm in the initramfs, as long as it's capable of assembling the root array. > Also at least Debian doesn't (yet) support a common initramfs for their > kernel packaging. You either build a kernel without need for one or you > have a per kernel initramfs that is automatically build and updated > whenever anything in the initrmafs changes. Not often, but still too > often, the initramfs then doesn't work. The scenario was when users configure and build their own kernel. These users are presumably capable of using grub's "initrd" command or the CONFIG_INITRAMFS_SOURCE kernel option. -- 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: Michael Evans on 19 Feb 2010 04:10
I actually much prefer building my own kernel for servers and higher-end workstations. I like having all the core drivers needed to 'get running' in there; even if the more delicate but static logic of how to track down and assemble/unlock the drives is in the initramfs image. The only really annoying issue I've had with my custom initramfs creator is getting it 'chained' by various distros auto-initramfs update triggers so that it can grab the version of modules that match a given kernel. I have several ways in mind to work around that issue at various steps, but no known userbase to support besides my self and thus less motivation to work on that task. Everything else of course works exactly the same as long as the configuration hasn't changed on the host system. -- 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/ |