From Raymond.Langley at saultcollege.ca Mon Jul 21 19:11:00 2008 From: Raymond.Langley at saultcollege.ca (Raymond Langley) Date: Mon, 21 Jul 2008 13:11:00 -0400 Subject: [Udpcast] Intel 82566 NIC driver Message-ID: I too am looking for the 755 alpha build do you have a link to it? http://udpcast.linux.lu/pipermail/udpcast/2008-January/000807.html Raymond Langley IT Specialist, Information Technology Services Phone: (705) 759-2554 ext. 2786 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Udpcast at udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast From adoutte at gmail.com Sat Jul 5 17:20:47 2008 From: adoutte at gmail.com (Mathieu Adoutte) Date: Sat, 05 Jul 2008 15:20:47 -0000 Subject: [Udpcast] Problem cloning Dell latitude laptops Message-ID: Hi, I'm trying to clone several dell latitude laptops, but I can't seem to find the correct driver for the hard drive (when i pick the default choice, I get only "Other" in the partition list). Is there a way to locate the correct one ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raymond.Langley at saultcollege.ca Mon Jul 21 19:23:14 2008 From: Raymond.Langley at saultcollege.ca (Raymond Langley) Date: Mon, 21 Jul 2008 17:23:14 -0000 Subject: [Udpcast] Intel 82566 NIC driver Message-ID: I too am looking for the 755 alpha build do you have a link to it? http://udpcast.linux.lu/pipermail/udpcast/2008-January/000807.html Raymond Langley IT Specialist, Information Technology Services Phone: (705) 759-2554 ext. 2786 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allcoms at googlemail.com Thu Jul 24 18:45:48 2008 From: allcoms at googlemail.com (allcoms) Date: Thu, 24 Jul 2008 16:45:48 -0000 Subject: [Udpcast] clonezilla, drbl and udpcast Message-ID: Hi udpcast list! I work as an IT technician and certainly one of the most invaluable tools for my line of work has become the excellent open source cloning app Clonezilla. I have found it many times faster than ghost in creating images of NTFS partitions as well as being more reliable in many cases too. AND its FOSS so- very cool tool indeed! Clonezilla has a server-side counterpart app called drbl (diskless remote boot Linux). drbl is still in beta but when its finished it aims to provide functionality similar to Ghost Server, as found in Ghost Solution Suite. drbl uses udpcast to do its broadcasting of images over a network and the easiest way for people to try out drbl is to download drbl-live from http://free.nchc.org.tw/drbl-live/testing/ http://free.nchc.org.tw/drbl-live/unstable/ or http://drbl.sourceforge.net/download/sourceforge/ I can't wait to be able to totally replace Ghost with clonezilla/drbl, but I'm unable to switch from ghost server to drbl for 2 reasons 1- drbl-live server setup script/ ncurses GUI currently presumes you have multicast capable hardware and doesn't offer a mode to utilise udpcasts -brdcast mode easily yet but the author says he'll think about adding this capability. 2- drbl-live also requires that you either enter a specific time to wait or number of clients that have to connect or both. In my experience with using ghost server to image many machines you will know how many machines you WANT to image but you don't know how many of them will actually be able to connect to the server due to hardware failures and also you don't know just how long it will take to get all the machines connected to the server. Hence, I want drbl-live's Clonezilla server setup script to be able to work just like gs in that after setting the network settings and selecting the image to be broadcast etc. I would just select 'Listen for clients' or whatever. Then I would have an indefinite amount of time to run around and TRY to get everything connected to the drbl server. As each client connects to the server, it would get registered on the drbl console. When I've connected as many machines as possible, I would just be able to hit a key to start the broad/multicast. Setting a definite amount of time to wait or number of machines wouldn't work for me! The author of clonezilla and drbl has told me that #2 isn't do-able because this isn't supported by udpcast. Is he mistaken? Thanks for your help! Dan From alain at knaff.lu Thu Jul 24 19:56:53 2008 From: alain at knaff.lu (Alain Knaff) Date: Thu, 24 Jul 2008 17:56:53 -0000 Subject: [Udpcast] clonezilla, drbl and udpcast In-Reply-To: References: Message-ID: <4888C263.7050205@knaff.lu> allcoms wrote: [...] > When I've connected as many machines as possible, I would just be able > to hit a key to start the broad/multicast. Setting a definite amount > of time to wait or number of machines wouldn't work for me! > > The author of clonezilla and drbl has told me that #2 isn't do-able > because this isn't supported by udpcast. Is he mistaken? Bull. This is actually the default mode of udpcast operation: press a key (on either the sender or on any of the receivers) to make the transfer start. Starting after a given time and/or after a certain machines are ready are relatively late additions to the code. The basic mode of operation is wait for keystroke to start. And if a hardware failure would happen to any receiver *after* the transfer had already been started (i.e. after that keypress), it will wait for a small timeout (couple of minutes), then drop the offending receiver, and continue. > Thanks for your help! > > Dan Regards, Alain From bputnam at novell.com Thu Jul 31 20:19:21 2008 From: bputnam at novell.com (Brent Putnam) Date: Thu, 31 Jul 2008 18:19:21 -0000 Subject: [Udpcast] Timeout errors in UDPcast Message-ID: <4891C9DE.9E07.00D3.0@novell.com> Running SuSE SLES10/SP2 and an image of about 17GB. When multicasting clients, performance appears to suffer from a excessive number of timeouts and/or retransmits. If the images are smaller this is not a problem, but we currently need them this size. The errors appear frequently: Timeout notSnasweed=[1] notReady=[1] nrAns=2 nrPart=3 avg 10193 We added the configs of rmem_default and rmem_max in the /tftpboot directory substructure in init.d for the client. It does seem to affect the speed, but still winds up bombing out on the big partition (~17GB). It's an IBM blade center w/SAS drives which do not have cache. TIA, Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: