PANIC: ASSERT FAILED (src/add-ons/kernel/file_systems/bfs/BlockAllocator.cpp:448): !fLargestValid || start + length <= fLargestStart |

[luroh]

Revision 29436, Vmware Player 2.5.0 (Ubuntu 8.10, 32-bit).

1. Build a vanilla 300 MB haiku-vmware-image.
   
2. Make a copy of it named haiku_copy.vmdk
   
3. Include the image copy in the haiku.vmx file:
   ide0:1.present = "TRUE"
   ide0:1.fileName = "haiku_copy.vmdk"
   ide0:1.deviceType = "disk"
   ide0:1.mode = "persistent"
   ide0:1.redo = ""
   ide0:1.writeThrough = "FALSE"
   ide0:1.startConnected = "FALSE"
   
4. Boot.
   
5. From the Haiku desktop, mount the copy image.
   
6. Double-click the copy image disk, press <Alt + A> and <Shift + Delete> to remove all files.
   

Result:

PANIC: ASSERT FAILED (src/add-ons/kernel/file_systems/bfs/BlockAllocator.cpp:448): !fLargestValid

start + length <= fLargestStart |

[luroh]

Furthermore, after encountering this panic, the original image is no longer bootable.

[luroh]

Repeatable on real hw as well:

1. dd a haiku-image to a USB stick and a hard disk.
   
2. Boot from the USB stick.
   
3. Mount and remove all files from the hard disk.
   
4. Try to boot from the USB stick again.
   
5. No profit.
   
   

In other words, you can render your system disk unbootable by removing files from another disk. Sounds potentially dangerous to me.

[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

[luroh]

It is perfectly reproducible. All I do is dd the same image file to a USB stick and a hard disk (both of them raw devices) in Linux, boot off the USB stick and delete files off the hard disk.

Yes, when following your terminal commands to the letter, it renders the USB stick unbootable. I can see a lot of USB stick activity when doing that, which I find suspicious.

Also a note: when booting the first time off the USB stick, the desktop looks strange; I can see both the normal Haiku system drive icon and a Haiku USB stick icon.

[luroh]

If you don't have a spare HDD available, the problem is also repeatable with two USB sticks.

Btw, a funny thing is, 'df' lists /boot as /dev/disk/ata/3/master/raw although it's in fact a USB stick. It does list /Haiku1 as /dev/disk/usb/0/0/raw.

And just to clarify; yes, after running your commands above, the beos folder is indeed missing from the wrong drive, making it unbootable.

Tested with rev 29481.

[luroh]

Hang on, I think I know what is going on here; Haiku picks up the presence of an old deleted Haiku partition on my SATA drive (an old revision number in About gave it away!):

1. Booting starts from the USB stick.
   
2. At some point during boot, the system detects an old deleted Haiku partition on the SATA drive and decides to set it as /boot. This explains why the system loaded slowly during bootsplash but fast once it reached Desktop.
   

To avoid 2 from happening, I not only had to delete the old Haiku partition on the SATA drive, but reformat the partition with an alien file system to completely rid it from its BFS-edness.

Perhaps we should close this ticket as invalid and start fresh, as it seems to have morphed into something completely different than it initially was.

Tested with rev 29529.

[axeld]

Okay, thanks for investigating this further! The problem is that the BIOS does not tell Haiku that it booted from USB. Once in the kernel, Haiku usually has to guess the drive from which it had been booted before; it uses some kind of heuristics, but apparently, they could be improved as your case shows.

But I agree, we should open a new ticket for this problem. Should I do it, or do you want to? :-)

[luroh]

Done in #3569.