2.16 final, 512MB usb pup_save with heavy encryption,
2.16 final, 512MB usb pup_save with heavy encryption,
Seems to be a prob with universal install to USB in 2.16-final
I chose to create a 512MB encrypted (heavy) pup_save for an install to USB stick. On reboot into the system the new 512MB encrypted pup_save gets detected on the stick OK, but the freemem applet only shows 69MB as being available. I Gig USB stick is formatted to VFAT and PMOUNT reports the correct amount of unused space.
If an attempt is made to download a file larger than 69MB to the root folder with Seamonkey , the freemem applet shows its usual low memory warning whereupon Seamonkey then crashes.
On the next reboot the partially downloaded file is still there, but freemem then shows available free memory as back to 69MB.
Something seems to be going wrong when the 2 layers are merged in the shutdown script. I don't understand this area of Puppy very well. Some explanation would be appreciated here.
I chose to create a 512MB encrypted (heavy) pup_save for an install to USB stick. On reboot into the system the new 512MB encrypted pup_save gets detected on the stick OK, but the freemem applet only shows 69MB as being available. I Gig USB stick is formatted to VFAT and PMOUNT reports the correct amount of unused space.
If an attempt is made to download a file larger than 69MB to the root folder with Seamonkey , the freemem applet shows its usual low memory warning whereupon Seamonkey then crashes.
On the next reboot the partially downloaded file is still there, but freemem then shows available free memory as back to 69MB.
Something seems to be going wrong when the 2 layers are merged in the shutdown script. I don't understand this area of Puppy very well. Some explanation would be appreciated here.
Life is too short to spend it in front of a computer
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I don't think it's a bug. The script that calculates free space is /usr/sbin/calcfreespace.sh and the relevant code is:
You you be on PUPMODE 13, and it is calculating free space in RAM (pup_rw) and free space in your pup_sve file (pup_ro1) and using the smaller of the two.
In other words, you may have plenty of RAM space but your pup_save is full so there is no point putting more than that into RAM as there is insufficient space to save it..
Code: Select all
case $PUPMODE in
3|7|13) #home partition/file mntd on pup_ro1, tmpfs on pup_rw
SIZEFREE=`df -k | grep ' /initrd/pup_ro1$' | tr -s ' ' | cut -f 4 -d ' '`
SIZETMP=`df -k | grep ' /initrd/pup_rw$' | tr -s ' ' | cut -f 4 -d ' '`
[ $SIZETMP -lt $SIZEFREE ] && SIZEFREE=$SIZETMP
;;
6|12) #home partition/file mntd on pup_rw (no tmpfs)
SIZEFREE=`df -k | grep ' /initrd/pup_rw$' | tr -s ' ' | cut -f 4 -d ' '`
;;
*)
SIZEFREE=`df -k | grep ' /$' | tr -s ' ' | cut -f 4 -d ' '`
;;
esac
In other words, you may have plenty of RAM space but your pup_save is full so there is no point putting more than that into RAM as there is insufficient space to save it..
How does this apply to /tmp which is also in RAM
Barry
Since /tmp is also in RAM and it is not written back to the pup_save file, the size of the pup_save file should have no bearing on using storage in /tmp. Does it?
Regards
Ron
Since /tmp is also in RAM and it is not written back to the pup_save file, the size of the pup_save file should have no bearing on using storage in /tmp. Does it?
Regards
Ron
puppy.swp
Is here any point in having a puppy.swp swap-file on the USB stick?
How would reads/writes to the swap-file affect the operating life of the stick?. Would it speed things up to any significant extent anyway (i.e is it worth having a swap-file in PUPMODE13 at all especially when encryption is involved?)
How would reads/writes to the swap-file affect the operating life of the stick?. Would it speed things up to any significant extent anyway (i.e is it worth having a swap-file in PUPMODE13 at all especially when encryption is involved?)
Life is too short to spend it in front of a computer
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: How does this apply to /tmp which is also in RAM
True, but the script is not that clever ...someone will have to modify it to exclude /tmp ...anyone game?rrolsbe wrote:Barry
Since /tmp is also in RAM and it is not written back to the pup_save file, the size of the pup_save file should have no bearing on using storage in /tmp. Does it?
Regards
Ron
Using unencrypted swap with encryption is not a good idea if you're at all serious about securing data with encryption. You just don't know what plaintext or keys are getting swapped out
I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.
But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)
I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.
But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)
Agree, if used, encrypted swap is a must for good security.
All of the machines I boot puppy from have enough RAM that a swap file is not required; however, it would be nice if I could store the encrypted pup_save file on the puppy boot CD and use it in a read only mode, IE.. no RW media required to store the pup_save file. As a work around, I currently store the pup_save file on the CD with a diffent name then copy/rename it to R/W media, reboot to access contents and delete when finished. Also, the encrypted pup_save file contents is available as clear text while in use. I like the idea of having the option of running totally from optical boot media then simply powering the computer off at the end of the sessions, IE.. great mode for open wireless.
Regards
Ron
Regards
Ron
Seems like a lot of work to avoid having to do a shutdown. But maybe I miss the point.
I had decided to delete my swap partition so I wouldn't need to run a swapoff command in my rc.local to disable the swap, but when I did that, puppy created a pupswap.swp file for me anyway, without even asking me if I wanted it! So now I have "swapoff /initrd/mnt/dev_save/pupswap.swp" in my rc.local...
John Doe did some work with dmcrypt which would have allowed encrypted swap, but at the time Puppy's use of Busybox commands made it impossible. The offending command has now been made a full one, so a hard-core encryption fan might take another shot at it. Search the forum for his work on this.
Bottom line, if you use encryption now, you need to disable swap manually and have enough memory not to need it. A simple warning to this effect sure would be worthwhile, if nothing else.
As someone who has done his fair share of sniping at cryptoloop, I can sympathize. But hey, it's a heck of a lot better than what we had before! While I wouldn't hide stolen cruise missile plans in my pupsave, heh heh, I figure good (or bad) old cryptoloop delivers 95% or 98% of the utility of loop-aes and dmcrypt. And that's nothing to sneer at...
It wouldn't hurt for another hard-core encryption geek to join the Puppy development team. Maybe some day we could have more up-to-date encryption alternatives and features. As it is right now, though, I'm happy.
I believe the pup_save file proper remains encrypted, but of course stuff read from there into memory is cleartext while in memory (and in swap, if one is so rash as to use it). If that's so, that's about as good as it gets anywhere in the world of encryption. Correct me if I'm wrong...Also, the encrypted pup_save file contents is available as clear text while in use.
I have nagged about that, in vain I think (I haven't done anything with 2.16 so don't know for sure). Actually I lobbied to get the boot to happen with swap off by default if encryption is used.I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.
I had decided to delete my swap partition so I wouldn't need to run a swapoff command in my rc.local to disable the swap, but when I did that, puppy created a pupswap.swp file for me anyway, without even asking me if I wanted it! So now I have "swapoff /initrd/mnt/dev_save/pupswap.swp" in my rc.local...
John Doe did some work with dmcrypt which would have allowed encrypted swap, but at the time Puppy's use of Busybox commands made it impossible. The offending command has now been made a full one, so a hard-core encryption fan might take another shot at it. Search the forum for his work on this.
Bottom line, if you use encryption now, you need to disable swap manually and have enough memory not to need it. A simple warning to this effect sure would be worthwhile, if nothing else.
Well, we are only half serious around here.But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)
As someone who has done his fair share of sniping at cryptoloop, I can sympathize. But hey, it's a heck of a lot better than what we had before! While I wouldn't hide stolen cruise missile plans in my pupsave, heh heh, I figure good (or bad) old cryptoloop delivers 95% or 98% of the utility of loop-aes and dmcrypt. And that's nothing to sneer at...
It wouldn't hurt for another hard-core encryption geek to join the Puppy development team. Maybe some day we could have more up-to-date encryption alternatives and features. As it is right now, though, I'm happy.