For what it's worth, Zero problems here on a couple of 540 frugal installs as well as a couple of older frugals I'm still running. Always ext3 or ext4 savefiles...... on ext3 or ext4 partitions....never on NTFS......all desktops.

This may be totally wrong but I think worth considering. By implication if someone is using a NTFS volume they are probably running XP or more likely Windows 7.

A couple of years back I accidentally defragged a FAT32 USB stick containing IIRC an ext2 save-file. This resulted in a totally unstable pup prone to freezes and I had to restore a good copy of the save-file in order to rectify matters.

Some time later I took to keeping my sfs and save files on my XP NTFS volume but booting from USB or SD (what I term a mixed frugal install). Back then I always used AUSLOGICS to manually defrag my NTFS volume but always excluded the directories holding the Puppy files from the process. (An option within that tool). Subsequently I changed the hard disc for an SSD so no longer defrag anything!

This experience leads me to suspect that the Windows 7 automatic defrag process might be a possible culprit. By default it is set up as a scheduled weekly task for 01am. If your PC is switched off when you retire it will silently kick in when the system is next powered up and reasonably idle. I don’t have Windows 7 but understand that there is no option to exclude particular directories from the MS defrag process.

This may or may not be a common factor. If anyone agrees they can simply disable it before creating a save-file and instead use AUSLOGICS to defrag with suitable exclusions. It is also possible that an ext4 save file may be more resilient to a defrag than ext2 or ext3._________________Regards ETP
Kennels

Is it worth repeating? This Forum desperately needs a decent index, fully collated database, to retain the enormous wealth of IPR, suggestions, solutions. and comments.
Not only that, I personally recall advising against mixing any Linux with the devil's OS. Just what is the problem? Too many worthless laptops? HD s are cheap as chips. Swap 'em around - I use caddies, but neither IDE nor SATA connectors take more than seconds to detach and re-attach. Use one (old) disc per distro with it's own swap partition. Puppy is a compact distro - a 40Gb drive is overkill, they're so cheap they don't even give them away with cornflakes any longer.
Slacko 's have always worked for me on FULL installs to ext2,3, & sometimes 4. There is no problem, mick has done his work very well. Come in James C, perhaps these guys will listen to you...

Have found a minor bug, probably in Adobe Reader rather than Slacko, but annoying anyway. Running Slacko 5.4-Opera-PAE, using Adobe Reader 9 from the SFS on Smokey01's site. I was attempting front-to-back printing manually, just a single sheet, but the second invocation of the print command crashed Adobe Reader. Doesn't matter if the file>print menu is used or the <cntrl-P> hotkey combo, and it's very repeatable. Any suggestions? This isn't a game-killer by any means, I even got my Fed taxes done & printed, but if there's an easy fix I'd sure like to know about it. Thanks for any help!

EDIT: Out of curiosity I just checked also Presice-5.4.2 (k3.2.29) on NTFS - same problem there...

Indeed, I suspected as much.

So... disregarding the test with slacko-5.3.3 ntfs-3g installed in 5.4.. the common denominators seem to be ext2 and ntfs.

I kind of understand why your "dirty write" hack works, but methinks there is probably a kernel parameter that does the same thing. If so, then this could probably become a "known issue" and documented. That way, there would be an acceptable work around available.

I tested my travel mate, the ZTE MF636 USB modem-on-a-memory-stick, and it works like a charm; the modem is found, attached as ttyUSB2, and upon entering pin and net address, it just works! Fantastic!

One observation: When I attach my USB HD with 4 partitions on it, the CD also spins up, it is obvious that the procedure for recognizing additional attachments act a bit different from what I am used to from my old dpup. Is this correct behaviour?

I have an old nvidia GeForce2 MX-200 card, and the driver that is loaded is noveau. When I try to test if there is a better driver, I get the message that I have to install Slacko first to use that test function, why? I have run other puppys from a live CD/DVD where installation is not necessary for an upgrade test. Does anyone know if the old nv driver actually is better for my graphic card?

Hi Billtoo:
For your info; before I saw your mc .pet, I checked my updated ppm for an mc (can't live without one), and they list mc-4.8.4 in slackware-14.0-official, and also slang-2.2.3 and gpm-1.2.0, a general mouse server, as dependencies.

tallboy_________________True freedom is a live Puppy on a multisession CD/DVD.

With Slacko 5.4 final, my install is frugal to to an 3fs save file on an 2fs formatted partition.
But I got to thinking.
Is it possible that the problem hay be due to a glitch in the periodic save of changes to the slackosave file maybe not being backgrounded.
If in the foreground, would there be a pause/lockup while the slacosave file was updated.
When one shuts down or reboots, a message is shown of all changes already have been saved.

Oh yes, my PC also is a dual-core 4800 with 3 gigs of ram and a 512meg save file and no swap.

Anyway, I think some process is halting all IO other than the process itself showing up as a pause/temporary lockup.

If you are saving to a hard disk, to a defined save file then you are running in PUPMODE=12 and saves are direct, just like running a full install, all writes to the save file are like writes to disk, that is there is no ..

Quote:

periodic save of changes to the slackosave file

.

------------------------------------------------------------

I believe it's a kernel issue that has surfaced since 3.2. It would be interesting to see how pemasu's upup-372 (k3.7.2) performs under the same conditions. Also, he has included the new static binary for ntfs-3g which is included in the initrd.gz and is responsible for mounting NTFS at boot. This may even partially solve the issue, but of course wont have anything to do with ext(n) filesystems.

I was tempted to call lack of swap a common denominator until ally posted swap sizes for the dell and lenovo machines.

I have uploaded an ISO image of slacko-5.4 with the PAE kernel from 5.3.3 in an attempt to investigate the "blank page bug", blank, becuse that's what I've drawn, page, well my readings have lead me to believe it's something to do with it, bug, well.. it's a bug!

There is no bugs fixed or anything, it's straight out of the 5.4 woof tree just with the older kernel, you might want to use it as your daily driver if it works for you, works with intel and nouveau but radeon may be an issue (not tested) because it was compiled before mesa became a necessity in the iso image, ymmv. The idea here is if ally, 8-bit, SFR and whomever else can try this and see if the bug happens, this will once and for all determine if it's the 3.4.17/3.2.33 kernels or a userspace bug.

The yellow sticky notes application xpad-4.0 from Slacko's ppm doesn't work. The notepad come up on the desk as a little grey square without anything else. I found an xpad-4.0.pet in my archives that worked, the pet's size is 78K not installed, but I don't know it's origin.

I have been running a 5.4ff fresh frugal on the lenovo t61 for 26hrs now (same 2 drives/4 partitions installed to ext2

I have installed my normal suite of pets to mimic the previous hanging install and NOTHING!

really don't know what to say, I can't find my original install disc so maybe there was a dodgy burn or perhaps the original file was iffy - I don't know

will keep it running for a couple more days to see if I can recreate the issue

OK typing this I now recall wjy I changed from ext4 to ext2, I normally run a (high) encrypted (encrypya) savefile, this time I didn't, so, will build an encrypted file and see if that causes the problem

It's not looking good near where you live. I hope you and family are all right. Take care, my prayers are with you._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

It's not looking good near where you live. I hope you and family are all right. Take care, my prayers are with you.

We are ok here. We only lost a few out door things due to wind/rain, nothing really, flood waters are at least 2m below our level and we are fairly low. Luck the Gold Coast hasn't the huge catchment of Brisbane, they are copping it again there but worst is further north between Gympie and Cairns, not good up there._________________Puppy Linux Blog - contact me for access

It would be interesting to see how pemasu's upup-372 (k3.7.2) performs under the same conditions.

I was curious too, so yesterday I tested these, just for comparison:
Precise-3.7.2-SCSI (k3.7.2) - same issue.
Lupu-520 (k2.6.33.2) - all fine.

BTW, yesterday I also tried the latest ntfs-3g, of course without success...

So, it seems to be pretty clear now where's the source...
_____________

EDIT:

01micko wrote:

I kind of understand why your "dirty write" hack works, but methinks there is probably a kernel parameter that does the same thing. If so, then this could probably become a "known issue" and documented. That way, there would be an acceptable work around available.

Although this hack makes my system usable, but it's far from perfection, to be honest.
It's like that:
1. Without the hack, while saving session (some bigger file or many smaller ones) after ~100 MB HDD hangs and then 'few MB -> ~25 sec hang -> few MB' cycle begins.
2. With the hack the beginning is practically the same, just after the first hang the rest is being saved fluently; but not if at the same time something else is in the middle of saving (i.e. I copy sth from sda2 -> sda3).
In this case usually we're going back to 1 - all write operations go off (I observed it just recently).

Also, if this matters, I have no problems with writing directly to NTFS volumes - many times I happen to copy/move a few large (~5GB) files simultaneously from/to NTFS volumes and despite obvious slowness, all's fine.

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