(old)Puppy Linux Discussion Forum

I've updated pup_save encryption for 2.14. Finaly got a computer that boots from usb flash. So encryption works there too. Posted on the other forum:

http://www.puppyos.net/forum/?1172086471

Great work Kirk....check with WhoDo so he can *hopefully* incorporate this into the Puppy 2.15 CE "Viz" edition. I've always been of the opinion that this should be a standard feature or option in the base release.

Thanks Jam,

I think It should probably be in the base distro too. It's quite small and offers security for usb flash and for multiple users on the same computer.

I've tried puppy linux at the encouragement of my brother previously but I couldn't get wifi to work. The last time, it was better but I had just gone up to WPA from WEP and that wasn't there. So I hadn't used it to speak of.
I downloaded 2.14, burned an iso to a CD-RW and started up again. I had a little trouble with the WPA, it wasn't clear to me what numbers I really should be using for password and whatnot, that's not a fault of they puppy system but a lot of stuff you get with SBC Yahoo is "idiot proofed" and you don't really need to know much. But I looked it up.
When you're trying to get the WPA window up it's a little non-intuitive. You have to poke around a bit to get the right sequence of things. I lucked out the first time (beginners luck). It was working fine and that proved it COULD be done. That was helpful because I messed up and thought I could get the CD-RW to load the "change file" when I powered down but that's a no-no I found out.
Anyhow, I had to start over when I powered up and that time I had a bit more trouble with the auto help wizard thing. Having had it work once though kept me going 'cause I knew it could be done!
Turns out you really really need to use the scan thing. But it's a little tricky to select WPA then scan just right before it'll even see a WPA wifi node. Once it does, then just enter the key and you're there.
I'm using an ACER laptop with 802.11g. It's a Travelmate with a Pentium M and CD burner/DVD reader combo.

Just a little appreciation note for all the great work you have submitted to Puppy as regards encryption Kirk.

This puts Puppy even further ahead of all the other Linux distros if it wasn't already.

Best from Tronkel

Thanks Tronkel,

I didn't do that much. But it's nice to get a pat on the back.

Jam wrote:

Great work Kirk....check with WhoDo so he can *hopefully* incorporate this into the Puppy 2.15 CE "Viz" edition. I've always been of the opinion that this should be a standard feature or option in the base release.

I second that.

Me2

kirk wrote:I think It should probably be in the base distro too. It's quite small and offers security for usb flash and for multiple users on the same computer.

Ok, I've got most of the bugs sorted in Beta1 and I'm ready to try something new for Puppy 2.15CE Beta2. Save file encryption is an obvious feature choice and I'd like to include it. Can you let me know what I need to do to the next unleashed build of the 2.15 initrd.gz file to have encryption installed? Thanks, kirk.

I've uploaded my save-file-wizard also WhoDo. Just so you know. When you get encryption sorted, let me know if it has any errors and I'll take a gander.
http://www.murga-linux.com/puppy/viewtopic.php?t=16249

But for now I'd better go test my homework before I leave for the weekend (I wrote and tested it in Puppy with g++, but it will be graded with Visual Studio, so I have to make sure that works too).


As for adding encryption, the basic run-down is edit /sbin/init with a couple lines, and add the aes and cryptoloop modules, which these guys can explain. Also nice is the option to encrypt the file when you first create it. I'll be working on that next week as I port Pizzapup to 2.14. I'd just give you the scripts I used with 2.12, but Puppy's shutdown has changed since then (for the better).

Ok, I've got most of the bugs sorted in Beta1 and I'm ready to try something new for Puppy 2.15CE Beta2. Save file encryption is an obvious feature choice and I'd like to include it. Can you let me know what I need to do to the next unleashed build of the 2.15 initrd.gz file to have encryption installed?

I've posted the details here:

http://www.puppyos.net/forum/?1172086471

That's for a modified 2.14 initrd.gz. I've noticed that fsck is now taking up more than half of my boot time. Fsck takes me about 30sec with 512MB save file that has 93MB free in it. Right now the encryption mod is using ext2 like the rest of puppy. I'm thinking we should go back to ext3, or at least make it an option. I never had a problem with ext3 on the loopback device.

I posted the fsck time problem on the other forum, Barry has changed init script to fsck only if it's ext2. Barry seems to always be working on the init script. Might want to see if we can use his current working version.

If you need more info or you've got another init script and you want me to apply these changes to it, let me know.

I'd like to here others thoughts about ext2/3.

hello kirk

I’m having difficulty using your app to encrypt my pup_save file. I follow the directions and all seems to go well and the new pup_save_crypt file is created. On reboot I have the option to select the new pup_save_crypt.2fs file but then I get the following error:

Mounting /pup_save_crypt.2fs on /pup_rw…
Dumping last lines of /tmp/bootinit.log…
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck –b 8193 <device>

mount: Mounting /dev/loop1 on /pup_rw failed: Invalid argument
Dumping last lines of kernel log…
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: RRIP_1991A
VFS: Can’t find an ext2 filesystem on dev loop1
Pausing for 60 seconds

I’m booting off a live CD v2.14 and have both pup_save.2fs and pup_save_crypt.2fs on hda3 (vfat). I tried using both the ext2 & ext3 filesystem with similar outcome.

Also I can't get it to work while booting off a 1gig USB drive with the pup_save_crypt.2fs on the USB drive.

What am I doing wrong?

You've gotta edit initrd.gz. That means using isomaster to edit the iso before burning it to a cd, or else replacing the initrd.gz file on the usb-drive. I think the instructions said about it.

Gotta go sleep now. Sorry for no details, but already past bed-time.

Yes, make sure you've replaced you initrd.gz.

Thank You Pizzasgood and kirk, that was it. Guess I missed that!

Fsck takes me about 30sec with 512MB save file that has 93MB free in it.

Ah, so that is what is taking the time. It wasn't like that before the ext2 change. I hadn't noticed more than a couple seconds extra to fsck a non-encrypted pupsave. Must be the combination of encryption with fsck that's taking the time?

Barry had earlier experimented with the tune parameter that sets how frequently the file is fsck'ed. I talked him into just doing it every time. Well, that was a good choice with unencrypted pupsaves! Perhaps he can use the tune parameter only on encrypted pupsaves, to fsck only every 10 or 20 boots.

I don't think going back to ext3 is the right general answer; there were good reasons for getting away from it. However I believe users who want it can still go that route, right? The support is still there I think. Anyway I gave the option for an ext3 pupsave in the convert-pupsave script, and it seems to work. Convert-pupsave is available here:
http://www.puppyos.net/forum/?1170535852

That 30sec is with a non-encrypted pup_save file. Just a lot of little files in there. Ext3 worked very well for me. I'd crash quite a lot between video games and my battery going dead. Never lost any thing with ext3.

I never had any trouble with ext3 either.

From memory I believe the basis of the problem which was presented was that if one had a journaled file system mounted as a loopback device on a non-journaled file system which happen to be in the process of being defragmented (or rearranged in some way) while one were accessing the loopback device something bad MIGHT happen to the loopback file system.

The only time I could even imagine this could happen is with a network puppy boot where the save file is on a windows share that was fat and it was being defragged.

Or maybe I misunderstood the problem, I didn't go back and read the thing again.

Perhaps, if a user chooses to create a pup_save file in a ext3 or reiserfs hard drive partition, then Puppy could automatically make it a ext3 f.s. in the pup_save file. In all other conditions it will be ext2.
It would be easy enough to add this logic to the shutdown script -- and I would rather not offer the choice, want to keep everything as simple and automatic as possible.

i don't suppose it matters much ... a fsck repair of an ext3 drive is usually much faster than on an ext2 drive, and it is usually more likely to be able to fix the file system properly

i am using a pup_save.3fs file, because i upgraded it from Puppy 213 (or 212?)

i have never had any problems with ext3 either

i know that it has been said that there can be problems with journaled file systems mounted on loop devices ... personally, i have never noticed any problems with ext3 pup_save files, but that doesn't mean that there can't be problems

anyway, i don't think Puppy needs to force a full file system repair on every boot ... when the file system is created (ext2 or ext3) it was automatically configured to do a full file system check every 28 mounts or so, by default ... otherwise, fsck should just check if it was unmounted cleanly, and if it was unmounted cleanly, it won't bother to do a full file system check

so something like this should take less than a second or 2:

e2fsck -y -p pup_save.2fs

because it's not forcing a full file system check on every boot, on a file system that was unmounted cleanly

oh, by the way, i don't have any ntfs partitions, but for some people who do, the home partition might not be unmounting properly when Puppy shuts down ... i think it needs a fusermount -u command at the end of rc.shutdown, with the option to remount read-only, if necessary (i don't remember the read-only option ... -z?) ... because umount works on vfat but not on ntfs partitions