Try to recompile 2.4.25 to reduce size, but got error" can not open initial console" with the new boot kernel.
Thanks jackie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 8:07 PM To: [EMAIL PROTECTED] Subject: Sisuite-users digest, Vol 1 #191 - 4 msgs Send Sisuite-users mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/sisuite-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sisuite-users digest..." Today's Topics: 1. Re: Re: bug in systemconfigurator? (Michael Chase-Salerno) 2. Re: [Systemimager] [Sisuite-users] systemimager rsync problem (Bas van der Vlies) 3. Re: RE: Sisuite-users digest, Vol 1 #188 - 2 msgs (dann frazier) 4. Re: Re: SI and IA64 (dann frazier) --__--__-- Message: 1 Subject: Re: [Sisuite-users] Re: bug in systemconfigurator? From: Michael Chase-Salerno <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue, 16 Mar 2004 09:55:08 -0500 Reply-To: [EMAIL PROTECTED] Correct me if I'm wrong here, but doesn't the function in SystemInstaller do a lot of this? If you use the "mksimachine" command you can easily query or change which image is installed on which nodes. It also does all the underlying changes that need to happen to effect the update, and maintains a database of the system configuration. It may not be 100% there, but its written and has been pretty heavily tested. One thing that we've discussed before is splitting the image building portion and the command line/front end portion of SystemInstaller and making the front end piece a required part of SIS and that would become the interface. Maybe its time to open that discussion up again? Mike On Mon, 2004-03-15 at 15:47, Brian Elliott Finley wrote: > Mark, > > This sounds really quite cool, and I appreciate your comments. I agree > that some of SystemImager has gotten unwieldy, and does not prevent a > user from getting bits of the system out of sync. I'm saving your > comments here, and will review them again when we get to the point of > implementing a solution. > > Thanks! > > -Brian > > > Thus spake Mark Seger ([EMAIL PROTECTED]): > >The thing that I've found very frustrating in learning how to use > >SystemImager is trying to figure out all the different steps one needs > >to do through to change which image is installed and where, especially > >because if you get one step wrong it does't work. To that end I built a > >tool that looks at file that contains entries something like this: > > > >#Config Net Abs/Rel BaseHost BaseAddr > >Mask Gateway > >mjsconfig eth0 S mjstest00.cag.com 192.168.250.40 > >255.255.255.0 - > > eth1 S - 16.21.17.40 > >255.255.248.0 16.21.16.253 > > > >This file contains mulitple names of configurations and describibe how > >to set up the network address ranges along with masks and gateways. In > >this case, the network addresses are created sequentally, and the host > >names always contain at least 2 trailing digits. > > > >This second file > > > >#MapName Script Name Nodes ConfigName Overrides > >mjstest mjsscript 6-8 mjsconfig > > > >says to take the setting in the first file for 'mjsconfig' and use them > >to install the image pointed to by the script 'mjsscript' using the > >overrides (if specified). they get layed down on nodes 6-8 which are > >described in a 3rd file that contains their mac addresses. > > > >I can then run a single script that uses this information to create a > >dhcpd.conf file, populate the overrides directory, create a set of > >softlinks for each hostname and point them to the master installation > >script, remove any files put in the /tptp directrly by netbootmond, > >create a new hosts file in the scritps directory as well as the images > >(by putting that too in the overrides directory) and do what's necessary > >to get ALL network addresses set up on each client. From the users > >perspective this is the only thing they have to run, once the tables > >have been populated. > > > >I guess my point in mentioning this is that ideally I'd like to see this > >kind of capability in SI, in which from the users persective they have a > >single command to run and not the many that are currently required. At > >the very least, if something new is going to happen to support multiple > >networks don't create yet another mkfoo that needs to be run along with > >all the others. > > > >-mark > > > >>Subject: Re: [Sisuite-users] Re: bug in systemconfigurator? > >>From: Brian Elliott Finley <[EMAIL PROTECTED]> > >>Reply-To: [EMAIL PROTECTED] > >> > >>Thus spake Sean Dague ([EMAIL PROTECTED]): > >> > >> > >>>On Tue, Feb 17, 2004 at 04:44:15PM -0600, Brian Elliott Finley wrote: > >>> > >>> > >>>>>Ultimately, putting everything in the SIS database seems best. > >>>>> > >>>>>I'd prefer adding this data in the autoinstallscript.conf file vs. a > >>>>>post-install script - we'd then be able to do it all in one call to SC, > >>>>>and without teaching users any new commands/hooks. > >>>>> > >>>>> > >>>>The only problem with that is that each machine needs a different entry, > >>>>which would require a different autoinstallscript.conf file for each > >>>>machine. Perhaps we could: > >>>>- include code in the autoinstall scripts that checks for the existence > >>>> of a file such as above "./scripts/interfaces-by-host" (or similar) > >>>>- if the file exists, use it to configure network interfaces > >>>>- if it doesn't exist, do one of the current methods of DHCP, STATIC, > >>>> REPLICANT > >>>> > >>>> > >>>Another solution to this problem is to lean on the SIS DB more, and make > >>>autoinstall scripts "per client" instead of "per image". > >>>mkautoinstallscript would then generate a script specific to the client. > >>> > >>> > >> > >>I think I like this idea. Anybody else have comments? > >> > >> > >> > >>>>Now that I mention that, perhaps it makes more sense to have another > >>>>--ip-assignment METHOD, where METHOD is TABLE or DB. > >>>> > >>>>TABLE would use a file such as above that lived in the scripts > >>>>directory. The benefit of this is it's text-editable. > >>>> > >>>>DB would use the SIS db. Benefit of this is canonical data. > >>>> > >>>>My only hesitation to using the DB for everything (in this case) is that > >>>>it's very handy to be able to simply edit a text file. But, perhaps we > >>>>could have a $tool that would: > >>>>- suck all the assignment entries out of the database, and pop them into > >>>> $EDITOR. > >>>>- user can view and edit to his hearts content > >>>>- when $EDITOR is closed, if there are changes, the $tool would confirm > >>>> with user, then update DB to reflect changes made to the file. > >>>> > >>>> > >>>Vi is not a user interface, and is very error prone for scripting. Doing > >>>any mass change of this data is better scripted through a commandline > >>>tool that will reject bad data with a reason to the user. > >>> > >>> > >> > >>This is actually what I'm proposing -- just that the data could be > >>prepared using $EDITOR instead of only with command line tools. In a > >>number of cases, including many DNS management systems I've worked with > >>(internal applications to deal with many zones and hosts, that is) I've > >>found it really useful to be able to use my favorite editor to make mass > >>changes, then to have my changes parsed and accepted or rejected, > >>allowing me to edit again. Oh yeah, "crontab -e" is another example. > >> > >> > >> > >>>Otherwise you end > >>>up with a lot more questions on the mailing list which come from subtle > >>>formating bugs. > >>> > >>> > >> > >>We definitely want to avoid this. > >> > >>So, in order to do the $EDITOR bit above, we certainly need to have the > >>command line tools (or at least their libraries) in place first. So > >>I think it's reasonable to make the $EDITOR bit a secondary goal, and > >>perhaps we'll decide it's not even necessary depending on how the > >>command line tools come out. > >> > >> > >> > >>>>Yes. I like that very much. All the data remains canonical, and in the > >>>>database, and our code only has to have one method for looking up such > >>>>info -> the DB. But users can still use a familiar interface (their > >>>>$EDITOR) to make changes. Although, this certainly needn't be the only > >>>>interface. > >>>> > >>>> > >>>> > >>>>>------------------------------------------------------- > >>>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >>>>>Build and deploy apps & Web services for Linux with > >>>>>a free DVD software kit from IBM. Click Now! > >>>>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >>>>>_______________________________________________ > >>>>>Sisuite-users mailing list > >>>>>[EMAIL PROTECTED] > >>>>>https://lists.sourceforge.net/lists/listinfo/sisuite-users > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>--------------------------------------------------------- > >>>>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! > >>>> > >>>> > >>>>------------------------------------------------------- > >>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >>>>Build and deploy apps & Web services for Linux with > >>>>a free DVD software kit from IBM. Click Now! > >>>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >>>>_______________________________________________ > >>>>Sisuite-users mailing list > >>>>[EMAIL PROTECTED] > >>>>https://lists.sourceforge.net/lists/listinfo/sisuite-users > >>>> > >>>> > >>>-- > >>>__________________________________________________________________ > >>> > >>>Sean Dague Mid-Hudson Valley > >>>sean at dague dot net Linux Users Group > >>>http://dague.net http://mhvlug.org > >>> > >>>There is no silver bullet. Plus, werewolves make better neighbors > >>>than zombies, and they tend to keep the vampire population down. > >>>__________________________________________________________________ > >>> > >>> > >> > >> > >> > > > > > >------------------------------------------------------- > >SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >Build and deploy apps & Web services for Linux with > >a free DVD software kit from IBM. Click Now! > >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >_______________________________________________ > >Sisuite-users mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/sisuite-users > > -- Michael Chase-Salerno [EMAIL PROTECTED] IBM Linux Technology Center Poughkeepsie, NY Advanced Linux Response Team http://www.ibm.com/linux --__--__-- Message: 2 Date: Tue, 16 Mar 2004 10:24:05 +0100 From: Bas van der Vlies <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Systemimager] [Sisuite-users] systemimager rsync problem Reply-To: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: > hello > I have a Linux SuSE Enterpriser server 8.0 installed with systimager > (systemimager-server-3.0.1-4, systemimager-common-3.0.1-4, > systemimager-i386boot-standard-3.0.1-4). > My problem is if I play an image with the boat disk back, the following > message comes: > > start_syslogd > rsync -av 131.102.102.14: :boot/i386/standard/boel_binaries.tar.gz /tmp/ > @ERROR: Unknown module "boot" > rsync: connection unexpectedly closed (42 bytes read so far) > rsync error: error in rsync protocol data stream (code12) at io.c (150) > > the file boel_binaries.tar.gz is present on the server but in the listing > /usr/share/systemimager/boot/i386/standard/ > > which is the problem on the client? > > > > Is there a boot stanza in /etc/systemimager/rsyncd.conf: (on server) [boot] path = /usr/share/systemimager/boot -- -- ******************************************************************** * * * Bas van der Vlies e-mail: [EMAIL PROTECTED] * * SARA - Academic Computing Services phone: +31 20 592 8012 * * Kruislaan 415 fax: +31 20 6683167 * * 1098 SJ Amsterdam * * * ******************************************************************** --__--__-- Message: 3 Date: Tue, 16 Mar 2004 11:07:24 -0700 From: dann frazier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Sisuite-users] RE: Sisuite-users digest, Vol 1 #188 - 2 msgs Reply-To: [EMAIL PROTECTED] On Mon, Mar 15, 2004 at 05:45:55PM -0800, Li, Jackie (Yanhui) wrote: > Does anybody have documentation how to build boot kernel and initrd.img > using different kernel like 2.4.9-e25? there is documentation in the systemimager manual (in the faq) on making your own boot flavor. since it sounds like 2.4.25 might work for you, and you just need a smaller binary, you should be able to just do a custom build of this flavor. try doing a build from http://dannf.org/systemimager/systemimager-boot-2.4.25-20040316.tar.gz 'make kernel' will build a kernel in src/linux-2.4.25/arch/i386/boot/bzImage that you can use to replace your kernel file. you'll need to tweak the config in patches/linux.i386.config to set all the drivers you need to Y, and ones you know you don't need to N. --__--__-- Message: 4 Date: Tue, 16 Mar 2004 11:09:48 -0700 From: dann frazier <[EMAIL PROTECTED]> To: Mark Seger <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [Sisuite-users] Re: SI and IA64 Reply-To: [EMAIL PROTECTED] On Mon, Mar 15, 2004 at 01:33:59PM -0500, Mark Seger wrote: > Using /dev/sda > (parted) print > Disk geometry for /dev/sda: 0.000-140014.398 megabytes > Disk label type: GPT > Minor Start End Filesystem Name Flags > 1 0.017 100.016 FAT boot, lba > > and here's what's in my autoinstallscript on that same machine. isn't > the problem that the value of size for /dev/sda is "*"? yes - that's exactly it. systemimager grows the last filesystem to the end of the disk. you'll wanna change that to a static value for fat filesystems. ideally, systemimager would do a boundary check when creating the master script, and limit fat filesystems to their max size. --__--__-- _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users End of Sisuite-users Digest ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users
