PC reboots during copying files (new onto old revision on seperate partition)

[meanwhile]

On a PC with -among others- a Haiku and a BeOS partition, it used to be possible to mount Haiku from BeOS and use Mount Image to do the same with a newer revision of Haiku. Copying and replacing the files from the new revision onto the old Haiku install no longer works: the PC reboots during the process. I guess this occurrence isn't (or can't be) logged anywhere...the only thing I can say is that it always used to work and that the last file being copied before the reboot seems to be "Vorbis" (if my eyes are fast enough).

[meanwhile]

I tried with hrev26139; previous still working partition must have been hrev26003. Booting the partition now shows an error.

[meanwhile]

I'll test all the revisions between hrev26003 and hrev26139 in the coming days.

[stippi]

So BeOS reboots when you try to copy files to the Haiku partition? Have you turned off the "bluescreen" in your BeOS kernel settings file? In case it is turned off, can you turn it on and tell the output of the BeOS KDL, also what the "sc" command gives? I am guessing your Haiku partition got corrupted and the BeOS BFS can't cope with it. Unless I misunderstand the report.

[meanwhile]

It's the entire PC that shuts down and reboots...Plz let me know if your advice is still valid with that info...

[meanwhile]

Hmm, on second thought it's the same thing :D

[meanwhile]

Got to go to work now, will try your advice tomorrow.

[mmlr]

Just clarify if this happens under BeOS. If you are in BeOS and the PC reboots when copying files, this cannot be caused by Haiku. None of the files are executed (they can't even be, as Haiku binaries aren't runable on BeOS anymore). So if this is really the case it would be a BeOS/BFS problem, independent of the Haiku files/revision. As Stephan mentioned it is probable that your Haiku partition got corrupted and BeOS' BFS is crashing because of that. In that case you should copy everything that you still need off of that partition (assuming it doesn't reboot doing that) and re-initialize the partition with a fresh BFS.

[meanwhile]

Replying to mmlr:

Just clarify if this happens under BeOS. If you are in BeOS and the PC reboots when copying files, this cannot be caused by Haiku. None of the files are executed (they can't even be, as Haiku binaries aren't runable on BeOS anymore). So if this is really the case it would be a BeOS/BFS problem, independent of the Haiku files/revision. As Stephan mentioned it is probable that your Haiku partition got corrupted and BeOS' BFS is crashing because of that. In that case you should copy everything that you still need off of that partition (assuming it doesn't reboot doing that) and re-initialize the partition with a fresh BFS.

Back from my (dead-end) job I can say it does happen under BeOS (Dano) when copying files, making it a BeOS/BFS problem, like you said. I emptied the partition, except for a non-removable 'Home' folder with an empty equally non-removable 'Desktop' in it, after which I replaced those two with the contents of the mounted new revision. During the copying of files the PC still reboots, so I'll start working on this partition with Partition Magic, to try and clean it up. Thanks for the help and this ticket should be marked invalid.

[meanwhile]

P.S. Success after copying the files "in bits and pieces", rather than through 'replace all'.

[mmlr]

Making the partition empty by removing all files does _not_ necessarily cure a corrupted filesystem. If you want to start over with a filesystem, you should just use DriveSetup to reinitialize said partition with a completely new BFS. That should resolve this kind of problem. Closing the ticket as it is a BeOS/BFS issue.

[Bouncer]

I believe I have experienced this same problem:

Here are some of my observations. For what they are worth.

When I first encountered this problem - I got the Beos KDL. With a message like "Panic error cache can't allocate data memory" From the 'MoveTask' thread in the tracker team.

I then tried increasing the Virtual Memory. It stopped KDL'ing. Now the BeOS was just hung!

Then I experimented with Initiallizing the target partition. This was rather interesting.

Beos really does not like to copy files from the haiku image onto a partition Initiallized with larger block sizes. I.e.: It likes the target partition to have a 1024 byte block size rather than a 2048 byte block size. Almost never hangs or crashes when using the smaller block size.

I had initiallized with 2048 byte blocks because thats the 'recommended' size according to haiku's disksetup. But

I know this is a 'BeoOS' problem. But are we absolutly sure that a similar problem does not exist in Haiku?. If one drags/copies the image files onto another filesystem having a different block size?

[anevilyak]

Yes, this is a BeOS-specific issue, various aspects of the VM and cache make calculations on the assumption that the volume has 1KB blocks, which break badly when that's not the case. One way of limiting the damage is to set a fixed cache size in ~/config/settings/kernel/drivers/kernel, but realistically on BeOS 5 it's a bad idea to use a non-1KB volume. Haiku has no such issues since it has an entirely different VM/cache architecture anyhow.

[meanwhile]

Hmm, I've installed a lot of new revisions with the help of BeOS and until recently, they all succeeded. Another factor is that I can't work from another Haiku partition (the HD on this hardware has a Windows, two Haiku and one BeOS partition) because the 'Mount Image' app. doesn't work on it.