Opened 3 months ago

Last modified 32 hours ago

#15045 new bug

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

Description

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 3 months ago.
KDL when mounting writable
photo_2019-05-02_20-10-57.jpg (161.9 KB) - added by diver 3 months ago.

Download all attachments as: .zip

Change History (17)

Changed 3 months ago by humdinger

Attachment: mount_kdl.jpg added

KDL when mounting writable

comment:1 Changed 3 months ago by diver

Component: - GeneralFile Systems/ext2

comment:2 Changed 3 months ago by diver

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

Changed 3 months ago by diver

comment:3 Changed 3 months ago by waddlesplash

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 Changed 3 months ago by waddlesplash

humdinger, is this reproducible across reboots?

comment:5 Changed 3 months ago by diver

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

comment:6 in reply to:  4 Changed 3 months ago by humdinger

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 Changed 3 months ago by humdinger

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

comment:8 Changed 3 months ago by waddlesplash

Cc: jessicah added

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

comment:9 Changed 3 months ago by jessicah

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

comment:10 Changed 3 months ago by waddlesplash

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 Changed 3 months ago by jessicah

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

comment:12 Changed 2 months ago by humdinger

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

comment:13 Changed 5 weeks ago by waddlesplash

Blocked By: 15116 added

comment:14 Changed 4 weeks ago by humdinger

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 Changed 32 hours ago by un_spacyar

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.

Note: See TracTickets for help on using tickets.