On Monday 19 December 2005 21:19, Jim Carter wrote: > On Fri, 16 Dec 2005, Blaisorblade wrote: > > On Thursday 15 December 2005 21:15, Jeff Dike wrote: > > > On Thu, Dec 15, 2005 at 05:26:44PM +0100, Blaisorblade wrote: > > > > The problem is that the same declaration is used in kernel sources. > > > > I.e., we have (likely) COW files generated from 64-bit machines using > > > > a different format from 32-bit ones. So we have two incompatible > > > > formats out there in the wild. > > > > > > Hummm, this seems to call for a V4. > > > > In short, not needed. > > > > Very short term solution is to build 32-bit and 64-bit uml_moo versions. > > With the existing code - i.e. compile -m32, compile normally. > > > > Releasing a V4 is provably correct but suboptimal for 32-bit UMLs, where > > V3 and V4 would coincide. And actually, we've been lucky with this bug - > > it can be completely avoided.
> I'm having a related problem. This is with SuSE 10.0, kernel 2.6.13, with > a SKAS3 patch in the host (I tried and failed to determine *which* patch), > and UML utilities 20040114 (same behavior with utilities 20040406). > Architecture is i386 (Pentium-M). > I create a COW file and it comes out in the default v3 format. When UML > starts, the kernel complains "Size mismatch (206158430208 vs 805306368) of > COW header vs backing file". The numbers are 3x2^36 vs 3x2^28 (768 MB). I > dumped the header and looked at the source: uml_mkcow puts the size in > network byte order using htonll() (_bswap64). My guess is that the kernel > does not invert the swap, where it does so for all the other fields, but I > was not able to see in the kernel sources where this was (not) happening -- > the provided sources use cow.c which is nearly identical to cow.c for the > utilities, and I can see the call to ntohll and its definition as _bswap64. Yep, I remember this bug - I've not went as far as reading the whole of the rest of the email (although I'd say that I wouldn't suggest you forcing V2 - hasn't been used for ages). The problem lies in the #ifdef mapping ntohll to _bswap64 - in 2.6.13 it was changed in a wrong way (and not by anybody present here - somebody went with a "nice cleanup" without understanding what was going on). The bug is described here: http://www.user-mode-linux.org/~blaisorblade/news.html In this entry: ===== * 13 October 2005: UML/2.6.13.4-bs4 released * CAREFUL : 2.6.13 kernel changed the COW format from all previous kernels in an unintended way (and it wasn't our fault). -bs4 restores the previous format, but this means you likely won't be able to use the same COW files when switching from any 2.6.13 to -bs4; but -bs4 has the same format as any <= 2.6.12 or >= 2.6.14 UML kernel. While the comment refers to a "2.6.13" format and an "other kernels" format, it's clear that uml_utilities use the latter. Also, normally there's no need to use uml_mkcow - passing ubd0=<cow_path,backing file path> auto setups the COW file if needed (i.e. it doesn't exist). ===== -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
