Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Stemsee, this is one more example what is the advantage of main-stream linux.
Boot puppy sfs module with debian kernel and initrd and you get all debian save file options and multiple squashfs load + puppy system. Fully working system with debian save file options.
Boot debian squashfs module with latest puppy developed initrd and puppy kernel and you get broken system.
Fred took porteus initrd and kernel and made debian squashfs to work with them keeping the save file options and advantages from porteus on debian system. Then he went further with some help from Sfs and made the same initrd file to work the same way with debian kernel having the best from Porteus and Debian in one system that is now DebianDog.
When something does not work but you see value in it you should keep trying to make it work till it is done. The word stunts has much different meaning to me.
But you decide what has value for you. If you are happy to have by accident live/secure/safe boot disc option and this is OK, then I'm happy for you. I would even suggest to type xdm-start in terminal to activate the login manager and install firewall. Then remaster DebianDog before renaming the main module to puppy.sfs and you will have much more secure system that is well protected. Even from the user itself.
Boot puppy sfs module with debian kernel and initrd and you get all debian save file options and multiple squashfs load + puppy system. Fully working system with debian save file options.
Boot debian squashfs module with latest puppy developed initrd and puppy kernel and you get broken system.
Fred took porteus initrd and kernel and made debian squashfs to work with them keeping the save file options and advantages from porteus on debian system. Then he went further with some help from Sfs and made the same initrd file to work the same way with debian kernel having the best from Porteus and Debian in one system that is now DebianDog.
When something does not work but you see value in it you should keep trying to make it work till it is done. The word stunts has much different meaning to me.
But you decide what has value for you. If you are happy to have by accident live/secure/safe boot disc option and this is OK, then I'm happy for you. I would even suggest to type xdm-start in terminal to activate the login manager and install firewall. Then remaster DebianDog before renaming the main module to puppy.sfs and you will have much more secure system that is well protected. Even from the user itself.
Hi, Fred.
Do you have any plans to work on encrypted save file option for porteus boot?
I'm reading some links from Sfs pointed to us in this thread - Russian language only but at least the code examples are in English![Smile :)](./images/smilies/icon_smile.gif)
http://forum.puppyrus.org/index.php/top ... l#msg86697
http://forum.puppyrus.org/index.php/topic,15571.0.html
From what I understand the initrd.xz is very similar to porteus one. Not sure what is included inside but this is from one of the links:
http://www.puppyrus.org/~melvik/puppyru ... 02/kernel/
http://www.puppyrus.org/~melvik/puppyru ... 6-porteus/
http://www.puppyrus.org/~melvik/puppyru ... /initrd.xz
Otherwise I'm reading about encryption for Wheezy. I'm not sure what I will find as solution yet but we shall see.
Toni
Do you have any plans to work on encrypted save file option for porteus boot?
I'm reading some links from Sfs pointed to us in this thread - Russian language only but at least the code examples are in English
![Smile :)](./images/smilies/icon_smile.gif)
http://forum.puppyrus.org/index.php/top ... l#msg86697
http://forum.puppyrus.org/index.php/topic,15571.0.html
From what I understand the initrd.xz is very similar to porteus one. Not sure what is included inside but this is from one of the links:
http://www.puppyrus.org/~melvik/puppyru ... 02/kernel/
http://www.puppyrus.org/~melvik/puppyru ... 6-porteus/
http://www.puppyrus.org/~melvik/puppyru ... /initrd.xz
Otherwise I'm reading about encryption for Wheezy. I'm not sure what I will find as solution yet but we shall see.
Toni
This post no longer applicable since fixed/upgraded versions of xrecord and pavrecord now uploaded later.
Cheers, William
Cheers, William
Last edited by mcewanw on Sat 19 Jul 2014, 04:03, edited 1 time in total.
github mcewanw
updated/fixed pavrecord deb uploaded now
Hi Toni,
Have now uploaded revised pavrecord (version 0.9.4) in deb format. This contains the critical VU peak level meter fix suggested by SFR. Thanks again Jake. I've attached it to main pavrecord thread since that helps me keep the various Puppy versions in sync:
http://www.murga-linux.com/puppy/viewtopic.php?p=656582
Toni and Fred: You should completely remove the old one includine the .pavrecord folder in $HOME before installing this fixed version, just to be sure all will be fine...
I'm currently busy working on updating the several versions of this and precord for Puppy. If only people could compile ffmpeg to contain the same encoders... By the way, Fred, your static ffmpeg squashfs build doesn't seem to include support for x11grab.
Cheers, William
Have now uploaded revised pavrecord (version 0.9.4) in deb format. This contains the critical VU peak level meter fix suggested by SFR. Thanks again Jake. I've attached it to main pavrecord thread since that helps me keep the various Puppy versions in sync:
http://www.murga-linux.com/puppy/viewtopic.php?p=656582
Toni and Fred: You should completely remove the old one includine the .pavrecord folder in $HOME before installing this fixed version, just to be sure all will be fine...
I'm currently busy working on updating the several versions of this and precord for Puppy. If only people could compile ffmpeg to contain the same encoders... By the way, Fred, your static ffmpeg squashfs build doesn't seem to include support for x11grab.
Cheers, William
github mcewanw
Thanks, William.
What is your suggestion - to replace pavrecord with the attached one or to uninstall the package and install the new one? Is there something more changed in the deb package than the version name and /usr/bin/pavrecord?
I try to keep at minimum configuration program directories in $HOME/ In Jwm version there is no $HOME/.pavrecord I guess it is not a problem since it is created on first program run?
Toni
What is your suggestion - to replace pavrecord with the attached one or to uninstall the package and install the new one? Is there something more changed in the deb package than the version name and /usr/bin/pavrecord?
I try to keep at minimum configuration program directories in $HOME/ In Jwm version there is no $HOME/.pavrecord I guess it is not a problem since it is created on first program run?
Toni
The only other thing changed in the deb package is the Debian Control file, which contains the correct current version number of pavrecord. The separate main pavrecord script I attached to this thread is the same one in the deb Toni. I particularly informed you of the new deb since you would need to replace the one currently stored at smokey's site.saintless wrote:Thanks, William.
What is your suggestion - to replace pavrecord with the attached one or to uninstall the package and install the new one? Is there something more changed in the deb package than the version name and /usr/bin/pavrecord?
I try to keep at minimum configuration program directories in $HOME/ In Jwm version there is no $HOME/.pavrecord I guess it is not a problem since it is created on first program run?
Toni
Yes, it is not a problem (in fact it is better) to provide the iso with no $HOME/.pavrecord since as you say it is created automatically anyway the first time pavrecord is run.
William
github mcewanw
Hi Toni,
These days I'm busy working as volunteer for an alternative computer repair/shop.
They switched to Lubuntu as replacement for windows xp.
Also they have some "thin clients" (it's very low-ram small computer, 256MB RAM and only 256MB HDD) for connecting to server.
I tried openbox version on that but it's to heavy so using your JWM version now
Btw, I tried using Simple network setup as default network manager but frisbee is more reliable for wired connection (sns is unstable when unplugging/plugging cable and automatic connecting when rebooted)
Fred
Thanks, I didn't have plans but I'll look at it when I have time.Hi, Fred.
Do you have any plans to work on encrypted save file option for porteus boot?
Thanks, that solved it.Remove this lines from /root/bashrc and the problem is solved.
Code:
if [ $SUDO_USER ]; then
sudo -H -u $SUDO_USER xauth extract - $DISPLAY | xauth merge -
fi
These days I'm busy working as volunteer for an alternative computer repair/shop.
They switched to Lubuntu as replacement for windows xp.
Also they have some "thin clients" (it's very low-ram small computer, 256MB RAM and only 256MB HDD) for connecting to server.
I tried openbox version on that but it's to heavy so using your JWM version now
![Smile :)](./images/smilies/icon_smile.gif)
Btw, I tried using Simple network setup as default network manager but frisbee is more reliable for wired connection (sns is unstable when unplugging/plugging cable and automatic connecting when rebooted)
Sorry, should have wrote: I forgot on openbox version, obviously didn't install latest deb you made.Fred wrote:We forgot to add the gsu line on top of /usr/bin/frisbee.
Fred
Hi, Fred.
Nice to read you work with old PC like mine
Better comress the main module with default gzip for this computer. It will work faster.
Encrypted save file and save partition solved for live-boot-3x thanks to Refracta forum and Dzz:
http://refracta.freeforums.org/snapshot ... -t182.html
He also solved the rw-boot partition mounting and SWAP not working issue for live-boot-3x. Now the persistence save file can be on the boot partition. Tested the pach for initrd from Dzz and works fine for encrypted save file with DebianDog.
I will look for live-boot-2x encrypted save file option now.
If we decide to use by default encrypted save file/partition we need to include cryptsetup package (it is 1Mb uncompressed) and we need to rebuild initrd files with cryptsetup support.
We have time to decide and test this, Fred. At least with live-boot-3x the problem is solved and it can be included even as separate initrd.img for encrypted save file/partition support without touching anything in the iso files.
Toni
Nice to read you work with old PC like mine
![Smile :)](./images/smilies/icon_smile.gif)
Encrypted save file and save partition solved for live-boot-3x thanks to Refracta forum and Dzz:
http://refracta.freeforums.org/snapshot ... -t182.html
He also solved the rw-boot partition mounting and SWAP not working issue for live-boot-3x. Now the persistence save file can be on the boot partition. Tested the pach for initrd from Dzz and works fine for encrypted save file with DebianDog.
I will look for live-boot-2x encrypted save file option now.
If we decide to use by default encrypted save file/partition we need to include cryptsetup package (it is 1Mb uncompressed) and we need to rebuild initrd files with cryptsetup support.
We have time to decide and test this, Fred. At least with live-boot-3x the problem is solved and it can be included even as separate initrd.img for encrypted save file/partition support without touching anything in the iso files.
Toni
a couple days ago I acheived remedial save function with DebianPup equal to the solution saintless posted for booting puppy with DD (DebianDog) initrd. This assumes booting to ram from sda3 chang appropriately for your setup or add searh for savefile function.
Mount script
#!/bin/sh
mkdir -p /media/sda3 && mount /dev/sda3 /media/sda3
mount /media/sda3/live/debian-save.2fs /initrd/pup_ro5
cp -r -p /initrd/pup_ro5/. /initrd/pup_rw/
restart X to see changes or add to init
save script
#!/bin/sh
cp -r -p /initrd/pup_rw/. /initrd/pup_ro5/
But work continues to implant full puppy options
Edit: the official fatdog64 option is to specify a kernel argument pupsave=ram:/path/to/savefile #mounts save file on /initrd/pup_rw ram layer
or pupsave=save:/path/to/savefile #mounts savefile on /initrd/pup_save - which doesn't exist outside of real FatDog64 initrd.
neither worked for me, maybe not enough testing.
Mount script
#!/bin/sh
mkdir -p /media/sda3 && mount /dev/sda3 /media/sda3
mount /media/sda3/live/debian-save.2fs /initrd/pup_ro5
cp -r -p /initrd/pup_ro5/. /initrd/pup_rw/
restart X to see changes or add to init
save script
#!/bin/sh
cp -r -p /initrd/pup_rw/. /initrd/pup_ro5/
But work continues to implant full puppy options
Edit: the official fatdog64 option is to specify a kernel argument pupsave=ram:/path/to/savefile #mounts save file on /initrd/pup_rw ram layer
or pupsave=save:/path/to/savefile #mounts savefile on /initrd/pup_save - which doesn't exist outside of real FatDog64 initrd.
neither worked for me, maybe not enough testing.
Last edited by stemsee on Fri 20 Jun 2014, 10:25, edited 1 time in total.
Hi, William.
I'm fine and my family also. We have small flat in Varna - Asparuhovo (where the tragedy happened) but we live 5 Km from there at the moment. Unfortunately official statement is at least eleven people died in the floods in Varna (including 2 children)... Hope there will not be more...
Toni
I'm fine and my family also. We have small flat in Varna - Asparuhovo (where the tragedy happened) but we live 5 Km from there at the moment. Unfortunately official statement is at least eleven people died in the floods in Varna (including 2 children)... Hope there will not be more...
Toni
Sorry, Dan, rar (unrar) is non-free software and we can't include it installed in DebianDog:
https://packages.debian.org/wheezy/rar
We need to find alternative free version for linux that does the same job or to leave the user to install it with apt-get or Synaptic later.
Toni
https://packages.debian.org/wheezy/rar
We need to find alternative free version for linux that does the same job or to leave the user to install it with apt-get or Synaptic later.
Toni
Hi Toni,
I think I have the hardest part done for porteus save file encryption: the loading at boot.
Here's initrd1.xz-crypt
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
If it works for you also then I need only to modify the makepfile.sh script for supporting encryption.
Also attached make-changes script from original porteus, maybe it can be useful.
Fred
I think I have the hardest part done for porteus save file encryption: the loading at boot.
Here's initrd1.xz-crypt
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
If it works for you also then I need only to modify the makepfile.sh script for supporting encryption.
Also attached make-changes script from original porteus, maybe it can be useful.
Fred
- Attachments
-
- make-changes.tar.gz
- make-changes script from porteus inside archive
- (7.99 KiB) Downloaded 137 times
Hi, Fred.fredx181 wrote:Hi Toni,
I think I have the hardest part done for porteus save file encryption: the loading at boot.
Here's initrd1.xz-crypt
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
If it works for you also then I need only to modify the makepfile.sh script for supporting encryption.
Also attached make-changes script from original porteus, maybe it can be useful.
Fred
Works fine with already encrypted persistence file renamed to changes.dat
Here is what we have to the moment:
Porteus-boot:
Saving changes inside encrypted save file (changes.dat or different named).
No changes in boot code needed.
initrd1.xz-crypt is only 0,3Mb bigger:
http://smokey01.com/saintless/DebianDog ... 1.xz-crypt
Live-boot-3x, thanks to Refracta initrd patch:
Saving changes inside encrypted persistence save file (with persistence.conf inside):
Saving changes inside partition labeled persistence (with persistence.conf inside).
Saving changes in non-encrypted persistence save file placed inside encrypted partition.
initrd1.img-crypt is 1,9Mb bigger:
http://smokey01.com/saintless/DebianDog ... .img-crypt
Needs addition to boot code. This one will use encrypted persistence save file placed inside /live directory:
Code: Select all
title DebianDog Wheezy live-boot-3 Persistence Encrypted
uuid 25e43216-01b1-43eb-b02d-6350e970da2c
kernel /live/vmlinuz1 boot=live config swapon noeject quickreboot autologin basemountmode=rw,noatime,umask=000 persistence persistence-path=/live/ persistence-encryption=none,luks
initrd /live/initrd.img-crypt
basemountmode=rw,noatime,umask=000 (or basemountmode=rw) - this one will mount boot partition RW and now save file can be placed on boot partition. If it is missing boot partiition is mounted RO.
persistence-path=/live/ - this points the path to persistence save file.
persistence-encryption=none,luks - the system will search for non-encrypted or luks-encrypted save file/partition.
Live-boot-2x - still searching for solution but for the moment only live-sn (non-encrypted) and home-rw (non-encrypted) but placed inside encrypted partition works. I can't make live-rw from encrypted partition to work and also can't make encrypted save file work.
Fred, I think we should upload the initrd-crypt files for testing for some period of time. Replacing them inside the iso without proper testing from more people may bring more troubles later. Maybe wait more than a month for next updated iso?
We will also need to include aespipe and cryptsetup packages in the main module.
What do you think we should do?
Toni
Hi Toni,
We could maybe replace the iso's with included cryptsetup and aespipe (where is that for?) and other changes and give the choice to download and use initrd crypt. I 'm not in a hurry though.
Btw, the porteus-boot encrypted savefile option should be ok I think, I tested it around 20 times.
Here's mk-save.gtkdlg and makepfile.sh with added checkbox for encryption support.
I added parts of the porteus "make-changes" script which is very solid IMO.
Attached: mk-save.tar.gz
EDIT: uploaded again with major correction in mk-save.gtkdlg script
Fred
We don't have many testers these days, maybe we should hire someFred, I think we should upload the initrd-crypt files for testing for some period of time. Replacing them inside the iso without proper testing from more people may bring more troubles later. Maybe wait more than a month for next updated iso?
We will also need to include aespipe and cryptsetup packages in the main module.
What do you think we should do?
![Smile :)](./images/smilies/icon_smile.gif)
We could maybe replace the iso's with included cryptsetup and aespipe (where is that for?) and other changes and give the choice to download and use initrd crypt. I 'm not in a hurry though.
Btw, the porteus-boot encrypted savefile option should be ok I think, I tested it around 20 times.
Here's mk-save.gtkdlg and makepfile.sh with added checkbox for encryption support.
I added parts of the porteus "make-changes" script which is very solid IMO.
Attached: mk-save.tar.gz
EDIT: uploaded again with major correction in mk-save.gtkdlg script
Fred
- Attachments
-
- mk-save.tar.gz
- mk-save.gtkdlg and makepfile.sh with encryption support
- (4.26 KiB) Downloaded 130 times
Thank you, Fred!fredx181 wrote:Attached: mk-save.tar.gz
I will test porteus encrypted save file proper in the next days.
Live-boot-3x encrypted save is also tested many times by me last few days and I think it will work fine.
Live-boot-2x is the one making troubles for me but I think I will get it done in time.
I think the best way to go is to add cryptsetup and aespipe (older aes encryption support for cryptsetup) in the main module and to replace only porteus initrd1.xz with the new one. The iso size will stay almost the same and we have encryption save file option for porteus boot. But this is for later.
initrd1.img-crypt and initrd.img-crypt will be available for download from the site (both will add 4Mb to the iso size and I see nobody else but me using live-boot-2x and live-boot-3x).
I will keep testing the encryption changes in the next days and get back with results.
Much easier for us this way, FredWe don't have many testers these days, maybe we should hire some
![Smile :)](./images/smilies/icon_smile.gif)
Toni
I think you guys should consider trying to get a wider pool of users by posting it on some Debian message boards or maybe the Porteus ones.fredx181 wrote:Hi Toni,
*stuff deleted
We don't have many testers these days, maybe we should hire some![]()
*stuff deleted
I have had some trouble getting Google Earth to recognize my display card, which is showing direct rendering and works for xbmc. I'll try to write up the issue sometime this week.