> I found what's wrong. > > The size of an AxFS image created by mkfs.axfs is always n*4096+4 bytes large. > So when it wants to check the magic value in the last 4 bytes, the block layer > tries to read a whole 512-byte sector, which fails for loop-mounted images. > > If you test on real FLASH, additional bytes after the end of the AxFS image > can > be read, hence it works. > > By padding the image with 508 zero bytes, I can mount it, on both PS3 (ppc64) > and UML (ai32). I can even read images created on PS3.
Right. We haven't tested loopback since we added the magic end value. How is one expected to read those last 4 bytes of a loopbacked file? Are they unreadable? We can add the padding. I am just wondering if this is a bug or a known limitation in the loopback handling or if there is a different safer way of reading block devs with truncated last blocks. > However, there still are weird things going on, like `find' not seeing all > files and directories, or just aborting, and `ls -lR' showing actual file > contents in its output. Do you see this behavior for all builds for just the PS3? -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
