Last night I committed my first version of this tool. Please have a look. It's in ./sbin/mkbootpackage. We can re-name if if appropriate. Also, the way I've written it is not set it stone, but was my first attempt to do what we're looking for. I'm sure there are some things that will need to be changed.
This has only been tested on x86, and I have yet to actually try to boot from a resultant boot package, but it should work fine. Currently works with cramfs, ext2, ext3 (see ext2), jfs, and reiserfs. xfs hooks are in place, but the machine i was working on didn't have xfs support for me to test with. It makes some assumptions that I should probably clarify in the --help and/or man page: - that you are running it on a system with a similarly configured kernel (but not necessarily the same kernel) as the one you want to use for your boot package. - there may be others I need to libraryize it, but want to have our "how should we name our libraries" discussion first. Need to man-page it. Do a "cvs up" and a "./sbin/mkbootpackage --help" for details. Cheers, -Brian Thus spake Brian Elliott Finley ([EMAIL PROTECTED]): > Thus spake dann frazier ([EMAIL PROTECTED]): > > On Mon, Oct 20, 2003 at 02:36:00PM -0500, Brian Elliott Finley wrote: > > > > > > Are there any major distros that don't include a .config file with their > > > kernel(s)? I know that SuSE provides a /proc/config.gz, which is > > > _really_ nice, that we could always check for first as it will always > > > match the running kernel. > > > > Debian & RedHat install a /boot/config-<vers>. > > however, people who build their own kernels will need to point us to theirs. > > I think that one required option would be --config (or similar) to > point to the kernel's .config file. > > > > This is a difficult question. > > > > > > Brain storming: dmesg freshly booted machine will tell us the order that > > > certain drivers were loaded, but not necessarily info for all devices. > > > I think some drivers may load silently. > > Your comments below are true. What I was thinking, and I guess I didn't > say, was that we could require a reboot immediatly prior to running the > command that would gather this info. Still hackey, and not guaranteed, > but might still be worth considering. > > Also, I am now going to dig up code sent to me by Benoit des Ligneris, > who has put together a similar system for an OSCAR off-shoot. At a high > level, it does what we want, but it may not do it exactly as we want. > He has also offered development time (his students) to assist in making > modifications to suit our needs. > > Look for this code momentarily. > > -Brian > > > > quite often the ring buffer will be overwritten or a user is running > > a daemon that periodically clears this. floating-point assist faults > > make this very likely on ia64. > > > > > However! It seems that I've never met a network or disk driver that > > > didn't record some info into the ring buffer. Maybe we can use that in > > > some way? > > > > the inconsistencies make this difficult - we'd need some special code > > to deal with the parsing of the messages for each driver. > > > > > > Once we have the list of modules, we can determine which ones reside > > > > in drivers/net, and make sure those are loaded in the initrd. It'd > > > > probably also be a good idea to copy over modules.conf, so we get > > > > any weird options that may need to be passed. > > > > > > Some systems now use /etc/modules also, or instead of modules.conf. > > > We may need to take that into consideration too. > > > > yeah. > > -- > --------------------------------------------------------- > Brian Elliott Finley Phone: 630.803.8183 > GPG: 3FF8 D096 0E0C D3F3 29B7 6518 D20B 1931 10F8 EE52 > --------------------------------------------------------- -- --------------------------------------------------------- Brian Elliott Finley Argonne, MCS Division Phone: 630.631.6621 http://thefinleys.com GPG: 3FF8 D096 0E0C D3F3 29B7 6518 D20B 1931 10F8 EE52 --------------------------------------------------------- Hi! I'm a .signature virus! Copy me into your signature to help me spread! ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
