The problem with loading UCI's if they are on CDROM2 still exists in RC2 - see my post on this for RC1 at:
http://damnsmalllinux.org/cgi-bin....2;st=20andrewb, If your issue can be described and reproduced without a virtual machine then I will take a look. It is not the goal for DSL to interface seamlessly with virtual machines. I think that we state in the readme that this DSL + virtual machine is experimental. There are too many virtual machines to support. I see there is even another now, Parallels? Also I do not have access to Windows machines powerful or capable enought to achieve such environment. as you describe.
Given that, I would think that you should setup your environment to have another virtual hard drive and not an additional virtual cdrom. Would not that be easier? Then use mydsl=hdX something?I'm also using DSL 2.1RC2 with the the final release of VMplayer. This may or may not help ... but the way I run it is: * get the player to boot the DSL iso image * download my fav UCI & mydsl packages (from the DSL running in the vmplayer) * select supend in the VMplayer preference panel
Using this method I restore (& suspend) the DSL Vm and continue working exactly where I left off. There's no moving downloads from /tmp or boot parameters etc. Once everthing is exactly as I like it - I can duplicate my tweaks by ssh(ing) all the settings etc. to my laptop.
Cheers rob PS With the above VM config I also have a 500mg virtual partition with a 128 meg swap drive. I could install DSL to this VM partition but don't need to when using the suspend method.
Just to mention conky. Conky is a fork of torsmo which should work even better from what I've heard. Did you try it?
Conky FAQ Looks nice, though technically 2.x isn't really based on Torsmo anymore.As I said in my previous posting I can't decipher what the script in etc/init.d/mountci is doing entirely, but it looks as though in line 11 of the script that if the pathname contains cdrom2 then the SOURCE pathname is changed to point to mnt/auto/cdrom/optional rather than using the pathname passed to the script?
You can test this by placing a uci file in a directory which has the text 'cdrom2' somewhere in the path (can be on it's own, or as part of a longer directory name, e.g. /home/dsl/cdrom/openoffice.uci or /whydoesntcdrom2work/openoffice.uci, or even part of the uci filename - e.g. opencdrom2office.uci). then try to load the uci file.
What is so special about having 'cdrom2' in the path or was it a left-over from some testing?
edit:
This 'bug' was introduced with V2.0. V1.5 loads UCI's OK under the above conditions.Next Page...
original here.
) ...... 