Problems with udpcast in combination with a fileserver
Dear all, i've got a strange problem with udpcast. If i store the files on an ext3-partition on a fileserver via udp-reciever -f foo.image and clone it on the other notebook, i am not able to boot the new system on it. When i look on the hdd, i see the several partitions, but no partition types. What's my fault? I am getting more and more confused. Please help me. Mit freundlichen Grüßen Thomas Kühling -- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer Straße 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
Are the disk geometries the same on the master and target notebooks? Is lilo or grub or other used as the boot loader? If it is a problem from udpcast, I'd guess it has something to do with the first few bytes on the data. I saw a problem like this before where we could not boot an IBM notebook recovery partition. In our case the broadcom 5702 ethernet driver on the imaging server had a bug which went away in a 2.6.5 kernel driver. TCP/IP was reliable, but the driver bug was specific to UDP multicast. Even the Windows drivers for that Broadcom device had problems (at the time) immediately after DHCP connect. The other possible flaw that could go wrong is a bug in the ethernet driver on one of the notebook clients. Check the changelogs at kernel.org for hints there may be bug fixes for one of the ethernet devices you use. You can test to see if the images are the same on upload by using cmp to compare the image files. Upload twice and compare. Upload, image, and upload from the target and compare. This only works with gzip, as I learned, that lzop stores a timestamp inside the file. --Donald Teed On Mon, 12 Dec 2005, Thomas Kuehling wrote:
Dear all,
i've got a strange problem with udpcast. If i store the files on an ext3-partition on a fileserver via udp-reciever -f foo.image and clone it on the other notebook, i am not able to boot the new system on it. When i look on the hdd, i see the several partitions, but no partition types.
What's my fault? I am getting more and more confused. Please help me.
Mit freundlichen GrüÃen Thomas Kühling
-- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer StraÃe 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
_______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
Hi Teed, Am Montag, den 12.12.2005, 07:51 -0400 schrieb D Teed:
Are the disk geometries the same on the master and target notebooks? Is lilo or grub or other used as the boot loader?
not really. On the fileserver i am using a 300 GB SATA Maxtor HDD and in the Notebooks i've got a normal 60 GB HDD. I prefer to store several images on the 300 GB HDD. As i read in the advanced doku, the option --nosync for the udpreciever could help. I am just testing this. Therefore i tested directly to sync from one notebook to the other one and this worked without any problems. I think the problem is the storing of images on a normal ext3-partition.
If it is a problem from udpcast, I'd guess it has something to do with the first few bytes on the data. I saw a problem like this before where we could not boot an IBM notebook recovery partition. In our case the broadcom 5702 ethernet driver on the imaging server had a bug which went away in a 2.6.5 kernel driver. TCP/IP was reliable, but the driver bug was specific to UDP multicast. Even the Windows drivers for that Broadcom device had problems (at the time) immediately after DHCP connect. The other possible flaw that could go wrong is a bug in the ethernet driver on one of the notebook clients.
Check the changelogs at kernel.org for hints there may be bug fixes for one of the ethernet devices you use.
You can test to see if the images are the same on upload by using cmp to compare the image files. Upload twice and compare. Upload, image, and upload from the target and compare.
This only works with gzip, as I learned, that lzop stores a timestamp inside the file.
For testing-szenario i used only raw without any compression.
--Donald Teed
On Mon, 12 Dec 2005, Thomas Kuehling wrote:
Dear all,
i've got a strange problem with udpcast. If i store the files on an ext3-partition on a fileserver via udp-reciever -f foo.image and clone it on the other notebook, i am not able to boot the new system on it. When i look on the hdd, i see the several partitions, but no partition types.
What's my fault? I am getting more and more confused. Please help me.
Mit freundlichen Grüßen Thomas Kühling
-- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer Straße 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
_______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
Mit freundlichen Grüßen Thomas Kühling -- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer Straße 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Storing images on an ext3 partition should not make a difference from what I can tell. I have written the last thru versions of g4l, and it does exactly that. It uses dd with compression and then ftping it to the server. I've even used the images created with g4l with udpcast. I do note that when restoring an image to different drive, it has problems if the heads / sector ratio is not exactly the sime. The layout of the server that stores the image doesn't matter. I generally use g4l to create my images, and store them on a system with two 250GB drives, but then use udpcast to image the one system to the other 19 machines in the lab. On 12 Dec 2005 at 13:07, Thomas Kuehling wrote: Subject: Re: [Udpcast] Problems with udpcast in combination with a fileserver From: Thomas Kuehling <thomas.kuehling@mapsolute.com> To: D Teed <dteed@artistic.ca> Organization: Mapsolute GmbH Date sent: Mon, 12 Dec 2005 13:07:05 +0100 Copies to: udpcast@udpcast.linux.lu Send reply to: thomas.kuehling@mapsolute.com <mailto:udpcast-request@udpcast.linux.lu?subject=unsubscribe> <mailto:udpcast-request@udpcast.linux.lu?subject=subscribe>
Hi Teed,
Am Montag, den 12.12.2005, 07:51 -0400 schrieb D Teed:
Are the disk geometries the same on the master and target notebooks? Is lilo or grub or other used as the boot loader?
not really. On the fileserver i am using a 300 GB SATA Maxtor HDD and in the Notebooks i've got a normal 60 GB HDD. I prefer to store several images on the 300 GB HDD. As i read in the advanced doku, the option --nosync for the udpreciever could help. I am just testing this.
Therefore i tested directly to sync from one notebook to the other one and this worked without any problems. I think the problem is the storing of images on a normal ext3-partition.
If it is a problem from udpcast, I'd guess it has something to do with the first few bytes on the data. I saw a problem like this before where we could not boot an IBM notebook recovery partition. In our case the broadcom 5702 ethernet driver on the imaging server had a bug which went away in a 2.6.5 kernel driver. TCP/IP was reliable, but the driver bug was specific to UDP multicast. Even the Windows drivers for that Broadcom device had problems (at the time) immediately after DHCP connect. The other possible flaw that could go wrong is a bug in the ethernet driver on one of the notebook clients.
Check the changelogs at kernel.org for hints there may be bug fixes for one of the ethernet devices you use.
You can test to see if the images are the same on upload by using cmp to compare the image files. Upload twice and compare. Upload, image, and upload from the target and compare.
This only works with gzip, as I learned, that lzop stores a timestamp inside the file.
For testing-szenario i used only raw without any compression.
--Donald Teed
On Mon, 12 Dec 2005, Thomas Kuehling wrote:
Dear all,
i've got a strange problem with udpcast. If i store the files on an ext3-partition on a fileserver via udp-reciever -f foo.image and clone it on the other notebook, i am not able to boot the new system on it. When i look on the hdd, i see the several partitions, but no partition types.
What's my fault? I am getting more and more confused. Please help me.
Mit freundlichen GrüÃ"Yen Thomas Kühling
-- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer StraÃ"Ye 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
_______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
Mit freundlichen Grüßen Thomas Kühling
-- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer Straße 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
_______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+ http://setiathome.berkeley.edu Number of Seti Units Returned: 18,823 Processing time: 32 years, 168 days, 23 hours, 32 minutes (Total Hours: 284,376) -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 -- QDPGP 2.61c Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBQ5ze6CzGQcr/2AKZEQKhHgCeN96v1g3hPCCtTImyJA+rzK1lck4AnjOd PUurIzbGQeZUXfuGFQqm53iQ =fZ4a -----END PGP SIGNATURE-----
participants (3)
-
D Teed -
Michael D. Setzer II -
Thomas Kuehling