> > > Why are you trying so hard to create an initrd image? I would just > > > compile the modules statically into the kernel and forget the whole > > > initrd thing altogether if I were you. The distro packagers have all > > > the time and resources they need to create their initrd images, which > > > is why they do it for their shipped versions, but the average Joe who > > > compiles his own kernel doesn't really need to do that.
I take issue with this comment. For one thing initrds are very useful thing. Just like I don't run windows on my servers cause I don't need an entire gui, com+ and ton of other stuff taking up resources, I don't need driver probing modules, modules for hardware that does get used but rarely, network stacks that I need for some hardware at times and a ton of other stuff floating around in my kernel all the time. An initrd solves many of these problems. Not to mention that initrds make the job of an admin that doesn't want to custom compile a kernel for every slightly different system setup they have a lot easier. They also make it possible to do such things as network boots and root filesystems on things like loop back devices for encryption or to avoid partitioning a ntfs mess. The entire opensource movement has been based on ideas including that of people do have the time and talents to use such things. If something as fundamental as setting up a very simple root filesystem to boot strap another is a job to complex for anyone but a full time paid distro developer, than this idea is dead. Anyone who has set up a daemon to run in a chroot environment or put together a linux from scratch system (which many on this list have) is perfectly capable of using an initrd. If your reply to someones question does not have more substance than you're too dumb to do that then please don't respond. It doesn't help the person asking the question or anyone else. They are highly likely to never ask a question on the list again for that matter. > Ah, well there you have it. If things do not work out once you apply > the official Debian kernel patch, you may want to escalate this issue > to another (development) mailing list. Either that, or engage in some > Happy Fun Kernel Debugging. Block decompression in cramfs has > historically had issues in the 2.4 kernel, especially for larger > cramfs images, but I would be surprised if this has not been resolved > in 2.4.22... It is still broken and the apparently will not be fixed. Not to mention the fact that the bug the prohibits initrds from being released was introduced and discovered in 2.4.22-pre3. It appears that it may have been fixed in 2.4.22-pre2 but I do not have time to confirm that. Oh and thanks for informing me that this isn't the place to ask this question since it isn't a development list. Thankfully there are other people on this list who are a lot more useful than you. Hans pointed me in the right direction without telling me that I am a moron. Yes I am in a bad mood today. Don't rub it in. >>>------> -- +-------------+-----------------------+---------------+ | Ed Schaller | Dark Mist Networking | psuedoshroom | +-------------+-----------------------+---------------+
signature.asc
Description: Digital signature
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
