Thank you, Sfs!
Just did quick test and I like your additions. Not everything downloaded with sfs-get will work on DebianDog but I guess I can change the repository to different one with more compatible modules or create special modules for DebianDog.

This gives me very good base to start working on one more boot method for DebianDog - named PuppyRus-Arch-boot maybe? I have much to explore and understand first.

Fred, (just information for later) the porteus initrd from Sfs's iso can use systemd boot and seems to me this is the fastest boot I ever used. It also does not have modules included inside and we can change the kernels with the same initrd.xz file.

I can boot also with extracted from puppy-initrd-boot kernel-modules.sfs (renamed to 000-kernel.pfs) and vmlinuz using your porteus-puppy-rus-a_initrd.
The archive is linked here
Maybe your work will make possible to adapt puppy initrd to use systemd as optional boot. I doubt there is much interest for the moment from systemd here but I will post this information in the forum after some more testing.

I'm not planning to work to adapt puppy initrd to use systemd, but I think it will be possible to boot puppy main module with systemd with initrd.xz from Sfs.
I doubt anyone will try to adapt systemd in puppy reading this thread.

Quote:

Also puppy initrd crypto for DD??

I think if you create encrypted save file from puppy you can use it with puppy-initrd-boot and DebianDog. The problem is Puppy uses cryptoloop and DebianDog cryptsetup. I'm sure it can be fixed inside initrd or maybe we can create encrypted save somehow with cryptsetup that can be opened with criptoloop. But this is not something i see as priority for me at the moment.
BTW DebianDog default kernel has cryptoloop module that can be activated with modprobe cryptoloop. It can be downloaded here also but works only with 3.2 kernel series:
http://www.smokey01.com/saintless/Fredx181/cryptoloop-wheezy-kernel-3.2.tar.gz_________________Farewell, Nooby, you will be missed...

Hi, Sfs.
I have problem to use encrypted save file with porteus-puppy-rus-a_initrd including the last one Maybe this is because I use DebianDog main module but I get error about "/opt/000-kernel/sbin/cryptsetup not found" on boot.
Rebuilded again your initrd.xz with the changes from Fred's initrd1.xz builded for DebianDog:
http://www.smokey01.com/saintless/DebianDog/System-modules/initrd-pra-crypt.xz
With this initrd.xz I get password prompt and the encrypted save file is checked for errors and loaded.
The changes inside initrd.xz:
1. In linuxrc changed lines 235 and 345:
/opt/000-kernel/sbin/cryptsetup changed to /bin/cryptsetup
2. Added /bin/cryptsetup and /lib/cryptsetup/askpass

I don't know if this information is usefull for you but it works for me this way.

I use this 3,13.5-pf kernel that does not have sbin link to /usr/bin/cryptsetup like 3.14.4
3.13.5-pf is the only kernel from your link that starts Xorg without troubles on my very old hardware. I will use my laptop for further testing encrypted save with newer kernel.

saintless, a couple of suggestions to improve the quoted post http://murga-linux.com/puppy/viewtopic.php?p=774457#774457 below:

saintless wrote:

DebianDog Wheezy live-boot-3x:

To save changes you need to create save file named persistence or ext partition with label persistence + adding persistence.con file inside this save file or save partition (both save file and partition can be encrypted).

...

...

...

Thanks to dzz from Refracta forum and his initrd patch we can use encrypted save file or partition even on the same partition where /live folder is located (boot partition)

...

...

Also you need to create persistence.conf file with this content for full peristence:

Code:

/ union

...

... ... ...

Fix the typo: persistence.con -> persistence.conf

Mention explicitly that what triggers dzzz's patch is boot code rw-basemount, which replaces a standard boot script with a patched one from /opt/... This information is of interest to people who need to debug the live boot process (boot code debug=1).

Most importantly, file persistence.conf needs to end with a newline. If it doesn't persistence won't work. So the example you give above should be rewritten as:

Code:

/ union

I spent countless hours debugging live boot to find out why persistence file and partition didn't persist, just to eventually figure out that appending a new line to the file fixed the problem for good.

To use RemasterCow with live-boot3x type in terminal one of the options depending what kind of persistence or no persistence you use (all work well with official initrd.img). With the patched initrd.img /live/image may not point the right location and may need manually creating the link /live/image to /lib/live/mount/persistence/sdX instead /lib/live/mount/medium, but /live/cow is created proper and /live/cow is the important link for RemasterCow to work:

Most importantly, file persistence.conf needs to end with a newline. If it doesn't persistence won't work.

Actually, it is good to remember that ALL text files in Linux should be correctly terminated with a newline. This arises from POSIX standard, which says that each line in a file must end with a newline char:

The terminating newline is also specified as necessary by the C standards: ISO/IEC 9899:2011 §7.21.2 Streams

Though many commandline utilities have been written to work with or without the newline, some don't. Command 'diff', for example, would probably complain if it is missing. Some text utilities may not read the last line correctly if the terminating \n is missing - can also be a problem in shell script loops if not carefully written.

The result is that you are certainly not alone, step, in running into an apparently 'weird' bug, which ends up just being caused by an improperly terminated text file. Though I'm well aware of the standard, it is an easy one to miss, and I've also found myself scratching my head in bewilderment because of a missing newline I wasn't aware of in some input file or other I was working with on a project. It should also be a lesson to developers who write utilities and do not take care to account for the special case of newline terminator missing on input file. They should always check for that and account for it (in other words, I blame Debian...). But it is best to stick to the POSIX recommended newline terminator on any files you create anyway since that of course avoids the possible issue.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum