roberts
Group: Members
Posts: 4983
Joined: Oct. 2003 |
|
Posted: Feb. 05 2006,19:41 |
|
desnotes, Very good but subtle points raised here. I keep debating if I should go back to the -cdrom option of Qemu or not.
Two issues I think are playing here: 1. Folders, don't use them for each extension. The autoload extensions should be in the root of specified partition or in this case virtual drive. The folders concept is really for booting the machine with differenet personalities, e.g., a game machine or an office machine, then the mydsl option would not only specific the partition but also the folder. mydsl=hdb/games The folder(s) would contain the collection of extensions for that personality.
2. The second issue is much more complex. By booting Qemu without the -cdrom option but instead the -kernel option we end up without the cloop module loaded at boot time. There was a small hack that allowed dynamic loading of uci type extensions by placing the insmod cloop into /opt/bootlocal.sh. However this does no good for boot time loading of uci extensions. A better hack to make both instances work is the following...
Boot up Qemu as normal. As root do the following: a.) Mount the virtual drive hdb b.) mkdir /mnt/hdb/modules c.) cp /lib/modules/2.4.x/kernel/drivers/block/cloop.o /mnt/hdb/modules d.) edit /opt/bootlocal.sh and remove the insmod cloop line e.) shutdown so backup occurs.
At the Windows level edit the dsl-windows.bat file and add another boot option within the append clause modules=hdb
Now restarting the Qemu machine, these changes will insure that the cloop module is loaded so that boot time uci extensions will properly load.
Whew! Nice find desnotes, thanks for reporting.
I suspect this complication could be avoided by using the -cdrom qemu boot option, but then we lose the easily changed and persistent boot options passed to dsl.
|