Unable to boot HD image: bfs_access:1329: Operation not allowed

[a.mottola@…]

Trying to build my first HD image in about three years of absence from the scene, and I'm experimenting this bug while booting a fresh new image under QEMU on R5: the system starts, I see the boot logo, but then the debug output blocks at this point (I report the lines above too for clarity):

[...] vesa_get_frame_buffer_config() loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/input/ps2_hid ps2_hid: keyboard: buffer not available! bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed bfs: bfs_access:1329: Operation not allowed vm_soft_fault: va 0x0 not covered by area in address space vm_page_fault: vm_soft_fault returned error -2147478783 on fault at 0x0, ip 0x28afe4, write 1, user 1, thread 0x41 vm_page_fault: sending team "/boot/beos/apps/Terminal" 0x29 SIGSEGV, ip 0x28afe4 ("libroot.so_seg0ro" +0x5cfe4)

Nothing more happens. If I download a prebuilt HD image the same happens, whereas the same image boots just fine under VMWare on WinXP. This leads me to believe it may be a BeOS issue; I'm running an Athlon64 3000. Not sure though so I thought this was worth a bug report...

[a.mottola@…]

Forgot to say: tried both my self-built image and the downloaded pre-built one under both QEMU 0.7.2 and Bochs 2.11 under BeOS R5 with the same result.

[axeld]

Wow, welcome back Angelo :-) "bfs: bfs_access:1329: Operation not allowed" just means that someone (in this case FreeType) tried to access a file or directory in an inappropriate manner. The font scanner tries to open every file as a directory - thanks to Mac OS X and its bundle directories.

You should try the latest Qemu available for BeOS, I think it hasn't been released yet on BeBits. It's available here: ​http://www.iscomputeron.com/modules.php?name=News&file=article&sid=756

In any way, you could use "nm libroot.so | grep 005cf | sort" to find out which function led to the crash of Terminal. BTW where did you download the image, and which revision was it?

[a.mottola@…]

Hi Axel, nice to talk to you again :)

I haven't tried the latest QEmu built you mention, but I just finished installing a fresh copy of the haiku repository under my linux box, compiled it all and tested successfully the resulting image under QEmu 0.7 there; the error that happened under QEmu/Bochs on BeOS did not happen, so it is likely a BeOS QEmu/Bochs issue. Will try with the unreleased QEmu binary on ICO once I boot back under BeOS, I'll post here later about the results.

In any way, you could use "nm libroot.so | grep 005cf | sort" to find out which function led to the crash of Terminal. BTW where did you download the image, and which revision was it?

I cannot, as the system did always not finish to boot up: the QEmu window still shows the black haiku boot logo when I get those bfs_access errors. The image I did test was built by me from a fresh svn copy.

[axeld]

In any way, you could use "nm libroot.so | grep 005cf | sort" to find out

You can use this under the host operating system, you don't have to do it under Haiku. The app_server will clear the screen only when an application starts - it may do this very late.

[a.mottola@…]

Ok, confirmed my self-compiled hd image works fine under BeOS using the experimental QEmu downloaded from ICO... Looks like an emulator problem, better this than a bug in Haiku ;)