I have just made an sfs file of VirtualBox-4.2.4 but have been having trouble getting it to work with the fatdog sfs-loader. What I have discovered, and I do apologise it this has already been repeated somewhere else, the following:

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.

This is not an ideal solution if running a live system.

I then tried shino's SFS-load-on-the-Fly and it worked fine without a reboot as it obviously loads the required modules.

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.

My questions are:

1. Will using shino's SFS-load-on-the-Fly cause any problems with fatdog?

2. Is it possible to use a pinstall.sh in the fatdog sfs loader to load the required modules?

1,2,3 is all right, 4 is odd because it should be looking at /Fatdog/fd64save.ext4.

Quote:

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:

Quote:

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).

Quote:

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.

Quote:

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:

Quote:

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.

Quote:

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.

You could put a wrapper script in the sfs called from the DOTdesktop file that checks if the modules are loaded, if not loads them then runs virtual box. Would overcome your problem I think._________________Puppy Linux Blog - contact me for access

jamesbond further investigation has revealed a reboot after loading the sfs with the fatdog loader does not fix the problem, even with a savefile.

It does. I just tested it with your Virtualbox sfs. The SFS already have the right files in /etc/init.d; that will start the vbox services which will load the modules after your reboot.

The only missing thing is that you need to "depmod" after the SFS is loaded, and this needs to be done only once.

If you want to run this from a live session, you just need to "depmod" and then start the /etc/init.d/vboxdrv services ("/etc/init.d/vboxdrv start") or use the Service Manager. Like 01micko says, you can modify the VBox desktop button to point to your wrapper script to test for conditions launching the real VirtualBox, like this one:

revealed the culprit. There are some unprintable characters before word savefile. Hence entire savefile argument has become meaningless. Looks like they came up while copying and pasting Grub2 entries in the editor. A very good lesson for future !!!!

jamesbond further investigation has revealed a reboot after loading the sfs with the fatdog loader does not fix the problem, even with a savefile.

It does. I just tested it with your Virtualbox sfs. The SFS already have the right files in /etc/init.d; that will start the vbox services which will load the modules after your reboot.

The only missing thing is that you need to "depmod" after the SFS is loaded, and this needs to be done only once.

If you want to run this from a live session, you just need to "depmod" and then start the /etc/init.d/vboxdrv services ("/etc/init.d/vboxdrv start") or use the Service Manager. Like 01micko says, you can modify the VBox desktop button to point to your wrapper script to test for conditions launching the real VirtualBox, like this one:

There are some unprintable characters before word savefile. Hence entire savefile argument has become meaningless. Looks like they came up while copying and pasting Grub2 entries in the editor. A very good lesson for future !!!!

That's probably why they recommend that you not hand-edit the Grub2 config file.

For the benefit of other Fatdog-Grub2 users, could you please post your 40-custom file along with some instructions on how you used it in Mint? Where do you put the file? What update command do you run? etc.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum