(old)Puppy Linux Discussion Forum

mavrothal wrote:

01micko wrote:I also hacked 3builddistro to support the a drive concept, it does nothing more than produce a sane DISTRO_SPECS. An iso with A drive needs to be made manually afterwards.

That's a good start but spitting at build time is even better

For sure.. or even renaming a custom sfs to the adrive, more flexible, less prone to error. (Maybe more chance of acceptance upstream ). Baby steps.

mavrothal wrote:

Q5sys wrote: Actually LHP64 can load all SFS into ram. You have the option to run them from disk or load to ram.

Never used LH64 so I do not know for a fact.
I just glanced at the code and although I can see COPYEXTRASFS2RAM I can not see how more that one SFS is loaded as UMNTRO.
I probably miss something, but can you actually see RAM usage increasing as much as the SFS size when more than 1 extra SFSs are loaded with the copy2am option? (I know you have the RAM for that test )

I'll be rebooting my machine again in a few days to add some drives... I'll do a few startup schemes and get you some hard results. From memory... yes I have seen memory usage, but memory isn't always the most accurate thing. Give me some time and I'll get you the info.

I knew I had seen this.

This is NOT Jeminah's model. It is one that is in place with LH64. ((I believe it may have been missed/overlooked as it is aimed for his 64bit platforms) See this pictorial for easy understanding.

It is NOT intended to shift current discussion, rather, to present one working concept.

Hope this helps and provides clarity.

gcmartin wrote:It is NOT intended to shift current discussion, rather, to present one working concept.

That's a good point - plus: a little guide or help for the less experienced of us - like me!

Ok.

Back to just a adrv, but still something is getting wrong. The sfs goes to the adrv, I can see the files and use the applications or whatever is in the sfs. I have loaded up to 39 sfs files using sfs_load 1.9.6 (shinobar) - also can unload.

But: after unloading an sfs I can't mount sfs files or iso files by the usual left-click action.

The same on my second edition, adrv & ddrv, which I do attach here, hoping someone will have a look and find my "bugs"?

Seems it's not clear to me , how to handle the tmpfs dirs and the loopX...

Thanks

R-S-H wrote: Back to just a adrv, but still something is getting wrong. The sfs goes to the adrv, I can see the files and use the applications or whatever is in the sfs. I have loaded up to 39 sfs files using sfs_load 1.9.6 (shinobar) - also can unload.

But: after unloading an sfs I can't mount sfs files or iso files by the usual left-click action.

The same on my second edition, adrv & ddrv, which I do attach here,

I really have a hard time understanding.
After you mount 39 sfs with sfs_load if you unmount (with sfs_load?) *anyone* of those 39 (not the adrv) then you can not mount sfs with sfs_load or you can not mount them with your "left-click"? But before you unload an SFS the left-click works?
What the left-click calls in your case? filemnt? other?
What the command "filemnt /path/name.sfs" reports?

BTW SFS-load also needs to be patched so will not unmount a/b/cdrv.

Hi mavrothal.

If I'm talking about mounting an sfs, I do mean the single left-click-action, loading an sfs means to me: using sfs_load.

Sorry, but I try my best...

Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.

I will try the patch of sfs_load, but could you please have a look into my init script for the z,a,d(drv) and how I did arrange them (increasing its numbers etc. - btw: all needed dirs are in initrd.gz, I can see and use everything, even though I can not mount the iso, sfs with right-click, I can load more sfs files using sfs_load).

Thanks

R-S-H wrote: Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.

So what is the "filemnt /path_to_sfs/name.sfs" output when typed in the terminal (after you have unloaded an sfs and left-click fails). ie what is the error? and why do you think that is realated to init? Is this the ONLY change between a working and an non-working version?

mavrothal wrote:

R-S-H wrote: Yes, the left-click works until I do unload an sfs (sfs_load) and, yes, it calls filemnt.

So what is the "filemnt /path_to_sfs/name.sfs" output when typed in the terminal (after you have unloaded an sfs and left-click fails). ie what is the error? and why do you think that is realated to init? Is this the ONLY change between a working and an non-working version?

I'm currently using the no-adrv-initrd.gz, so I need to reboot to get the error message from terminal. Will post this later.

Yes, this is the only change, but I'm not sure yet, because of the not yet patched version of sfs_plus...

I will first do these patches, and after this, doing everything again, watching for the resuts...

R-S-H wrote: Yes, this is the only change, but I'm not sure yet, because of the not yet patched version of sfs_plus...

Would be easier then if you post a "diff -ur" between the adrv and the non-adrv initramfs folders.

Also the SFS_load patch is *only* for ydrv.
The latest sfs_load already has a provision for adrv and if you use b/c/d/e-drv must modify the ydrv patch accordingly.

Would be easier then if you post a "diff -ur" between the adrv and the non-adrv initramfs folders.

Ok. Here it is!

Oh!!!

I have discovered right now, even though I'm using sfs_load 1.9.6, the adrv is not taken under sfs_load's provision for the adrv. This is because of sfs_load uses DISTRO_ADRVSFS, which I don't. I send the sfs for the use with the adrv from boot menu and LazY Puppy DISTRO_SPECS does not have the DISTRO_ADRVSFS.

Could this be a clue/reason for this weird behavior? I do believe so...

mavrothal

here is a 3builddistro patch that works, manually adding adrive, so any custom adrive can be added, tested working.

it's against commit faca226129. (20130310)

01micko wrote:mavrothal

here is a 3builddistro patch that works, manually adding adrive, so any custom adrive can be added, tested working.

it's against commit faca226129. (20130310)

Looks good. Time to start lobbying

R-S-H wrote:Could this be a clue/reason for this weird behavior? I do believe so...

There is only one way to find out...
This and running that filemnt command (preferably with a "set -x" in filemnt if problem persists)

Now that we have adrv, ddrv and zdrv, could you also add c:drv please (to contain all my Windows files). I noticed ever since I first tried puppy that the c:drv has been missing...

That is not your Windows files. It is an OS's files licensed to you.

greengeek wrote:Now that we have adrv, ddrv and zdrv, could you also add c:drv please (to contain all my Windows files). I noticed ever since I first tried puppy that the c:drv has been missing...

Regarding c:drv, let me recycleanother post

It can run from NTFS partitions.
Actually I find this a flaw! (also for puppy)
NTFS. So primarily you are a windows user, used to be asked 5 times if you "really, truly, positively want to open this application".
And now you are granted root access in a system that you do not know very well and you are one typo/click away from messing your Windows partition (and then spend a day try to recover your "graduation pictures" ).
Besides NTFS already implies that it is a hobby/test OS and is not really used

Hi mavrothal.

filemnt message is: could not find free loop device.

Do I have to increase them as well in initrd.gz or how could this be done?

My initrd.gz has loop0 to loop10. The sfs_load creates automatically new ones if more sfs files are loaded.

So, let's say sfs_load has created new loops up to 16 then the iso could not be mounted if all loops are used. Unloading an sfs and mounting a iso works.
After unmounting the iso and loading new sfs mounting a iso fails again and son on. --> sometimes sfs_load stops to create new loop device after mounting an iso has failed several times.

That's really weird for a beginner like me...

To set option -x (set -x) in filemnt would have which effect?

Thanks

RSH

R-S-H wrote: To set option -x (set -x) in filemnt would have which effect?

Not that I know off. But is the filemnt behavior changes in you setting depending on "set -x"?

If you have problem with number or the generation of loop devices in /dev you may just want to make them manually once and have them there
Just type "mknod -m664 /dev/loop<number> b 7 <number>", where number is 11, 12,... etc (you can do it with a script too).

This will not address the root of the problem but it may cover it (up to the number of loop devices you will make).

The problem with this kind of "debugging" is that you have introduce several changes in your code-base so is hard for anybody else to reproduce or even see what is going on.
If you are going to keep developing/changing things you may want to seriously consider a versioning system (git, svn, hg etc). If it is pubic is even better

Thanks for your long support here, mavrothal.

I have used a script to create the loop devices: All loop devices are successfully created. But I'm not sure how to do this or better saying when/where.

Should I create the loop devices from within the init scipt (at boot up) or editing the initr.gz to create the loop devices. Path then would be: I assume different path makes no difference?

Thanks

RSH

P.S. Tests to create the loop devices has been made using a LazY Puppy version with no adrv options added (currently running it) - so, I couldn't test anything else yet.