pcPuppyOS FINAL

For talk and support relating specifically to Puppy derivatives
Message
Author
nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#31 Post by nooby »

I'm sure that I have asked this before and then forgotten all about it.

Is this a 2.14 puppy or a Puppy301 thing?

I try to copy my menu.lst to show why I ask.
title Puppy 301 PcPuppyOS
rootnoverify (hd0,0)
kernel /puppy301/vmlinuz PMEDIA=satahd PDEV1=sda1 psubdir=puppy301
vga=normal keyb=se
initrd /puppy301/initrd.gz
boot
The rootnoverify (hd0,0) is typical for 2.14 and doesn't that mean that
when I install teenpup which also is a 2.14 thingy then they will catch each
others save files?
my pup301 is named pup_save-301.2fs so that maybe protect it from being used by teenpup2008?


vg1 has suggested something that should work

but me being a noob I feel very insecure about if I manage to follow all those instruction of renaming a file from pup214R that I've downloaded and set it all up right.
I use Google Search on Puppy Forum
not an ideal solution though

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#32 Post by vg1 »

Nooby,

pcPuppyOS is based on puppy 301, not puppy 2.14. Its save_file is in a dir, teenpup will not find it Rootnoverify is not typical for p214, it's a grub thing and can be used with any version or distro.

A save_file in a dir will be found by some other p3 or p4 versions if their psubdir= is not specified. In that case all the files found will be presented for you to choose. Psubdir= is usually specified anyway so don't worry. I said more about this in the other thread on booting teenpup from a dir.

daniela132
Posts: 10
Joined: Wed 08 Oct 2008, 09:08

#33 Post by daniela132 »

Hi pizzagood,
How do you install clamav and remaster this Puppy? Are you remaster from installed Puppy or remaster a Live CD? Cause I have a problem to remaster liveCD with clamav included.
Thanks a lot.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#34 Post by Pizzasgood »

I install ClamAV by downloading the source from their website (clamav.net) and compiling it. I am careful to back up the files in /usr/etc/ for clamav (clamd.conf and freshclam.conf), then to compare them with the new versions and update the new ones to include the settings I set in the old ones. The "ON_ACCESS" and "NO_ON_ACCESS" files are just duplicates of clamd.conf, one with on-access scanning enabled. That caused instability for me, which is why I have it disabled by default. Neither of those files are needed, they're just there for convenience so you can copy one over clamd.conf to change it without having to open the file and dig around to find the settings that need changing.

I don't think I used any special options when compiling, other than --prefix=/usr. I may have used others, but I don't see them written in my notes anywhere so I don't think so.



As for remastering, the remaster script in pcpuppyos is a custom version, so your error could be related to that, but without knowing what error you got I wouldn't know. I did test it, but there's always a chance that something slipped past. What went wrong? If it didn't give an error message, try running it from the commandline:

Code: Select all

remasterpup2
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

daniela132
Posts: 10
Joined: Wed 08 Oct 2008, 09:08

#35 Post by daniela132 »

Hi pizzasgood,

I think I have made a mistake. Today, I have search the forum and found that I must include devx_410.sfs to compile from source. But I think I will do it tommorow since I have to download it this night.

Anyway, I have another way. I think I can compile clamav in Ubuntu, and copy all 'clam' files to puppy. Can I do this? :D

Edited : No. My idea can't be used :(

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#36 Post by PaulBx1 »

I've run into boot problems.

This iso boots "pfix=ram" all right, but when I try booting using an encrypted (by pcpuppyos) pupsave, I get through the mount of the pupsave OK (message "successfully mounted") but then:

Code: Select all

Loading the 'pup_301.sfs' main file...  Copying to ram... done
Kernel panic - not syncing: Attempted to kill init!
I checked the sfs file on disk against the one on the CD using md5sum. It looks good and as I said, that works with pfix=ram. I tried "loglevel=7" but no more messages appeared between the "Loading" message and the panic.

I can't recall if it is happy with an unencrypted pupsave. I will try that again and report.

<later>
Boots fine with an unencrypted pupsave. And it reliably gets a kernel panic with a dm-crypt encrypted one.

The machine is a Dell Inspiron 1525, a fairly new machine.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#37 Post by Pizzasgood »

Hmmm... I'll check it out later this week/weekend.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#38 Post by Pizzasgood »

It's working fine on my end. I'm not sure what would cause a difference based on encryption or no encryption. I'll dig out the boot script and examine that to see if anything sticks out.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#39 Post by Pizzasgood »

Would I be right in guessing that you were trying to use a 32-MB save file? Nothing wrong with that. But the problem is pcPuppyOS is configured so that it will automatically attempt to estabolish a network connection with dhcp, and then it will automatically attempt to update the virus definitions for ClamAV. Which appear to be ~37 MB in size.

Apparently, creating a save file when you have slightly more than the size of the file doesn't normally cause an issue. But if the file you're creating is encrypted with dmcrypt, it does cause an issue.

So there are a couple options. One is just use a larger file. Another is to disable the auto-update. The code only gets run when X is started, so if you boot with pfix=ram,nox you can boot to the commandline. Then run this command:
chmod 644 /etc/init.x/freshclam_daemon
Then you can run xorgwizard and start up X as usual, and it won't update the virus definitions unless you tell it to (menu -> utilities -> clamav, IIRC).

(In case you're wondering, the /etc/init.x/ directory works similarly to /etc/init.d/, except that it runs things when X starts instead of when Puppy boots. Actually, I think that's about the same thing as the /root/Startup/ directory that Puppy has nowadays.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#40 Post by PaulBx1 »

Good guess; it was a 32M pupsave. Maybe you need to disallow this choice in pcpuppyos.

I will check a larger one in a while; going on the road soon.

Say, is the swap encrypted? Seems to me the default is no swap.

There is also some thing out there about dm-crypt being substandard if used in a particular way (without salt, or something like that). Were you aware of that? Google would turn up some stuff. I will dig later if you don't know about this.

BTW I noticed that if you have multiple pupsaves, you normally get the inquiry about which one you want. However if you leave the splash on, the inquiry is invisible and unless you realize what is going on, you just sit there forever waiting for it to boot while it is waiting for your selection.

Maybe this was mentioned earlier in this thread; I haven't read through.

Personally, I don't like splash screens. This is linux; we are supposed to see the boot process going by. Just my opinion...

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#41 Post by Pizzasgood »

pfix=nosplash disables the splash. It should have turned itself off to let you choose, like it does for inputting the password for the encryption. I've fixed a number of bugs in Pebble since releasing pcPuppyOS though, so maybe that was one of them. I'll try to look at it this weekend.
Personally, I don't like splash screens. This is linux; we are supposed to see the boot process going by. Just my opinion...
I would personally prefer a split screen, and that's one of the main goals for version 2.0 of Pebble, whenever I get around to writing it. Doing that will also require changing the manner in which the program handles the text-flow, which should also allow me to have a hotkey to disable it on the fly. The current version was an attempt to just get the basic animation support working, and its structure is such that split screen and interactive control are not possible.




I never modified any code relating to swap, so no encryption there.

There is also some thing out there about dm-crypt being substandard if used in a particular way (without salt, or something like that). Were you aware of that? Google would turn up some stuff. I will dig later if you don't know about this.
No, I don't recall anything about that. I'll do some googling when I look into Pebble and multiple files.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
technowomble
Posts: 74
Joined: Thu 11 Oct 2007, 17:04
Location: West Gloucestershire, UK

One - possibly two - bugs in PuppyOS.

#42 Post by technowomble »

Pizzasgood,

I've been trying PuppyOS, and I'm generally impressed, but I do have a couple of items on my snag sheet.

The boot splash ran normally when I ran from the CD, but after doing a full install I can't seem to get it to run. This could be finger trouble on my part or one of the bugs in Pebble you mentioned in your last post, either way it's more of a nuisance than a real problem. More serious is that the provision to sync with a time server seems to be broken, with my time zone correctly set to London, UK, it did not adjust for the end of BST/DST here at the weekend and trying to set up a time server from the menu met with no success, it reported the one server in /etc/timeserver as unreachable, possibly broken.

Apart from these snags, nicely done, I can see PuppyOS proving popular as a ' budget ' office system - take one old desktop... ( I've been running it on a Dell laptop, 400Mhz, 192Mb RAM, 6Gb HDD ).

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#43 Post by Pizzasgood »

Was going to play with it on Sunday but wound up spending the whole day on homework. I'll do this tonight or tomorrow (I have no class tomorrow).

Looks like the timeserver I used went down. In hindsight, I should have put more thought into picking one. You can google 'timeserver' and it should turn up a number of them. They can be tested like this:
rdate -p rolex.usg.edu
To actually set the time from them, replace the -p with a -s. To save the server, just replace the contents of /etc/timeserver with the address of the one you want.

When I patch pcPuppyOS I'll update it. Maybe I'll also give it support for holding a list of servers, in case one dies. Yes, that sounds like fun. I'll have it cache the first one it finds that works, so it doesn't have to cycle through each time.

As for DST in Linux, that's something I haven't experienced much, considering it only happens twice a year. I should experiment with it tomorrow by changing the bios time. I understand the process if you use UTC time on the hardware clock, and it just converts it to local time on the fly. But when you store it as local time, I forget what happens (I think it adjusts the HW clock back an hour? Or maybe does nothing?). Not to mention what happens when Windows is thrown into the mix, because I know that it likes to change the hardware clock's time, and will also accuse you of pirating it if it detects that you've manually messed with the time...

I won't worry about what happens when Windows interferes. Not worth the effort.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#44 Post by Pizzasgood »

From what I can tell, Linux won't auto-update your time for DST unless you have your HW clock on UTC time, which the default (and this) Puppy doesn't support. Since the HW clock is on local time, the person running it (or Windows) is supposed to update it for things like DST. The timezone files will make corrections when translating from local time to UTC time, however (like if you run date -u).

If for some reason you modify your Puppy to use UTC time in the HW clock, it will automatically adjust for DST time on the fly.



I have the upgraded time-sync script finished now, and the newest version of Pebble included. Now I'm just waiting for it to finish building the iso so I can test it.

In the brief testing I did prior to modifying anything, I had no issues with multiple save files. The bootsplash shut off like it was supposed to. But one of the bugs that I've fixed since the version included in pcPuppyOS involved a race condition where Pebble didn't always clear the screen properly, so that's probably what you were having problems with. When I get the new iso built and tested, I'll make a .delta file to upgrade the old ISO to match the new one. I would rather not upload the whole ISO until I get confirmation that it works, so that I don't have to keep re-uploading this monster.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#45 Post by Pizzasgood »

http://puppylinux.ca/tpp/pizzasgood/pcp ... REV1.delta - 24 MB
http://puppylinux.ca/tpp/pizzasgood/pcp ... ta.md5.txt

Like I said, just uploaded the .delta file. When I know I've fixed it I'll upload the iso and make a more formal announcement about rev1 (or 2 or whatever it takes).

To apply the .delta, use something like this:
xdelta3 -d -s oldfile oldfiletonewfile.delta newfile
specifically:

Code: Select all

xdelta3 -d -s pcpuppyos_301.iso pcpos_FINAL_to_REV1.delta pcpuppyos_301-rev1.iso

This uses the latest Pebble (which I actually forgot to release - was waiting on Dinky to test if it had solved his problems with Tigerpup, but he's been too busy with his new daughter to get back to me.)

This also uses version 0.2 of the timesync script, which uses a list of timeservers at /etc/timeservers, and will go through it until it finds one that works, then caches it at /etc/.last_good_timeserver so that it doesn't have to use trial-and-error every time.

Finally, I updated ClamAV to 0.94.1rc1, along with the virus definitions.


@technowomble: I haven't tested this version with a full install yet, due to my lack of a free partition where I could do one. Let me know if it works properly this time, and if not, post a copy of your menu.lst file and I'll see what I can do. If necessary I do have enough space to move everything off of one of the less-used partitions.


@PaulBx1: I think I found some info on what you were asking about, and from what I can tell we're already doing that.

http://en.wikipedia.org/wiki/Dm-crypt
When using the cipher block chaining mode of operation with predictable initialization vectors as other disk encryption software, the disk is vulnerable to watermarking attacks. This means that an attacker is able to detect the presence of specially crafted data on the disk. To address this problem in its predecessors, dm-crypt included provisions for more elaborate, disk encryption-specific modes of operation.[1] Support for ESSIV (encrypted salt-sector initialization vector) was introduced in Linux kernel version 2.6.10, LRW in 2.6.20 and XTS in 2.6.24. However, the CBC mode is still the default for compatibility with older volumes.
http://www.saout.de/misc/dm-crypt/
The defaults are aes with a 256 bit key, hashed using ripemd160. Since Linux 2.6.10 you can use an alternative IV scheme to prevent a watermark attack weakness. aes-cbc-essiv:sha256 should do it.

Code: Select all

# cryptsetup status save_file         
/dev/mapper/save_file is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 128 bits
  device:  /dev/loop2
  offset:  1032 sectors
  size:    152729 sectors
  mode:    read/write
I actually didn't specify anything besides the defaults in the script, but according to the above output we're using the ESSIV version anyways. Maybe I set that when I compiled it, or maybe they've just changed the defaults since they last updated the documentation.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

Post Reply