Opened 11 years ago

Closed 11 years ago

#2024 closed bug (fixed)

after reboot: KDL: could not mount boot device!

Reported by: kaoutsis Owned by: axeld
Priority: critical Milestone: R1/alpha1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc: anevilyak
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

  • 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)

Attachments (2)

serial.txt (45.6 KB) - added by kaoutsis 11 years ago.
bfspartition.readonly.r24826.mmadia (631 bytes) - added by mmadia 11 years ago.
bfsinfo -s /bad_partition > this_attachment

Download all attachments as: .zip

Change History (20)

Changed 11 years ago by kaoutsis

Attachment: serial.txt added

comment:1 Changed 11 years ago by bonefish

Milestone: R1R1/alpha1
Priority: normalhigh

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. :-)

comment:2 in reply to:  1 ; Changed 11 years ago by 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. :-)

comment:3 in reply to:  2 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by kaoutsis

revision is hrev24775

comment:5 Changed 11 years ago by 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?

comment:6 in reply to:  5 ; Changed 11 years ago by 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

comment:7 in reply to:  5 Changed 11 years ago by kaoutsis

Replying to axeld:

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

next time, i will :-)

comment:8 in reply to:  6 Changed 11 years ago by 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. 

comment:9 Changed 11 years ago by 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?

comment:10 Changed 11 years ago by axeld

Priority: highcritical

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.

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by anevilyak

Cc: anevilyak added

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by 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.

comment:15 Changed 11 years ago by 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

comment:16 Changed 11 years ago by 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.

Changed 11 years ago by mmadia

bfsinfo -s /bad_partition > this_attachment

comment:17 Changed 11 years ago by 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)

comment:18 Changed 11 years ago by axeld

Resolution: fixed
Status: newclosed

Fixed in hrev24853.

Note: See TracTickets for help on using tickets.