[Haiku-bugs] [Haiku] #3532: PANIC: ASSERT FAILED (src/add-ons/kernel/file_systems/bfs/BlockAllocator.cpp:448): !fLargestValid || start + length <= fLargestStart |
axeld
trac at haiku-os.org
Wed Mar 11 13:49:56 CET 2009
#3532: PANIC: ASSERT FAILED (src/add-
ons/kernel/file_systems/bfs/BlockAllocator.cpp:448): !fLargestValid ||
start + length <= fLargestStart |
------------------------------+---------------------------------------------
Reporter: luroh | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: File Systems/BFS | Version: R1 development
Blockedby: | Platform: All
Blocking: |
------------------------------+---------------------------------------------
Comment(by axeld):
This appears to be a duplicate of #2590. The new part is that you could
reproduce this on real hardware as well, which is *very* strange to say
the least.
With VMware the problem seems to be that it will also mirror the original
image on the other controller. While Haiku thinks there are two different
volumes, changes to the second will only always change the first. The
second is not touched at all. This should be pretty easy to check for.
You can prove that this is a VMware problem by running "sudo lsof | grep
vmdk" on the Linux host. This will show that VMware opened haiku.vmdk
twice, but haiku_copy.vmdk not at all. I have no idea why it does so,
changing the UUID of the second disk does not help.
So let's concentrate on the hardware case as the rest is irrelevant for
Haiku. What did you do exactly, is it reproducible, and what is the end
result? If you delete a file from the HD, will it be gone from the USB
stick at next boot? Are you sure you really removed the files from the
right disk? Can you use the Terminal to make sure? Ie. the following might
help:
{{{
$ df
$ cd /Haiku1
$ rm -rf beos
}}}
--
Ticket URL: <http://dev.haiku-os.org/ticket/3532#comment:3>
Haiku <http://dev.haiku-os.org>
The Haiku operating system.
More information about the Haiku-bugs
mailing list