Good evening. Well. First come The Story. :-)Some days ago I wanted to test Haiku on my work PC with SATA controllers. I have install BeOS R5 under MS Virtual PC 2007 to be able to make the Haiku builds "on the fly". After some fight with s3 video, network and ssh I was able to download actual SVN tree and build the Haiku under VPC2007.
Firstly I have installed Haiku by defining HAIKU_INSTALL_DIR during build. An attempt to boot virtual machine with this disk was successful. It start perfectly and have no visible stability or usability problems. There were no network and video support because lack of drivers - but this is not significant at this stage. Note that Haiku target disk was created separately and initialized directly by the command "mkbfs /dev/disk/ata/0/slave/0/raw /Haiku". No partitions was created on this disk.
The second "adventure" was building haiku image, converting it into MS VPC virtual disk format and booting from it. The MS virtual hard disk format was published a year ago as part of MS OSP initiative. It was required just to add 512 bytes of VHD footer to raw data image. It was not so difficult task to hack corresponding "converter". This virtual disk was successfully recognized by VPC2007 and used to boot Haiku. I have seen our boot screen, say "wow!" and after some seconds KDL say me "HI!":
_____________________________________________ PANIC: could not mount boot device! Welcome to Kernel Debugging Land... Running on CPU 0 kdebug> sc stack trace for thread 0x7 "main2" kernel stack: 0x800ea000 to 0x800ee000 frame caller <image>:function + offset 800ed970 (+ 52) 8007da94 <kernel>:invoke_debugger_command + 0x00cc800ed9a4 (+ 64) 8007e834 <kernel>:_ParseCommand__16ExpressionParserRi + 0x01cc 800ed9e4 (+ 48) 8007e23f <kernel>:EvaluateCommand__16ExpressionParserPCcRi + 0x01e3
800eda14 (+ 228) 8007f6c0 <kernel>:evaluate_debug_command + 0x008c 800edaf8 (+ 64) 8007c8a7 <kernel>:kernel_debugger_loop__Fv + 0x018f 800edb38 (+ 32) 8007d3d9 <kernel>:kernel_debugger + 0x00c9 800edb58 (+ 192) 8007d305 <kernel>:panic + 0x0029 800edc18 (+ 816) 8004df26 <kernel>:vfs_mount_boot_file_system + 0x0146 800edf48 (+ 144) 800265bd <kernel>:main2 + 0x00d1800edfd8 (+ 32) 80035047 <kernel>:_create_kernel_thread_kentry__Fv + 0x001b
iframe at 0x800edff8 (end = 0x800ee050) [*** READ/WRITE FAULT ***] kdebug> _____________________________________________ Debug output show me a bit more information about the problem: _____________________________________________ [.....] KDiskSystem::Load(): file_systems/bfs/v1 -> 2 KDiskSystem::Unload(): file_systems/bfs/v1 -> 1 device 0: /dev/disk/ata/0/master/raw media status: No error device flags: 2 offset: 0 size: 104761344 (99.908 MB) content size: 104857600 block size: 1024 child count: 0 index: -1 status: 0 flags: 3 volume: -1 disk system: file_systems/bfs/v1 name: <NULL> content name: Haiku type: <NULL> content type: Be File System params: <NULL> content params: <NULL> device 1: /dev/disk/atapi/1/master/raw media status: No media present device flags: 5 boot device: bus 0, device 0 trying to mount boot partition: /dev/disk/ata/0/master/raw [.... some extra logging from vfs.cpp truncated .....] dec_vnode_ref_count: vnode 0x90847b80, ref now 2 vnode_path_to_vnode: top of loop. p = 0x90856005, p = ''file_open: fd: -1, entry path = '/dev/disk/ata/0/master/raw', omode 1048578, kernel 1
path_to_vnode(path = "/dev/disk/ata/0/master/raw") [.... some extra logging from vfs.cpp truncated .....] bfs: Mount:347: Invalid Argument file_close(descriptor = 0x90859a40) release_advisory_lock(vnode = 0x90859900, flock = 0x00000000) dec_vnode_ref_count: vnode 0x90859900, ref now 1 bfs: bfs_mount:127: Invalid Argument PANIC: could not mount boot device! [.....] _____________________________________________I tried to figure this problem out by yourself, activated TRACE-ing in vfs.cpp and vfs_boot.cpp. But this doesn't help me much. Which module generate this "bfs: Mount:347: Invalid Argument"? May be you have any idea about this mounting problem? Of course, I can provide complete system log if it is required.
And some additional questions:1) May this possibility to make VPC-ready Haiku images be useful for us? In other words - should I invest a bit more time to bring my "vhdconverter" to production quality? :-) Currently it can produce fixed-size virtual drives. But mentioned VHD specification allows to produce sparse files that can decrease resulting size of the disk image and use images with any reasonable size. 2) Is information obtained from document under "*Microsoft Open* Specification *Promise* <http://www.microsoft.com/interop/osp/default.mspx>" license safe to be used during development for Haiku? In my case that was just reading VHD file specification.
Thank you! Kind Regards, S.Zharski