KDL from mounting an old Haiku (BFS) filesystem

[kallisti5]

see screenshot of KDL attached. Mounting second partition on a hard drive with two partitions.

gcc4, hrev43152

[mmlr]

The changes in hrev43033 and hrev43056 are to blame here. On mount the existence of "be:volume_id" is checked, which in case of it not being present at all or not being in the small data section of the root node, will cause an attribute vnode to be created. This however can't work, as the volume isn't yet fully mounted and the volume ops haven't been set yet, causing the VFS to try to access volumeOps->get_vnode on a NULL pointer resulting in the the above 0x10 read (and hence the KDL). A hacky way to get around this would be to initialize the volume ops pointer earlier in bfs_mount, i.e. before the call to Volume::Mount(). It'd probably work as the volume structures are pretty much fully set up in the VFS before calling the actual FS mount, however calling into the VFS with an incomplete mount sounds kind of unclean in any case. Opinions?

BTW: This also happens on boot when installing a new Haiku installation on an existing BFS volume.

[axeld]

I think I would just remove the on-mount functionality.

One could either provide a tool to create/change those IDs afterwards. Another option would be to make that check when the root vnode is opened from some application.

[Disreali]

Does this mean I need to re-intialize all my BFS volumes if I update to a rev more recent than hrev43033?

[axeld]

No, absolutely not. The unique volume ID is a completely optional feature.

[mmlr]

I've removed that part of the change in hrev43229, which should fix this issue.