DebianDog - Wheezy
Thanks, Fred, sorry Tm_mT, my mistake. I will correct the first post now.
Flashplayer choice problem then:
Type in terminal flashplayerchoice and see if it starts. If it does, then I guess the menu entry is deleted for some reason. Please, right click on /root/.bash_history and --Add to archive and attach the archive here. This will give me information what custom programs you have installed with apt-get to repeat your steps.
Or if you can tell from memory just write the programs installed from you.
Toni
Flashplayer choice problem then:
Type in terminal flashplayerchoice and see if it starts. If it does, then I guess the menu entry is deleted for some reason. Please, right click on /root/.bash_history and --Add to archive and attach the archive here. This will give me information what custom programs you have installed with apt-get to repeat your steps.
Or if you can tell from memory just write the programs installed from you.
Toni
Hi step,step wrote:What code/config changes do you recommend to skip starting X during live boot-3x? I want live boot to fully set up everything, but leave DebianDog running at the command line prompt without X graphics. Then if root wanted to start X she could just type startx. TIA.
Open /etc/inittab with text editor,
Find the lines:
Code: Select all
1:2345:respawn:/bin/login -f root tty6 </dev/tty1 >/dev/tty1 2>&1
#1:2345:respawn:/sbin/getty 38400 tty1
Code: Select all
# 1:2345:respawn:/bin/login -f root tty6 </dev/tty1 >/dev/tty1 2>&1
1:2345:respawn:/sbin/getty 38400 tty1
Fred
Uhmm sorry guys, I think I explained incorrectly what happened. There is no problem, well.. there was a problem.. "me". I couldn't find it, but that doesn't mean it wasn't theresaintless wrote: Flashplayer choice problem then:
Not sure when it happens, will try to follow the text better next time I am booting again but indeed there is a check and right before the check the error message occurs.saintless wrote:
Do you see this fsck save file message on boot (before modules loading 01-filesystem.squashfs message).
That's right, that's what I need. Thanks.saintless wrote:Hi, Fred.
I think Step needs to autologin but not starting X.
Toni
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
Hi Toni, step,
Sorry, Step.
Then if in Jwm version remove (or comment out) this:
(last lines) from /etc/profile
Now don't tell me this is wrong again!
Fred
Yes, of course that's a difference,I think Step needs to autologin but not starting X. This needs some reading and testing.
Sorry, Step.
Then if in Jwm version remove (or comment out) this:
Code: Select all
if [ -z "${DISPLAY}" ] && [ $(tty) = /dev/tty1 ]
then
startx
fi
Now don't tell me this is wrong again!
Fred
New and updated packages and fixes information and download links.
Usually as deb packages to install with right click or files to replace directly.
The list is short for the moment.
If you mean official Debian bugfixes they are in debian repository as upgraded packages.
Usually as deb packages to install with right click or files to replace directly.
The list is short for the moment.
If you mean official Debian bugfixes they are in debian repository as upgraded packages.
You are right it didn't delete on destination ... and I DO need that. Just resquashed 8+GB at max compression (takes a long time) and I have the same sfs!!! . Let's try your code.fredx181 wrote: I forgot to mention before that when I tested your rsync command I found that it doesn't delete files in the target directory (synced with the deleted files on the filesystem).
The command I wrote does that (really "syncs" it) but maybe you don't need that really.
Fred
Thanks Anikin I'll take a look, but I am determined to succeed and present onlookers with a another useful version!
Thanks Fred, all is well now!fredx181 wrote:(last lines) from /etc/profile
Now don't tell me this is wrong again!
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
@fredx181
FYI
rsync -a = rsync -rlptgoD
I added -u and -H and --progress (instead of -v). Seems to do the job. fake .gz
I am not good at forensics but maybe you can give me an idea of what happens if zero-sizing man/doc/help/info occurs in the same workdir several times over?
FYI
rsync -a = rsync -rlptgoD
I added -u and -H and --progress (instead of -v). Seems to do the job. fake .gz
I am not good at forensics but maybe you can give me an idea of what happens if zero-sizing man/doc/help/info occurs in the same workdir several times over?
- Attachments
-
- ursync.gz
- (3.31 KiB) Downloaded 168 times
Hi, Tm_mT.Tm_mT wrote:I assume if I want my changes.dat encrypted I can't do it easily afterwards?
First version for testing move-in-crypt:
http://www.smokey01.com/saintless/Fredx ... -crypt.zip
Extract the archive in /opt/bin and type in terminal move-in-crypt
Use it with no save boot code (the source save file must be unmounted).
You need to create empty encrypted save file first. Make sure it is the same size or bigger from the non-encrypted source save file. Also /dev/loop6 must be free but it is free by default (if you do not have 4 more sfs modules loaded at the moment).
Firts choose the encrypted (empty) save file and bellow choose source (non-encrypted) save file and click OK. There will be prompt to type the password for the encrypted save file.
Not perfect but it will save us some typing.
Toni
Just gave it a shot, unfortunately my save file is bigger than what was accepted by the make save file script.saintless wrote: Make sure it is the same size or bigger from the non-encrypted source save file.
I think my previous savefile was created in live-boot 2 and there was no limit then. I created a 4 Gb changes.dat
Still tried to copy the data to a 2 Gb file with the tool (seemed to work)
After rebooting I needed to add the password, but then my keyboard entry wasn't accepted (it even hang completely..)
To be sure it wasn't something else, I used another keyboard, rebooted and the same result.
Is there a reason for limitting the save file to 2 Gb? Or can I dd a changes.dat file of 4 Gb from command line?
Hi, Tm_mT.
The script is combined for all boot methods and the only easy way to make bigger encrypted save file is to boot with live-boot-2x or live-boot-3x and create save file then. Just give it name changes.dat. Too much typing from command line otherwise.
Edit: Are you using vmlinuz6 and initrd63.xz? Is encrypted save file work at all for you? I can't start X with 3.14 kernel module at the moment but I will try to test it somehow.
Edit2: OK, checked with 4Gb encrypted save and kernel 3.14 (vmlinuz6 and initrd63.xz). Using move-in-crypt to copy 2Gb non-encrypted in 4Gb encrypted save and boot with encrypted save file. I can't start X with 3.14 kernel because of my old hardware but the save file is checked for errors and changes are there (checked the new installed and removed programs from command line). Still can't reproduce the problem you have. It is working well for me.
Is the error message you get about save file: /dev/mapper/crypt was not clearly unmounted ... forced check...? If so this is only when using encrypted save file and seems /dev/mapper/crypt is not unmounted before reboot. I don't know if Fred can do something about this but I doubt it will create some kind of a problem. Save file is always checked on boot.
Toni
Unfortunately I can't see this error on my system. I boot from ext partition on my hard drive (sda1 usually). Can you give some more details about your setup like ext, vfat, ntfs partition. I will try to reproduce the same situation and test with 4Gb save file (I never use more than 1GB).Tm_mT wrote:The message comes after the message it is checking the dat file for errors. Then it reports persistence was not correctly unmounted and the check starts.saintless wrote:Do you see this fsck save file message on boot (before modules loading 01-filesystem.squashfs message).
I think the 2Gb limit is for Fat16 and Fat32 partitions (but then it should be impossible to create bigger save file on vfat partition and I see no reason for 2Gb limit in the utility). I didn't know it is limited this way for porteus-boot mk-save utility. Maybe there is a reason and Fred will give more information about this later.Tm_mT wrote:Just gave it a shot, unfortunately my save file is bigger than what was accepted by the make save file script.
I think my previous savefile was created in live-boot 2 and there was no limit then. I created a 4 Gb changes.dat
Still tried to copy the data to a 2 Gb file with the tool (seemed to work)
The script is combined for all boot methods and the only easy way to make bigger encrypted save file is to boot with live-boot-2x or live-boot-3x and create save file then. Just give it name changes.dat. Too much typing from command line otherwise.
I guess this is because you had more than 2Gb data in source save. I tested few times (with much smaller save file) by installing and removing programs and adding keyboard layout. After the copy in encrypted save file with move-in-crypt no problem to boot the encrypted save and all changes are there. I will test it with 4Gb files to see if there is any difference.After rebooting I needed to add the password, but then my keyboard entry wasn't accepted (it even hang completely..)
To be sure it wasn't something else, I used another keyboard, rebooted and the same result.
Edit: Are you using vmlinuz6 and initrd63.xz? Is encrypted save file work at all for you? I can't start X with 3.14 kernel module at the moment but I will try to test it somehow.
Edit2: OK, checked with 4Gb encrypted save and kernel 3.14 (vmlinuz6 and initrd63.xz). Using move-in-crypt to copy 2Gb non-encrypted in 4Gb encrypted save and boot with encrypted save file. I can't start X with 3.14 kernel because of my old hardware but the save file is checked for errors and changes are there (checked the new installed and removed programs from command line). Still can't reproduce the problem you have. It is working well for me.
Is the error message you get about save file: /dev/mapper/crypt was not clearly unmounted ... forced check...? If so this is only when using encrypted save file and seems /dev/mapper/crypt is not unmounted before reboot. I don't know if Fred can do something about this but I doubt it will create some kind of a problem. Save file is always checked on boot.
Toni
Last edited by saintless on Mon 11 Aug 2014, 05:48, edited 2 times in total.
New changes:
1. Small change to make load= boot parameter work for porteus-boot in linixrc file inside initrd1.xz.
More information from Fred here. All separate kernel modules reuploaded (only initrd file for porteus-boot changed inside) and rebuilded initrd1.xz for the iso available for download here. It will be replaced in next DebianDog version (when we get enough improvements to add).
You can keep using the old kernel modules and initrd files for porteus-boot without problem, but if you like to use load= option replace initrd file for porteus-boot with the proper one for your kernel from the links above.
2. New version Porteus-Wheezy-3.13.6-openbox.iso. Added same improvements like in DebianDog latest version but the kernel is 3.13.6 from Porteus and the modules extension is .xzm (like in Porteus). This version runs with systemd boot enabled.
http://www.murga-linux.com/puppy/viewto ... 371#742371
1. Small change to make load= boot parameter work for porteus-boot in linixrc file inside initrd1.xz.
More information from Fred here. All separate kernel modules reuploaded (only initrd file for porteus-boot changed inside) and rebuilded initrd1.xz for the iso available for download here. It will be replaced in next DebianDog version (when we get enough improvements to add).
You can keep using the old kernel modules and initrd files for porteus-boot without problem, but if you like to use load= option replace initrd file for porteus-boot with the proper one for your kernel from the links above.
2. New version Porteus-Wheezy-3.13.6-openbox.iso. Added same improvements like in DebianDog latest version but the kernel is 3.13.6 from Porteus and the modules extension is .xzm (like in Porteus). This version runs with systemd boot enabled.
http://www.murga-linux.com/puppy/viewto ... 371#742371
Hi, Tm_mT, here is the fixed version (fix 5):Tm_mT wrote:Is there a reason for limitting the save file to 2 Gb? Or can I dd a changes.dat file of 4 Gb from command line?
http://murga-linux.com/puppy/viewtopic. ... 368#776368
Replace the files and you can make up to 20Gb save file from porteus-boot.
I asked Fred for 100Gb limit but he said "No!" Sorry...
If you need more than 20Gb just use again live-boot-2x or live-boot-3x. It will work.
See attachment 2014-08-11 21.58.59.jpg, sorry for the bad qualitysaintless wrote:Do you see this fsck save file message on boot (before modules loading 01-filesystem.squashfs message).
Encrytped save doesn't work at all. Even if it is started from scratch and 2GB. See attachment 2014-08-11 21.54.55.jpgsaintless wrote: Edit: Are you using vmlinuz6 and initrd63.xz? Is encrypted save file work at all for you? I can't start X with 3.14 kernel module at the moment but I will try to test it somehow.
- Attachments
-
- 2014-08-11 21.54.55.jpg
- (87.21 KiB) Downloaded 240 times
-
- 2014-08-11 21.58.59.jpg
- (96.95 KiB) Downloaded 232 times