From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K8c9R-0006WC-BU for qemu-devel@nongnu.org; Tue, 17 Jun 2008 10:27:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K8c9O-0006Va-TY for qemu-devel@nongnu.org; Tue, 17 Jun 2008 10:27:12 -0400 Received: from [199.232.76.173] (port=52443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K8c9O-0006VX-Nu for qemu-devel@nongnu.org; Tue, 17 Jun 2008 10:27:10 -0400 Received: from kurt.tools.de ([192.76.135.70]:63294) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K8c9O-0003Ml-IM for qemu-devel@nongnu.org; Tue, 17 Jun 2008 10:27:10 -0400 Received: from imap.tools.intra (homes.tools.intra [172.20.0.4]) by kurt.TooLs.DE (Postfix) with ESMTP id AEAA945814 for ; Tue, 17 Jun 2008 16:27:06 +0200 (MEST) Received: from tiger2.tools.intra (tiger2.tools.intra [172.20.0.11]) by imap.tools.intra (Postfix) with SMTP id 911C94B442 for ; Tue, 17 Jun 2008 16:27:06 +0200 (CEST) Date: Tue, 17 Jun 2008 16:27:06 +0200 (CEST) From: Juergen Keil Subject: Re: [Qemu-devel] Re: Boot Failure (CDROM boot failure code : 0004) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5CuYJK1mtLG4J/HWZHW5lA== Message-Id: <20080617142706.911C94B442@imap.tools.intra> Reply-To: Juergen Keil , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Volkan YAZICI writes: > > On Tue, 17 Jun 2008, Volkan YAZICI writes: > > root:~# diff \ > > > /root/scd0.iso.md5sum > > > /home/windows/windows-server-2003-standard-x86-64-sp2.iso.md5sum > > 1c1 > > < b5d670b7360dc43af8157a50de43bac1 scd0.iso > > --- > > > cfcf3b24d9b44e75826259c9e914bf40 windows-server-2003-standard-x86-64-sp2.iso > > More interesting results: > > windows:~# md5sum windows-server-2003-standard-x86-64-sp2-dd-bs-* > b5d670b7360dc43af8157a50de43bac1 windows-server-2003-standard-x86-64-sp2-dd-bs-1024.iso > b253aa547f8a7269b6589caa001bd566 windows-server-2003-standard-x86-64-sp2-dd-bs-2048.iso > 64a9d318690bfe223b0e3c5c15b392e3 windows-server-2003-standard-x86-64-sp2-dd-bs-32768.iso > b5d670b7360dc43af8157a50de43bac1 windows-server-2003-standard-x86-64-sp2-dd-bs-512.iso > > Quite funny. (By the way, all of them are of same size.) Should I trust > that bs={1024,512} produce the right result? Anyway, neither of them > solve the problem. Any ideas? That is unexpected. I'd expect that you get exactly the same bits no matter what block size >= 2048 (and power of 2) you use. Some drives (or the OS) also allow block sizes of 1024 or 512 bytes, but you should still get exactly the same bits. Smells like a bug, either with the optical drive, or some driver, filesystem, or OS issue. What happens when you use "cmp -l" on a pair of the above iso images which have not have the same md5 checksum? At what file offset does it find differences? Only on the last 2-3 blocks of the file, perhaps? Does cmp -l only find a few differences per iso image pair? What are the differences?