pcPuppyOS FINAL

[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.

[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 ).

[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.

[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.

[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.