Opened 6 months ago

Closed 8 weeks ago

#15045 closed bug (fixed)

KDL "ExtentStream::FindBlock() invalid header" when mounting

Reported by: humdinger Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: File Systems/ext2 Version: R1/Development
Keywords: Cc: jessicah
Blocked By: #15116 Blocking:
Has a Patch: no Platform: All


This is hrev53099, 32bit.

I recently updated from a fairly recent hrev (can't be sure, not older than hrev53060 I think) to hrev53099 (32bit).

I now get a KDL "ExtentStream::FindBlock() invalid header" (see attachment) when trying to mount a specific partition writable and a "Bad data" alert when mounting read-only. For the latter, the syslog says:

KERN: ahci: sg_memcpy phyAddr 0x191f8890, size 8
KERN: ext2: get_vnode: InitCheck() failed. Error: Bad data
KERN: ext2: could not create root node: get_vnode() failed!
KERN: ext2: Failed mounting the volume. Error: Bad data

Which is strange, because it's not ext2, but a BFS partition. Booting a 64bit Haiku Beta1 image I have laying around, I can mount the partition, no problem. A "checkfs" when booted in the Beta1 doesn't find anything wrong.

Attachments (2)

mount_kdl.jpg (372.9 KB ) - added by humdinger 6 months ago.
KDL when mounting writable
photo_2019-05-02_20-10-57.jpg (161.9 KB ) - added by diver 6 months ago.

Download all attachments as: .zip

Change History (19)

by humdinger, 6 months ago

Attachment: mount_kdl.jpg added

KDL when mounting writable

comment:1 by diver, 6 months ago

Component: - GeneralFile Systems/ext2

comment:2 by diver, 6 months ago

Interestingly, some other user on Telegram reported that reiserfs caused KDL for him. However, he didn't have any reiser partitions at all.

by diver, 6 months ago

comment:3 by waddlesplash, 6 months ago

Diver, that's an unrelated KDL, and I believe it's a duplicate of a different ticket on here; it appears to be caused by CD media changes conflicting with the IO scheduler and partition rescans.

comment:4 by waddlesplash, 6 months ago

humdinger, is this reproducible across reboots?

comment:5 by diver, 6 months ago

I don't recall any ticket like this. Do you have a link?

in reply to:  4 comment:6 by humdinger, 6 months ago

Replying to waddlesplash:

humdinger, is this reproducible across reboots?

Yes, 100%.
Any hint where to start my binary hunt for the breaking hrev?

comment:7 by humdinger, 6 months ago

I've pin-pointed the offending commit: it's hrev53082

comment:8 by waddlesplash, 6 months ago

Cc: jessicah added

Probably that just exposed an old bug in the ext2 filesystem, but cc jessicah anyway.

comment:9 by jessicah, 6 months ago

Ugh, alright, I'll look into reverting and finding a better way to fix this.

comment:10 by waddlesplash, 6 months ago

What? No, don't revert it. This just exposed some bug in ext2. If the disk was misidentified by ext2 and it was a non BFS disk we'd have this same problem. We need to just fix ext2.

comment:11 by jessicah, 6 months ago

Axel wanted it fixed in a better/more intelligent way anyway, which I can understand.

comment:12 by humdinger, 5 months ago

@jessicah, any news? I wouldn't hate accessing my two mis-indentified partitions again... :)

comment:13 by waddlesplash, 4 months ago

Blocked By: 15116 added

comment:14 by humdinger, 4 months ago

FYI, as I needed the disk space, I had to delete/reformat the affected partitions and won't be able to test possible future attempts to fix the issue.

comment:15 by un_spacyar, 3 months ago

I get the same issue after upgrading from Beta to Nightly (x86_gcc2). When booting from a USB stick, my Haiku partition get recognized as EXT2 by DriveSetup, after the update.

Thanks to @waddlesplash help, I managed to boot it again by blacklisting the EXT2 driver.

Just ask me if you need to test some fix.

comment:16 by waddlesplash, 2 months ago

hrev53401 may fix this.

comment:17 by waddlesplash, 8 weeks ago

Resolution: fixed
Status: newclosed

Actually fixed in hrev53429.

Note: See TracTickets for help on using tickets.