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 <mailto:udpcast%40udpcast.linux.lu?Subject=%5BUdpcast%5D%20Intel%20Macbook&In-Reply-To=>
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?
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
Computer Systems Specialist
Biology 347 Morrill
611 North Pleasant Street
Amherst, MA 01003-9297
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@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
Technology Support Specialist
The School District of Beloit
* This email was scanned for viruses by SDB Astaro Security Gateway v.7