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?
I have found a solution to this problem, but it involved using the latest PLD Linux Rescue CD.
Transfers of an 80Gb hard drive partitioned into EFI, HFS, and NTFS work rather flawlessly from one Intel MacBook to many.
One small annoyance: I am having excessive re-xmits, most likely due to an improper kernel module (sky2) or some setting in eth0. I have managed to reduce the re-xmit rate to about 6% from 50% using --nosync on the targets. However, this is still unacceptable, as the throughput degrades slowly during the multicast transfer.
Nevertheless, PLD Linux Rescue CD seems to support the Apple USB Keyboard as well as internal Gigabit Ethernet chip.
-----Original Message----- From: Humberto J. Varela Sent: Thu 4/12/2007 7:56 PM To: udpcast@udpcast.linux.lu Subject: Intel Macbook
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?
-
Humberto J. Varela -
Humberto Varela