Re: [Sisuite-users] 3.6.3 network question, kudzu

Thu, 20 Jul 2006 23:41:07 -0700

Title: si_updateclient fails in both 3.6.3 and 3.7.1
Brian, what's your comment on this?
 
Thanks,
 
Bernard

From: [EMAIL PROTECTED] on behalf of Brodie, Kent
Sent: Wed 19/07/2006 11:21
To: [email protected]
Subject: Re: [Sisuite-users] 3.6.3 network question, kudzu

As far as the pxe issue--    the entire si_mkbootserver deal assumes there’s a pxe daemon, and a /etc/pxe.conf file, and so on.     Basically, with the newer implementations of redhat-  the pxe stuff just isn’t there.        It seems to have been documented in a few places that all you really need is the tftp server, and the dhcp server.   Syslinux (boot images and such for /tftpboot) is a snap.  

 

Therefore, (my opinion?) the si_mkbootserver tool should really do nothing more than to create the “glue” between the /tftpboot directory, and the images and scripts required for the clients to network boot.

 

For example, the following snippet from a nice netboot howto (with systemimager) reflects what I had to do to make it all work: 

 

For PXE-booting of clients across the network, copy the required
files to /tftpboot:
 
   mkdir /tftpboot
   cd /usr/share/systemimager/boot/i386/standard
   cp -p initrd.img kernel /tftpboot/
   cp -p /usr/lib/syslinux/pxelinux.0 /tftpboot/pxelinux.bin
   cp -rp /etc/systemimager/pxelinux.cfg /tftpboot/
   cp -p /etc/systemimager/pxelinux.cfg/message.txt /tftpboot/
 

 

Of course, you have to work around differences in architecture (in my case, x86_64 and not i386).     

 

The second part would be what “si_mkclientboot” does for all of the clients.

 

I don’t know if I am asking too much, or perhaps I am mis-understanding what si_mkbootserver is supposed to do.    >From my perspective, I have the following observations:

 

* Installing systemimager – and preparing the server to go fetch an image.   No issues- clearly documented.

* Installing a client- and preparing the client with an image to be fetched.  Again- no issues, and clear.

* Fetching the image, and setting up dhcp – pretty clear as well!

* Setting up the DHCP server and tftp/dhcp to network-boot clients.    This is where it all gets REAL fuzzy, and I had to depend on snippets from a variety of sources to figure it out.      Basically, I had to manually config dhcpd.conf with the fixed addresses, and do the commands laid out above, and then also run the si_netclientboot deal.        It’s this last part that could be well-served by a script or tool to assist (si_mkbootserver??); and I think the pxe daemon stuff is outdated…

 

That’s my $0.02.   Thanks!!!

 

 

 

 

---------------------------------------------------------

Kent C. Brodie - [EMAIL PROTECTED]

Department of Physiology

Medical College of Wisconsin

(414) 456-8590

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Li
Sent: Wednesday, July 19, 2006 1:06 PM
To: [email protected]
Subject: Re: [Sisuite-users] 3.6.3 network question, kudzu

 

Hi Kent:

 

Glad that this worked for you.

 

BTW, I'm trying to fix the "pxe" issue - so are you saying that we basically just need to remove the requirement for the "pxe" binary and change the descriptive text around, is that sufficient?

 

Regarding 3.7.3 - the MD5 checksum issue is caused by prelink, and we are currently trying to fix that (it's not easy...).  Anyways, to get around the problem building the RPMs, you can see the following page:

 

http://wiki.sisuite.org/SystemImager

 

Cheers,

 

Bernard

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brodie, Kent
Sent: Wednesday, July 19, 2006 10:57
To: [email protected]
Subject: [Sisuite-users] 3.6.3 network question, kudzu

Hi guys.   Well, after locking myself in my office for a day, I figured it out.  (amd x86_64, even with sata drives.  Happy happy happy!)   The si_mkbootserver stuff threw me off, when all I really needed was to run si_mkclientnetboot.  (si_mkbootserver still seems to insist on a pxe daemon, which really isn’t around anymore, especially for redhat!).

 

Anyway, I have a simple question--  a minor annoyance, but requires manual intervention upon booting a cloned client.

 

When the client comes up after being imaged, kudzu insists that the two network Ethernet devices were “removed”, and prompts the user to remove or keep them.  (then, kudzu “finds” the two network devices right away as well….).   the result is that if you accidently “remove device” as prompted, you wipe out the client’s Ethernet config and have to do it all over.     Choosing to “keep configuration” seems to work ok, but as I said- requires manual intervention when booting the first time.

 

Any idea why this is so?   Anyone know how I can prevent the system from being configured so it’s thinking the Ethernet devices are “new”?  

 

As I said- minor annoyance.   I’m pretty sure it’s a systemconfigurator thing, but the modprobe.conf entries that are commented out (and subsequently added!) are the SAME.  (alias eth0 tg3)…….

 

 

 

PS: I tried to build 3.7.x, but had issues on the client with the RPM failing the MD5 checksum.   I’m more comfortable using the (distributed, stable) rpms……..

 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sisuite-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users

Reply via email to