-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > Andy Green wrote: >> Yep, dynamic generation of kernel commandline has managed to exist based >> on bad blocks :-) > > The command line content would not be affected by bad blocks. The > kernel also sees it always at the same place. Just the boot loader > wouldn't always see it at the same place, but that's also true for > any other block it loads.
OK. This being because we did the padding thing all partition starts can ignore the bad blocks that went before. Well that is good. >> We need to decide about that based on the max size allocated for this >> recovery system, not the minimum and "optimize later". What max size >> are you thinking of here for recovery kernel and rootfs / initrd? > > I think we'll be fine with 2MB for kernel plus 2MB for initramfs. > When selecting memory chips or allocating partition space, I'd > double that figure as "engineering tolerance". <= 2MB is fine as initramfs for me but aren't we closing off the possibility for a wonderland of graphical apps and so on in there? Or these must come from the main rootfs? >> No, I mean if you open the block device for dd or whatever, there is no >> "out of band" information in that device node. You just get >> dysfunctional blocks. > > You get that now as well. Wow NAND really sucks badly. I have used dd on the mtd block devices and just been lucky I guess. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4bHHOjLpvpq7dMoRAsTsAJ4knuNO1I5w9F7BJri3baWNUrqsuACfXWlE x0Ro7vbYGnqOZEnKWy4419M= =oZQD -----END PGP SIGNATURE-----
