Loading SFS to RAM Without Requiring 2X RAM (Solved)

[jamesbond]

Did some test a a virtual machine with dedicated graphics memory. On real machine with shared graphics (ie = most Intel graphics), one has to discount the available memory with the amount taken by graphics card.

For Puppy Studio 3.3 - SFS size is 360MB.
Theoritical minimum RAM required for loading to RAM = 2 x (360+1) = 722MB. In my VM, it will boot when supplied with 732MB, nothing less. The extra 10MB is probably required for kernel, drivers, etc.

For Lupu 5.2 - SFS size is 123MB
Theoritical minimum RAM required for loading to RAM = 2 x (123+1) = 248MB. In my VM, it will boot when supplied with 254MB, nothing less. It only requires 6MB extra (which is odd, because I thought both use the same kernel and drivers?).

EDIT: this is when booting from the virtual CD, no extra parameters are passed on the command line.

[emil]

emil, rcrsn51, apparently, this is the expected behaviour.

I was not saying something is wrong on my machine, everything worked as it should be . But maybe we can get also the values of those variables when it fails, like in the original post:

I booted the resulting iso (174 M) with "puppy pfix=ram,copy" and it didn't load the sfs into RAM, but instead ran off of the CD, same as before. So it wasn't because of anything I did that was causing this problem, it was definitely something to do with Puppy itself.

just to get more specific why it fails ...
l0wt3ch?

[jamesbond]

Yes emil, I agree. It's good if l0wtech can use the initrd you have supplied and see the values of these parameters. We can move further from there.

[playdayz]

I do have a 512MB machine. After removing one stick.

The standard Lucid 5.2 Live-CD (127MB) copied to ram as it booted.

I then installed Google Earth and Firefox and remastered--that gave a lupu-520 sfs of 181MB. That 181MB Live-CD copied to ram when it booted.

So, In a 512MB machine both the standard Lucid-52 LiveCD copied to ram and so did the remastered 181Mb Live-CD.

Given these results I think it might be possible that there is something unique about the 170MB test disk that l0wt3ch made. It looks like Barry changed some things in that routine--but from my tests it looks like Lucid 5.2 is behaving as expected.

Puppy Studio is a great deal so I hope we can find a solution. In the case of 256MB ram, lupu-520 takes 127 and leaves 129. So in the case of 512MB ram, it seems to me that it could handle an sfs of 383 MB, leaving 129 free. But I am thinking that it would need revision to initrd.gz.

I did notice that the Remaster program could use some better error-trapping if anyone would like to take that on. Specifically, I accidentally inserted a disk that had already been written to and the Remaster program did not catch it--it wrote for a second or two and then said it succeeded.

[rcrsn51]

Thus, when you do frugal install, the behaviour is *not* to load into RAM unless you request it explicitly by adding pfix=copy.

Thanks. All my tests were done with manual frugal installs - not by using the Universal Installer. So I was not using the "pfix=copy" argument in my menu.lst entries.

This is a change in the default behaviour of Puppy that I believe appeared around Quirky 1.3 and has since migrated into Lupu.

In the past, we always said that Puppy automatically loaded into RAM if there was enough space. Now it loads into RAM if there is enough space AND you ask it to.

[playdayz]

In the past, we always said that Puppy automatically loaded into RAM if there was enough space. Now it loads into RAM if there is enough space AND you ask it to.

I *think* the way Barry sees it is that Puppy copies into ram on first boot (if it can).

The welcome1stboot.htm popup, which we removed from Lucid 5.2, says

As this is the first time that you have started Puppy, he is running totally in RAM!

[l0wt3ch]

Thanks for the responses.

The strangest thing for me was that it didn't matter how many extra files I added - whether that was five 47 MB files (235 MB), eleven files (517 MB), or nineteen (893 MB), the resulting sfs was always 170 MB. And upon examination on boot, the files were still there!

Either this is the result of the alien technology given to Barry, or something is seriously wrong.

I've uploaded the dummy file I used, as well as the resulting isos (test1 is 520, test2 is 511).

I wonder if using the initrd from 511 would solve this? Or using the specific file from 511's initrd in 520's initrd. Are they compatible?

[Jim1911]

Is it possible that the compression algorithm recognizes that your 47MB file is duplicated X times and ignores or links the duplications?

[l0wt3ch]

I don't know. Can squashfs "see through" tar.bz2 archives?

Either way, the resulting 170 MB sfs file won't load into RAM with "puppy pfix=ram, copy" with 512 MB of RAM.

[emil]

l0wt3ch,

can you do a testrun with the 170 MB sfs and the initrd.gz I supplied ? - make a backup of the original somewhere.
I mean rename initrd.gz --> initrd.gz.old and copy the new initrd.gz in the puppy 520 folder, so that it is picked up by menu.lst.

The new initrd.gzt is original 5.2, but includes debug output of the main parameters just before the conditional if to load the sfs or not. The values appear on the screen during the boot process. Be sure you put pfix=copy into you menu.lst.

of course you could also test with the 511 initrd.gz to see if this works.
In case that works it would be interesting to have a comparison of the code.
Try to unpack the initrd.gz (described in the first link I gave). Look up the section around Line 1280 described by jamesbond.

Look if the size of Memory RAMSIZE and MINRAM2CPY are correctly detected. If yes there is the variable COPYCONTENDER. It should be "yes", but maybe there is some subtle bug somewhere in the detection of available drives, which may be specific to your test machine (although this is just a wild guess and I can be completly wrong).
If necessary we have to add more lines for debugging output eventually.

just my suggestion on a strategy how to nail this down
best emil

[l0wt3ch]

That was after comments about Luci not being able to eject disk with 256mb ram. Wonder if "Studio" was based on one of those "problem" versions?

No, it's based on the latest 520.

Does standard Lucid 5.2 Live-CD copy to ram on boot in that machine with 512MB ram?

I do remember that you said Studio does copy to ram on a machine with 1GB. Is that still the case?

Yes, and yes.

So, In a 512MB machine both the standard Lucid-52 LiveCD copied to ram and so did the remastered 181Mb Live-CD.

Did you try it with the "puppy pfix=ram, copy" options? My test disc also loads into RAM when booted without those options. (I should have mentioned that earlier.)

Given these results I think it might be possible that there is something unique about the 170MB test disk that l0wt3ch made.

I only added a few archive files to make the sfs bigger, and nothing else. That was the whole point of the "experiment".

can you do a testrun with the 170 MB sfs and the initrd.gz I supplied ?

I will see what I can do.

Thanks again to everyone.

If the ratio of RAM/size of sfs is "working properly", does that mean it was broken in 511? Because Studio 3.1 was 395 MB, and still loads properly with 512 MB of RAM.

[jamesbond]

Thanks for the responses.

The strangest thing for me was that it didn't matter how many extra files I added - whether that was five 47 MB files (235 MB), eleven files (517 MB), or nineteen (893 MB), the resulting sfs was always 170 MB. And upon examination on boot, the files were still there!

Either this is the result of the alien technology given to Barry, or something is seriously wrong.

Ah, we don't need to give alien some credits for it when mere mortals like us can do it ourselves: http://tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html. The pertinent portion of that link says (emphasis is mine):

Notes for default mksquashfs behavior:
- Duplicate files will be removed, so there will be only one physical instance (By the SquashFS 2.x, you can disable the detection/removal of the duplicates with the -no-duplicates option).

If you really want to enlarge your resulting squashfs file, instead of using 1.tar.bz2 multiple times, create your 47M file like this instead:

Code: Select all

dd if=/dev/random of=your-big-file bs=1M count=47

. Do this a couple of times if you need to create multiple files.

I've uploaded the dummy file I used, as well as the resulting isos (test1 is 520, test2 is 511).

. Thanks for this, I tried to run test1.iso with 350MB of RAM, and it loaded direct to RAM - no even pfix=copy required. Hmmm....

[jamesbond]

Thus, when you do frugal install, the behaviour is *not* to load into RAM unless you request it explicitly by adding pfix=copy.

Thanks. All my tests were done with manual frugal installs - not by using the Universal Installer. So I was not using the "pfix=copy" argument in my menu.lst entries.

This is a change in the default behaviour of Puppy that I believe appeared around Quirky 1.3 and has since migrated into Lupu.

In the past, we always said that Puppy automatically loaded into RAM if there was enough space. Now it loads into RAM if there is enough space AND you ask it to.

Yes, I'm surprised also, because as far as I can remember, Puppy has always loaded into ram *unless* I ask it not to. Apparently this behaviour is now reversed for frugal install (it's still true for LiveCD) but I can't pinpoint when the change happened.

[jamesbond]

In the past, we always said that Puppy automatically loaded into RAM if there was enough space. Now it loads into RAM if there is enough space AND you ask it to.

I *think* the way Barry sees it is that Puppy copies into ram on first boot (if it can).

The welcome1stboot.htm popup, which we removed from Lucid 5.2, says

As this is the first time that you have started Puppy, he is running totally in RAM!

This is still true because when Puppy runs for the first time (or when it runs with pfix=ram), PUPMODE is 5 and therefore it will try to load into RAM.

cheers!

[jamesbond]

Is it possible that the compression algorithm recognizes that your 47MB file is duplicated X times and ignores or links the duplications?

Gotcha ! mksquashfs does this (to be honest, I don't even know this before this thread).

[l0wt3ch]

Thanks for this, I tried to run test1.iso with 350MB of RAM, and it loaded direct to RAM - no even pfix=copy required.

As I mentioned to Playdayz, above, I know that the 170 MB sfs loads into RAM without any boot options. But when "puppy pfix=ram, copy" is given, it does not!

This suggests that something is broken in regard to the "sfs-loading-to-RAM" feature of Puppy.

[jamesbond]

Thanks for this, I tried to run test1.iso with 350MB of RAM, and it loaded direct to RAM - no even pfix=copy required.

As I mentioned to Playdayz, above, I know that the 170 MB sfs loads into RAM without any boot options. But when "puppy pfix=ram, copy" is given, it does not!

This suggests that something is broken in regard to the "sfs-loading-to-RAM" feature of Puppy.

Ah sorry I didn't notice that post. Anyway - your comment above is for booting from LiveCD? It does load into RAM!

Anyway, I notice something - not sure if it's a typo in the forum here, but the correct syntax is "pfix=ram,copy" (there is no space between the comma and "copy" - in fact there is not space anywhere). In the case of booting from LiveCD, regardless of the syntax error, it will still load to RAM. For frugal install, I think it will not load into RAM until you fix the syntax error.

cheers!

[l0wt3ch]

Ya, that's a typo. See my above posts where I typed it correctly if you just think I'm stupid or something.

Thanks.

[jamesbond]

Ya, that's a typo. See my above posts where I typed it correctly if you just think I'm stupid or something.

Thanks.

Nah everybody makes mistakes Hmm then I can't explain because that test1.iso you posted, works fine with 350MB ram with or without the pfix=ram,copy parameter (booting from LiveCD) - in both cases it loads into RAM. Haven't tried frugal - because your original problem is booting from LiveCD, right?
Then really you need to use emil's initrd and see what you see what output you get when you boot that test1.iso.

[ICPUG]

I have a 512MB RAM laptop (although some is used for integrated graphics).

I use Lin'N'Win frugal so create my own menu.lst. I have NEVER used pfix=copy.

I am pretty sure my standard Lupu 5.2 is loading to RAM.

As I understand it the default is to copy the base sfs to RAM if it meets the rules in the init script.

The pfix=copy is used when you want to copy ADDITIONAL sfs files into RAM as well. That's my interpretation of what this says:
http://bkhome.org/blog/?viewDetailed=01813

I will try booting from CD and I will certainly know if it running in RAM

Can I point out that emil's post to Barry's blog deals specifically with Pupmode 6,7 where a whole partition is used for a save file. So the comments about the default there are not relevent to the more common use of Puppy with a pupsave file.

My link above is much more recent and is I think the time when Barry was messing with this.