From ghasseler at gmail.com Wed Aug 1 00:29:12 2007 From: ghasseler at gmail.com (Greg Hasseler) Date: Tue, 31 Jul 2007 18:29:12 -0400 Subject: [Udpcast] Initrd - Cast-o-Matic issue with mount In-Reply-To: References: Message-ID: <46AFB7B8.3030006@gmail.com> I did not test rebuilding the image with lzma, although I am sure it too would also work. I did, however, rebuild the image with cpio and gzip. To do so, one should first navigate into their image root. Then simply run the following string of commands: $find . -print | cpio -H newc -o | gzip -9 -c > /tmp/initrd A working initrd will now be located in /tmp. I am pleased to report that this means I now have a fully working multicast based imaging system working which I can use to image machines remotely. Thanks go to Michael D. Setzer II who gave me some help off list. ------------------------------ Greg Hasseler SUNYIT Computer Science Department Ooh, mommy, mommy, what I have now doesn't work in this extremely unlikely circumstance, so I'll just throw it away and write something completely new. -- Linus Torvalds From michelsj at sdb.k12.wi.us Tue Aug 7 22:01:16 2007 From: michelsj at sdb.k12.wi.us (Jeff Michels) Date: Tue, 07 Aug 2007 15:01:16 -0500 Subject: [Udpcast] Compiling Problem Message-ID: <46B88939.771F.00ED.0@sdb.k12.wi.us> Hello, I'm having trouble compiling the 2007-06-02 release. All previous releases compiled properly on the system. The system is running Trustix Secure Linux 2.2. gcc -v produces: Reading specs from /usr/lib/gcc-lib/i586-trustix-linux/3.3.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/html --enable-shared --enable-threads --enable-haifa --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++ --host=i586-trustix-linux --enable-stack-protector Thread model: posix gcc version 3.3.4 (Trustix) Here is the error I get when I run make: jeff at image /usr/src/udpcast-20070602$ sudo make gcc -g -O2 -Wall -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wshadow -DBB_FEATURE_UDPCAST_FEC -D_FILE_OFFSET_BITS=64 -DUSE_SYSLOG -DUSE_ASSEMBLER -O6 -DNO_BB -I. -I. -c -o udp-receiver.o udp-receiver.c cc1: error: unrecognized option `-Wdeclaration-after-statement' make: *** [udp-receiver.o] Error 1 Regards, Jeff Michels Technology Support Specialist The School District of Beloit (608) 361-4087 * This email was scanned for viruses by SDB Astaro Security Gateway v.7 From serni at serni.net Wed Aug 8 11:26:13 2007 From: serni at serni.net (serni) Date: Wed, 8 Aug 2007 11:26:13 +0200 Subject: [Udpcast] udpcast-busybox us udpcast sources In-Reply-To: <46B88939.771F.00ED.0@sdb.k12.wi.us> References: <46B88939.771F.00ED.0@sdb.k12.wi.us> Message-ID: <6e06094e75cb8f49a5e292a135215044@imap.serni.net> Hi all. First excuse my poor english. I've been working on a live usb/cd distro, Debian Lenny based, focused on pc cloning with partimage or udpcast ( pxe ) plus utilities ... Just started the live distro allows sending or receiving detected hard disks or partitions ( udp-* -p lzop --file /dev/{disk,partition} -P 9000 ), that works great with udpcast compiled from last sources but if i try to use udp-sender from live with udp-receiver from the last udpcast pxe image i get a message about lzop and blocksize too small. Thanks in advance. From tomc at bio.umass.edu Wed Aug 15 20:54:18 2007 From: tomc at bio.umass.edu (Tom Carpenter) Date: Wed, 15 Aug 2007 14:54:18 -0400 Subject: [Udpcast] can cast-o-matic's "Device to be copied" be ignored or bypassed? Message-ID: <46C34BDA.70007@bio.umass.edu> Subject line sums up the question. What I'm trying to do is to generate a "sender" initrd with cast-o-matic that mounts a partition (using cast-o-matic's "Other commands to be executed before transfer but after menu:") where image files are stored and then serve out the image files with udpcast. -- Tom Carpenter Computer Systems Specialist Biology 347 Morrill 611 North Pleasant Street Amherst, MA 01003-9297 phone: 413-577-2311 fax: 413-545-3243 email: tomc at bio.umass.edu From alain at knaff.lu Thu Aug 16 09:22:38 2007 From: alain at knaff.lu (Alain Knaff) Date: Thu, 16 Aug 2007 09:22:38 +0200 Subject: [Udpcast] can cast-o-matic's "Device to be copied" be ignored or bypassed? In-Reply-To: <46C34BDA.70007@bio.umass.edu> References: <46C34BDA.70007@bio.umass.edu> Message-ID: <46C3FB3E.6040905@knaff.lu> Tom Carpenter wrote: > Subject line sums up the question. What I'm trying to do > is to generate a "sender" initrd with cast-o-matic that > mounts a partition (using cast-o-matic's "Other commands > to be executed before transfer but after menu:") where > image files are stored and then serve out the image files > with udpcast. > Cast-o-matic is for configuring the "embedded system" to be booted on the system to be imaged. Mounting partitions containing image files on the other hand is typically something you'd do on the server, not in the embedded system Alain From tomc at bio.umass.edu Thu Aug 16 15:21:15 2007 From: tomc at bio.umass.edu (Tom Carpenter) Date: Thu, 16 Aug 2007 09:21:15 -0400 Subject: [Udpcast] can cast-o-matic's "Device to be copied" be ignored or bypassed? In-Reply-To: <46C3FB3E.6040905@knaff.lu> References: <46C34BDA.70007@bio.umass.edu> <46C3FB3E.6040905@knaff.lu> Message-ID: <46C44F4B.4050403@bio.umass.edu> Alain Knaff wrote: > Tom Carpenter wrote: >> Subject line sums up the question. What I'm trying to do >> is to generate a "sender" initrd with cast-o-matic that >> mounts a partition (using cast-o-matic's "Other commands >> to be executed before transfer but after menu:") where >> image files are stored and then serve out the image files >> with udpcast. >> > > Cast-o-matic is for configuring the "embedded system" to be booted on > the system to be imaged. > > Mounting partitions containing image files on the other hand is > typically something you'd do on the server, not in the embedded system > > Alain > I've been trying to use one system as both. I've got a PC with two hard drives; one used as the system drive for whichever operating system I want to boot and the other for storing the operating system/software image files. I've been able to use cast-o-matic sender images to do what I want but the process is a bit kludgy...press CTRL-C once I've gotten through the setup menu, go to one of the other consoles, create a mount point and mount the image drive, then start up udpsender with "--file" and serve out the image of choice. Part of the reason I've been doing it this way is that the server (on which I am not the admin) for the lab of PCs I'm managing is a Sun E250 running Solaris 9...do you know of anyone that's ported udpcast to Solaris for SPARC? -- Tom Carpenter Computer Systems Specialist Biology 347 Morrill 611 North Pleasant Street Amherst, MA 01003-9297 phone: 413-577-2311 fax: 413-545-3243 email: tomc at bio.umass.edu From breuer.jens at googlemail.com Fri Aug 17 13:44:08 2007 From: breuer.jens at googlemail.com (Jens Breuer) Date: Fri, 17 Aug 2007 13:44:08 +0200 Subject: [Udpcast] can cast-o-matic's "Device to be copied" be ignored or bypassed? In-Reply-To: <46C44F4B.4050403@bio.umass.edu> References: <46C34BDA.70007@bio.umass.edu> <46C3FB3E.6040905@knaff.lu> <46C44F4B.4050403@bio.umass.edu> Message-ID: <76ce20420708170444j6ef86f83j9cc6fea777186788@mail.gmail.com> On 8/16/07, Tom Carpenter wrote: > I've been trying to use one system as both. Hi Tom, I'm not going to interrupt your interest in solving your issue with udpcast, but I feel that udpcast doesn't really fit your needs in your special case. udpcast hast been built for the purpose to transfer images from a server to one or many clients over the network via multicast (at least that is the case if I am using udpcast). I think you should use tools like "partimage", "dd_rescue" or "dd" to accomplish your task, since you just don't need the detour over the network. All you need is a LiveCD with the necessary tools on it like Knoppix. I think your issue can be solved with udpcast also, but I don't get why you should use it in that case. Kind regards Jens From Humberto.Varela at utsa.edu Wed Aug 22 00:57:26 2007 From: Humberto.Varela at utsa.edu (Humberto Varela) Date: Tue, 21 Aug 2007 17:57:26 -0500 Subject: [Udpcast] Intel Macbook USB Keyboard and duplicate keystrokes - solution Message-ID: The problem described below (of duplicate keystrokes in Syslinux on an Intel Mac) goes away completely if you plug the keyboard into USB slot 1 on the back of the Mac. The slot is usually the closest to the headphone jack, typically located in the back of the Macs. Any other USB slot triggers duplicate keystrokes when you navigate through the UDPCast menu or even if you pull up a log TTY and try to type. Hope this helps others who have had this problem with UDPCast. ***** Humberto J. Varela Humberto.Varela at utsa.edu Fri Apr 13 02:56:41 CEST 2007 I am using two UDPCast cds (one sender, one receiver) to boot two Intel MacBooks in an attempt to clone one to the other. Ok, it didn't exactly work out 100% Turns out when I boot my custom UDPCast cds, the SATA Disk Driver and the Marvell Yukon Network chipset in the MacBook fight with each other for IRQ assignment, and UDPCast finally just turns one IRQ off. IRQ 10. Meanwhile, I attached an external Microsoft USB 105-Key Keyboard to a MacBook to see if UDPCast would work with it and it did. But the "repeated ghost keystrokes" are still happening that plague the internal MacBook keyboard. So it seems that UDPCast is not playing well with the USB Controller in the MacBooks. It's not the keyboard. It's the controller. If I can identify the USB controller manufacturer, I might be able to insert the proper USB kernel module at boottime and finally be able to type into UDPCast after it boots. That would make it easier to guide through the menu-driven system that UDPCast uses in default-mode. It would also let me read the system boot log with the limited shell that I call up. So as for my experiment, both MacBooks boot up into a state that is ready-to-go, but they can't see each other on the network. This is most likely due to the IRQ conflict I'm getting from the SATA drive vs. the Network chipset. Network ports do light up on the switch I'm using, but the two computers won't see each other. I've even tried two different switches in case one had some kind of internal circuit that blocked Multicast Packet Storms or something... Has anyone tried UDPCast cloning of Intel-based MacBooks? -------------- next part -------------- An HTML attachment was scrubbed... URL: