and now that I have your attention I want to bring up another topic that both steve and I have had mulitple conversations with dann frazier about and that's grub and the fact that it doesn't work with many of our systems with Smart Array controllers on them. As you've no doubt seen in the mailing list steve and I have come up with some solutions that do indeed work in the environments we've been testing in. The bigger questions are how to move forward because we're found bugs in both grub, grub-install, Boot.pm and Label.pm. Admittedly this is outside the domain of SystemImager proper, but nevertheless SystemConfigurator is called by SystemImager and it'd sure be nice to minimize the number of players in this. Furthermore, just yesterday we found some problems with updateclient as well. finally there's the whole topic of how to implement the fixes as there are mulitple ways one might proceed. Just as a small example, when doing an install we've found /etc/mtab to be empty and that causes a 'df' command in grub-install to break! the fix is to populate that file via a commaond like "grep ext3 /proc/mounts > /etc/mtab" and then all is well. But WHO should execute that command - grub-install, systemconfigurator or the autoinstall script? We put the fix into SC. and then where is the best place in SC to put it? we chose Grub.pm.
dann had suggested I post our findings on the mailing list to see what the resf of the world thinks but there has been minimal discussion on a topic that is at least very high in importance to steve and myself which is why we're already poured over 3 weeks, going on 4, into this between the two of us and we want to make sure our pain (yes, there has been a lot!) is rewarded by getting support into SystemImager as soon as possible. Do you have any suggestions as the best way to proceed? Would there be any benefit of doing a concall and perhaps including dann? some of the finer points of this are too subtle to convey in mail - or at least too wordy...
-mark
Brian Elliott Finley wrote:
Mark,
I like your comments, and your humor. ;-)
Can you send me a patch to netbootmond with the behaviour you believe it should have?
Thanks!
-Brian
Thus spake Mark Seger ([EMAIL PROTECTED]):
Actually this is pretty slick/sick (depending on your perspecitve) 8-)
The copy is supposed to fail! The process, netbootmond (which has a bug I'll get to in a minute now that you reminded me about it) watches the tail of the rcync log for that very message to occur and once it sees that, know the installation completed successfully and write an empty file such as C0A8F829 to the /tftboot/pxelinux.cfg directory. On the next pxe boot, this tells the client not to load a remote image but rather boot locally. This whole mechanism only works if you
1 - edit /etc/systemimager/systemimager.conf and change the last entry to NET_BOOT_DEFAULT = local
2 - service systemimager-server-netbootmond start
works like a champ to prevent an installed node from reinstalling. naturally when you want to reinstall a node you need to manually remove that file - C0A8F829 - which is actually an encoding of the network address, 1 octet to each 2 chars. There can also be done via mkclientnetboot.
now for the bug in netbootmontd...
as written, netbootmond sits in a loop and looks at the last record in the rsync log, but a colleague and myself have experienced a situation where a 3 line error messages gets long and the line containing the string "scripts/imaging_complete" is missed! The fix is to look deeper into the rsync file (in my case at least -n 3), the challenge is to avoid messages that were already seen/processed.
-mark
Message: 2 Date: Wed, 12 May 2004 04:29:58 -0500 From: Thomas Schenk <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Sisuite-users] mkautoinstalldiskette problem Reply-To: [EMAIL PROTECTED]
I didn't really mean to be such a smart ass in my reply and I did solve the problem by recompilining the kernel that get's installed on the boot floppy. I was just stressing that day due to a migraine.
On another note, however, there was still a problem (although not a show stopper). The final step of the install resulted in an error when a rsync attempt was made by the master script which tried to do something with the <systemimager root>/scripts/imaging_complete directory. (I think that is correct...I'm doing this from memory). Anyhow, supposedly it was supposed to do something with that file or directory and it couldn't because it didn't exist. Perhaps another packaging error in the RedHat RPMS?
Tom S.
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Sisuite-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-users
