Fatdog64-610 testing 20 Nov 2012 (finished)

A home for all kinds of Puppy related projects
Message
Author
User avatar
RIZARDOUZ7
Posts: 44
Joined: Wed 27 Jul 2011, 12:38
Location: Philippines
Contact:

Re: skype

#21 Post by RIZARDOUZ7 »

smokey01 wrote:
RIZARDOUZ7 wrote:Here is the link http://distro.ibiblio.org/fatdog/sfs/50 ... 2.0.35.sfs

I even tried getting skype 4.0 sfs from the lighthouse 64 site. Unfortunately, both of the sfs didn't worked. I moved the sfs files to mnt/home and get an error whenever trying to load the sfs files from the the launcher. It was like an error in mounting.
Here is skype-4.0.0.8
http://www.smokey01.com/software/Fatdog ... 8-fd64.pet

The main credit goes to meeki as he built version 4.0.0.7 for LightHousePup.
http://www.smokey01.com/software/Fatdog ... .0.0.7.pet

Both work fine on FD64 600 601 610
Thank you very much, it worked! Speakers, mic and webcam worked :).

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#22 Post by spandey »

I have frugal install of Fatdog in /Fatdog directory of sad5 partition. I have the savefile in / of same partition. If I move the savefile to /Fatdog and change the boot parameters, it boots without savefile.

I don't want it in root '/' as I would like to test beta as well.

I have the following parm

Code: Select all

savefile=ram:device:sda5:/Fatdog/fd64save.ext4

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#23 Post by jamesbond »

spandey wrote:I have frugal install of Fatdog in /Fatdog directory of sad5 partition. I have the savefile in / of same partition. If I move the savefile to /Fatdog and change the boot parameters, it boots without savefile.

I don't want it in root '/' as I would like to test beta as well.

I have the following parm

Code: Select all

savefile=ram:device:sda5:/Fatdog/fd64save.ext4
That's the right parameter. Add "showerr" and "pfix=nox" to see the error with savefile loading process. Also, what's sda5's partition type? Is it ntfs?

cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#24 Post by spandey »

sda5 partition is ext3 type.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#25 Post by rcrsn51 »

spandey wrote:I have the following parm

Code: Select all

savefile=ram:device:sda5:/Fatdog/fd64save.ext4
What kind of device is sda - regular hard drive or a USB drive?

Didn't we have a similar discussion here?

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#26 Post by spandey »

Didn't we have a similar discussion here?
Yes we had and it worked for USB Pendrive.

I had given Hardrive for RMA and got it back now. As long as the savefile is in root directory it works fine.

@jamesbond,
I tried showerr and Fatdog is searching for /fd64save file in all the partitions. May be someone can recreate and check?

I am booting Fatdog from Grub2 if that matters.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#27 Post by rcrsn51 »

spandey wrote:May be someone can recreate and check?
It works OK for me.
I am booting Fatdog from Grub2 if that matters.
It sounds like some other OS on your hard drive is running Grub2. Did you run the Grub update procedure after changing the Fatdog entry?

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#28 Post by spandey »

Yes Linux mint 13 is using Grub2. I did update grub changes. 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.....

For frugal install I just copied the contents of the ISO, to /Fatdog directory. Hope that's alright ?

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#29 Post by spandey »

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!!!

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#30 Post by smokey01 »

spandey you appear to have omitted the word "direct" eg:

Mine looks like this:

Code: Select all

kernel /fd610/vmlinuz savefile=direct:device:sda3:/fd610/fd64save.ext4
Yours should probably look like this:

Code: Select all

kernel /fatdog/vmlinuz savefile=direct:device:sda5:/fatdog/fd64save.ext4

gcmartin

Download Failure

#31 Post by gcmartin »

Delete or ignore this message. Seems that its working now for some reason.
Attachments
DownloadFailure.png
Download Failure
(55.67 KiB) Downloaded 2519 times

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#32 Post by smokey01 »

kirk & jamesbond,

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?

I will place the VirtualBox-4.2.4-fd64_600.sfs here:
http://www.smokey01.com/software/Fatdog64-600/

Regards

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#33 Post by jamesbond »

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.
I will place the VirtualBox-4.2.4-fd64_600.sfs here:
http://www.smokey01.com/software/Fatdog64-600/
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!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#34 Post by smokey01 »

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

A modprobe of each of the 4 modules is required such as:

modprob vboxdrv
modprob vboxnetadp
modprob vboxnetflt
modprob vboxpci

Providing you have a savefile it will work on subsequent boots.

It still doesn't fix the live boot option.

A simple script would fix the problem but how would people know to run it. Maybe your fatdog sfs loader could look for the script, if found, run it.

Nothing is ever easy :cry:

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#35 Post by 01micko »

smokey01

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

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#36 Post by smokey01 »

01micko wrote:smokey01

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.
Yeah that might work providing VB is called from the menu entry.

I was thinking of putting a script in the sfs somewhere than could be run if required but it's not very intuitive.

I like your idea better.

Thanks

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#37 Post by rcrsn51 »

jamesbond wrote: But rcrsn51 uses grub2 and it shouldn't be problem.
No I don't. I was testing spandey's savefile argument in regular GRUB.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#38 Post by jamesbond »

smokey01 wrote: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:

Code: Select all

#!/bin/sh
! modinfo vboxdrv && depmod
! lsmod | grep -q vboxdrv && /etc/rc.d/rc.vboxdrv start
VirtualBox
should do the trick.

rcrsn51 wrote:No I don't. I was testing spandey's savefile argument in regular GRUB.
Oops I thought you did test it with grub2. Sorry :oops:

EDIT: add script.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

spandey
Posts: 114
Joined: Thu 20 Sep 2012, 14:30
Location: India

#39 Post by spandey »

Jamesbond,
Thank you so much. The

Code: Select all

cat /proc/cmdline
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 !!!!

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#40 Post by smokey01 »

jamesbond wrote:
smokey01 wrote: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:

Code: Select all

#!/bin/sh
! modinfo vboxdrv && depmod
! lsmod | grep -q vboxdrv && /etc/rc.d/rc.vboxdrv start
VirtualBox
should do the trick.
Your fix is a lot more elegant than mine. I took Mick's advice and made a wrapper which checks to see if each module had been loaded, if not it loads them. The script also starts with a depmod.

Anyway I am uploading the sfs again as it now works fine while operating live. I probably could have trimmed it down a bit but didn't bother. Maybe next time.
http://www.smokey01.com/software/Fatdog ... 64_610.sfs

Post Reply