spandey wrote:Yes Linux mint 13 is using Grub2.
I didn't use grub2 myself and never tested that. But rcrsn51 uses grub2 and it shouldn't be problem.
I looked at error message and there are bunch of them, like:
1. can't stat /lib
2. aufs/kernel-modules/lib missing
3. HDIO_SET_DMA failed
4. can't find savefile /fd64save.ext4 in partitions.....
1,2,3 is all right, 4 is odd because it should be looking at /Fatdog/fd64save.ext4.
For frugal install I just copied the contents of the ISO, to /Fatdog directory. Hope that's alright ?
That is very all right, I do this all the time too
spandey wrote:Just going thru Fatdog help documents and found something interesting under boot options:
Note 1: parameters are case sensitive. Most of them are in lower case, so if you specify them in upper case (capital letters), it won't work. Also remember that all parameters cannot include space or colon.
savefile parameter has colon!!!
Nah, this means that the savefile name or path should not contain a space or a colon. The colon in the savefile parameter itself is all right.
Try this: After you have finished booting, please type this in terminal: "cat /proc/cmdline" and tell me what you see. I'm expecting you to see the correct savefile parameters (with /Fatdog path), if you see anything different then it's your grub2 configuration that has problem.
==========
smokey01 wrote:spandey you appear to have omitted the word "direct" eg:
smokey01, spandey's line is all right. He doesn't use "direct" but he uses "ram" which means he is using the RAM layer (in other puppies, this is called PUPMODE=13).
smokey01 wrote:When using the fatdog sfs loader it loads/mounts the sfs but VirtualBox or for that matter, wine, neither works. The reason being, some modules need to be loaded so a reboot or a modprobe of the modules is required.
Yes, fatdog sfs loader just mounts the sfs. It doesn't do anything extra. This is a design decision - different SFS serves different purposes and may have different activation mechanisms; and the sfs loader doesn't try to guess what they are. You will to manually do what is required - e.g. "depmod" for extra modules, or "modprobe", or start-up services, or refresh menus, etc. (openbox menus btw is automatically updated, lxpanel isn't).
I then tried shino's SFS-load-on-the-Fly and it worked fine without a reboot as it obviously loads the required modules.
Yes, because shino's sfs has the smarts.
After I had installed shino's SFS-load-on-the-Fly I notice it had clobbered the fatdog sfs loader because the desktop entries have the same name although the file names are different. It's easy enough to rename one so they can co-exist.
Yes because shino's loader was the default sfs loader for Fatdog 500, and even for early betas of 600.
My questions are:
1. Will using shino's SFS-load-on-the-Fly cause any problems with fatdog?
Yes, it probably will. Early in 600 beta we have Shino's SFS loader in the ISO, and we run into some obscure problems. Turns out that it was the interaction between shino's loader with Fatdog's layering system; we were forced to take it out.
2. Is it possible to use a pinstall.sh in the fatdog sfs loader to load the required modules?
Not at the moment, but I will consider that. Where is this pinstall.sh located? Is this supported by Shino's SFS loader too? We have to consider the effect when multiple SFS-es have pinstall.sh-es; we have to ensure that when one SFS is loaded, only its own pinstall.sh will be executed and not pinstall.sh from previously loaded SFS; thus the pinstall.sh must also be written carefully. Unlike pets, where the pinstall.sh is executed only once and then deleted (thus one pet's pinstall.sh is unlikely to affect other pets), this isn't true with SFS where its pinstall.sh will live forever.
Thanks. I usually download Vbox and install it from the official website myself, but I do appreciate this isn't always possible for others (especially live session users).
cheers!