after reboot: KDL: could not mount boot device!

[kaoutsis]

• i create a haiku installation from linux (gcc2) to the /dev/hdb8

(grub recognizes this partition as hd1,7) the name of the partition is 'Haiku' i booted from this partition successfully;

• i mounted a bfs partition named 'haiku-src' which had a haiku source tree;

this partition was initialized from hrev5; the history of this partition in brief is: many crashes and many replay logs after crash, when mounted from the haiku running machine. From this haiku running machine (boot volune is 'Haiku') i run in Terminal 'svn up' after 1 or 2 minutes kdl (see #2008)

• reboot the machine in order to run haiku from boot volume 'Haiku'

Replay log is needed, and ended up successfully (i think) during the boot process. The Haiku machine is now ready;

• i created a directory named trunk to the /home directory, cd to that

directory and svn checkout ​svn://svn.berlios.de/haiku/haiku/trunk haiku the check out finished successfully! Then

• i rebooted the machine and from the grub menu i select

again the previously selected volume 'Haiku' and then KDL (see serial.txt)

[bonefish]

I just had a maybe related case. After shutting down normally I tried to boot my boot partition in the bfs_shell and it replayed a good deal of journal entries. Booting anew the second partition would mount anymore. mount() failed with B_ERROR. After mounting the partition under BeOS it would also be mountable in Haiku again.

I haven't had this before and the fact that someone recently modified the block cache raises certain suspicions. :-)

[bonefish]

Replying to bonefish:

I just had a maybe related case. After shutting down normally I tried to boot my boot partition in

"... mount my boot partition..."

the bfs_shell and it replayed a good deal of journal entries. Booting anew the second partition would mount anymore.

"... wouldn't mount anymore."

mount() failed with B_ERROR. After mounting the partition under BeOS it would also be mountable in Haiku again.

I haven't had this before and the fact that someone recently modified the block cache raises certain suspicions. :-)

[kaoutsis]

Replying to bonefish:

mount() failed with B_ERROR. After mounting the partition under BeOS it would also be mountable in Haiku again.

I haven't had this before and the fact that someone recently modified the block cache raises certain suspicions. :-)

i just mounted successfully the 'haiku-src' under hrev5 :-) i forgot to try the 'Haiku' volume, but it's too late now, tomorrow.

[kaoutsis]

revision is hrev24775

[axeld]

I guess neither of you saved the original unmountable contents for inspection? Since BeOS could mount it, it's probably not related to the block cache. In that case, I would guess that some validity checks failed for some reason (either because they are wrong, or the data in the log was problematic - which would bring the block cache back into the game, though).

Does chkbfs mentions any problems on that volume afterwards?

[kaoutsis]

Replying to axeld:

Does chkbfs mentions any problems on that volume afterwards?

$ chkbfs /haiku-src/
bfs: /dev/disk/ide/ata/0/master/0/0_5 is read-only!
Files processed: 218839
BFS has 998 blocks allocated that should not be.

    Block allocation mismatches detected.  Fixing.

    File system check completed.
$ uname -a
BeOS trantor 5.0 1000009 BePC unknown

[kaoutsis]

Replying to axeld:

I guess neither of you saved the original unmountable contents for inspection?

next time, i will :-)

[kaoutsis]

Replying to kaoutsis:

Replying to axeld:

this one was the boot device

$ chkbfs /Haiku
bfs: /dev/disk/ide/ata/0/slave/0/0_7 is read-only!
Files processed: 159090
BFS has 2 blocks allocated that should not be.

    Block allocation mismatches detected.  Fixing.

    File system check completed. 

[kaoutsis]

The boot device 'Haiku' booted successfully, but it couldn't mount the 'haiku-src' device, although was mounted and chkbfs-ed from hrev5 (and of course cleany unmounted after the hrev5 rebooted): When i try to mount from haiku, serial gives:

bfs: Replay log, disk was not correctly unmounted...
run count: -1, array max: -2, max runs: 126
bfs: Log entry has broken header!
bfs: replaying log entry from 820 failed: Bad data
bfs: could not initialize journal: General system error!
bfs: bfs_mount:120: General system error

Does all these make any sense?

[axeld]

Would it be possible to attach the disk's superblock and the log region to this bug? You can use the bfsinfo tool to retrieve the super block, and see at what location the log file is (or you can send me the super block, and I tell you what blocks I need).

At least I've already located a synchronization bug in BFS that was made much more likely due to the recent block writer changes.

[axeld]

Thanks to Vasilis, one problem is now clear to me: BeOS just mounts this volume even though the log is corrupt, it just ignores it, and leaves the user with a potentially corrupted disk.

That's certainly an option, but maybe we should only allow mounting it read-only then?

The first log entry seems to have been overwritten by another entry. This could have happened until recently, although it shouldn't have been very likely (the block writer bug would have been perfect to trigger this, though).

I guess this bug is fixed since hrev24792.

[anevilyak]

Hi Axel,

I just encountered this read-only volume issue with the newest version that fixed the deadlock by doing an svn checkout followed by an attempted build...what blocks would you like a dump of from the partition? I only have access to the partition from Linux unfortunately, so I can't directly use bfsinfo.

[anevilyak]

Hi,

I've uploaded a dump of the first 20 megs of my partition to sourceforge...you can get it at ​http://vision.sf.net/img.dump.bz2

Let me know if you need any other sectors off the disk.

[mmadia]

I can easily generate this issue. (mount a non-boot BFS partition) mkdir /walter ; mount walter.image /walter copyattr -d -r * /non-bootBFS sync # just for paranoia's sake (unmount) (re-mount -- failure)

luckily this is on a Haiku-only pc with nothing sensitive on the hard drive.

possibly on rev24784 --- i'd need to check to confirm

[mmadia]

recalling from memory, my syslog looks very similar to kaoutsis 's serial log. the log entry numbers were different, but the general error message was the same.

[mmadia]

bfsinfo -s /bad_partition > this_attachment

[anevilyak]

Further info, bfs_shell gives me this: bfs: Replay log, disk was not correctly unmounted... run count: 1002310361, array max: 63, max runs: 126 bfs: Log entry has broken header! bfs: replaying log entry from 2363 failed: Unknown error 2147483664 bfs: Replaying log failed, data may be corrupted, volume read-only. bfs: mounted "Haiku" (root node at 524288, device = /dev/sda3)

[axeld]

Fixed in hrev24853.