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: Volker Armin Hemmann on 16 Feb 2010 16:10 On Dienstag 16 Februar 2010, Bill Davidsen wrote: > Volker Armin Hemmann wrote: > > On Sonntag 14 Februar 2010, you wrote: > >> In other words, 'auto-detection' for 1.x format devices is using an > >> initrd/initramfs. > > > > which makes 1.x format useless for everybody who does not want to deal > > with initrd/initramfs. > > You make this sound like some major big deal. are you running your own > distribution? In most cases mkinitrd does the right thing when you "make > install" the kernel, and if you are doing something in the build so > complex that it needs options, you really should understand the options > and be sure you're doing what you want. > > Generally this involves preloading a module or two, and if you need it > every time you probably should have built it in, anyway. > > My opinion... I am running my own kernels - and of course everything that is needed to boot and get the basic system up is built in. Why should I make the disk drivers modules? That does not make sense. And the reason is simple: even when the system is completely fucked up, I want a kernel that is able to boot until init=/bin/bb takes over. Gl�ck Auf Volker -- 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: Bodo Eggert on 16 Feb 2010 16:20 Bill Davidsen <davidsen(a)tmr.com> wrote: > Volker Armin Hemmann wrote: >> On Sonntag 14 Februar 2010, you wrote: >>> In other words, 'auto-detection' for 1.x format devices is using an >>> initrd/initramfs. >>> >> >> which makes 1.x format useless for everybody who does not want to deal with >> initrd/initramfs. >> > > You make this sound like some major big deal. are you running your own > distribution? In most cases mkinitrd does the right thing when you "make > install" the kernel, I don't know what "make install" will do, so I'll have to expect random results. I don't expect it to copy bzimage to /boot/linux-version-commentfrommymind, point the "ln" or "lt" entry (depending on if I want to upgrade or to test a new kernel) in lilo.conf to the new kernel and to run lilo -R ln. I don't expect it to sftp the kernel from my build machine to my server, either. I expect it to move ~/bin/umount (a wrapper around /bin/umount fusermount -u and smbumount) to initrd:/bin/umount. It might also create an initrd with a passwordless rescue mode. Or it will use a minimal shell, and in case of trouble, I have to fight the shell, too. In short: I expect it to backstab me. (As a bonus, you can't read about rdinit= if you encounter your first initrd-ed system and init=/bin/sh does not work.) > and if you are doing something in the build so > complex that it needs options, you really should understand the options > and be sure you're doing what you want. What I do is the most simple thing you can do. No initrd no cry. That's why I have to use the 0.9 format. This - and the fact that my distribution defaults to using the 1.0 format - is what I discovered after upgrading my system last time. -- 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 16 Feb 2010 17:10 On 22:06 Tue 16 Feb , Volker Armin Hemmann wrote: > On Dienstag 16 Februar 2010, Bill Davidsen wrote: > > Volker Armin Hemmann wrote: > > > On Sonntag 14 Februar 2010, you wrote: > > >> In other words, 'auto-detection' for 1.x format devices is using an > > >> initrd/initramfs. > > > > > > which makes 1.x format useless for everybody who does not want to deal > > > with initrd/initramfs. > > > > You make this sound like some major big deal. are you running your own > > distribution? In most cases mkinitrd does the right thing when you "make > > install" the kernel, and if you are doing something in the build so > > complex that it needs options, you really should understand the options > > and be sure you're doing what you want. > > > > Generally this involves preloading a module or two, and if you need it > > every time you probably should have built it in, anyway. > > > > My opinion... > > I am running my own kernels - and of course everything that is needed to boot > and get the basic system up is built in. Why should I make the disk drivers > modules? > That does not make sense. I agree that it makes little sense to make something a module when you can't unload it anyway, but... > And the reason is simple: even when the system is completely fucked up, I want > a kernel that is able to boot until init=/bin/bb takes over. 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. -- 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: Volker Armin Hemmann on 16 Feb 2010 17:20 On Dienstag 16 Februar 2010, Nick Bowler wrote: > On 22:06 Tue 16 Feb , Volker Armin Hemmann wrote: > > On Dienstag 16 Februar 2010, Bill Davidsen wrote: > > > Volker Armin Hemmann wrote: > > > > On Sonntag 14 Februar 2010, you wrote: > > > >> In other words, 'auto-detection' for 1.x format devices is using an > > > >> initrd/initramfs. > > > > > > > > which makes 1.x format useless for everybody who does not want to > > > > deal with initrd/initramfs. > > > > > > You make this sound like some major big deal. are you running your own > > > distribution? In most cases mkinitrd does the right thing when you > > > "make install" the kernel, and if you are doing something in the build > > > so complex that it needs options, you really should understand the > > > options and be sure you're doing what you want. > > > > > > Generally this involves preloading a module or two, and if you need it > > > every time you probably should have built it in, anyway. > > > > > > My opinion... > > > > I am running my own kernels - and of course everything that is needed to > > boot and get the basic system up is built in. Why should I make the disk > > drivers modules? > > That does not make sense. > > I agree that it makes little sense to make something a module when you > can't unload it anyway, but... > > > And the reason is simple: even when the system is completely fucked up, I > > want a kernel that is able to boot until init=/bin/bb takes over. > > 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. Gl�ck Auf, Volker -- 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: H. Peter Anvin on 16 Feb 2010 18:40
On 02/16/2010 09:05 AM, Bill Davidsen wrote: > > I'm not really sure what you're getting at here, I use grub in MBR and > then add chain loader stanzas to grub.conf for many things, usually an > alternate Linux release, or to have 32/64 of the same release handy for > testing, and always memtest from the boot menu. Even Win98SP2 on one > machine, since that works very poorly under KVM. (ask Avi if you care > why, something about what it does in real mode). In any case, I don't > see the chain loader issue, unless you mean to reboot out of some other > OS into Linux. > That's one of many uses, yes Presumably the reason you don't have problems is because the partitions you chainload aren't RAID partitions with 1.1 superblocks, or you're specifying an explicit offset for your chainloads (Grub syntax allows that.) Either which way, it's a good example of the usage model. Chainloading is important for a lot of people. -hpa -- 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/ |