Page 10 of 15

Posted: Sat 26 Jan 2013, 17:47
by James C
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.

NTFS issue

Posted: Sat 26 Jan 2013, 19:20
by ETP
01micko

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.

Posted: Sat 26 Jan 2013, 20:11
by Sage
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...

Posted: Sat 26 Jan 2013, 20:15
by don570
01micko wrote:Please add what I have missed. My eyes can't be everywhere.
Don't forget to compile mhwaveedit correctly.
http://www.murga-linux.com/puppy/viewtopic.php?t=82367
... and use version 1.4.21 rather than 1.4.22 which is buggy!

________________________________________________________

Posted: Sun 27 Jan 2013, 00:35
by kevin bowers
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!

Re: HDD deadlock, hangs, etc...

Posted: Sun 27 Jan 2013, 00:39
by 01micko
SFR wrote: 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.

We'll see...

Posted: Sun 27 Jan 2013, 01:15
by tallboy
Hi 01micko, a couple of remarks:

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

Posted: Sun 27 Jan 2013, 04:24
by 8-bit
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.

And a periodic updating of the save file could be a possibility.

Posted: Sun 27 Jan 2013, 05:23
by 01micko
8-bit

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

------------------------------------------------------------
Testers Wanted

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!

ISO and md5 <-- http://www.smokey01.com/01micko/slacko/ ... st-5.4.00/

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.

Thanks!

Posted: Sun 27 Jan 2013, 07:47
by tallboy
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.

EDIT: The xpad-4.0.pet may be iguleder's from the Puppy Squeeze 009 project. See the link in http://www.murga-linux.com/puppy/viewtopic.php?t=65343 xpad (sticky notes) (Solved)

tallboy

Posted: Mon 28 Jan 2013, 04:04
by disciple
01micko wrote:... real testing begins when you release ... :lol: (@ disciple, can you add that to your "quotes" thread?)
Dude - can't you add it yourself? Oh, I guess some people don't like quoting themselves :)

Posted: Mon 28 Jan 2013, 09:23
by ally
hey micko

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

report back soon

:)

Posted: Mon 28 Jan 2013, 09:29
by jamesbond
Mick,

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

Posted: Mon 28 Jan 2013, 09:47
by 01micko
jamesbond wrote:Mick,

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.

Posted: Mon 28 Jan 2013, 11:14
by SFR
01micko wrote:Testers Wanted
Ok, same conditions as before.
Slacko-5.4.00 (k3.1.10):
- slackosave.2fs on NTFS - [ ok ]
- slackosave.3fs on NTFS - [ ok ]

EDIT: slackosave.2fs on NTFS (real enviroment) - [ ok ]
01micko wrote: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).

So my full workaround is: PUPMODE=13 + echo 1 > dirty... + never write anything else while saving the session.

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.

BTW, IIRC I tried also 'echo 5 > ...dirty_ratio' and/or 'echo 300 > ...dirty_expire_centisecs', but everything returned to point 1.
____________

Just to re-confirm my older tests:
(Same conditions, but pmedia=atahd & cat /dev/zero > /initrd/pup_rw/root/bigfileX)
Slacko-5.4-PAE, slackosave.2fs on NTFS - [ fail ]
Slacko-5.4.00, slackosave.2fs on NTFS - [ ok ]

Thanks & Greetings!

Slacko-5.4 feedback and bug reports

Posted: Mon 28 Jan 2013, 13:24
by Billtoo
I compiled and tested vlc-2.0.5 in Slacko-5.4, it works fine with the
intel video driver, should work with ati but it may need the
proprietary nvidia driver for nvidia graphics cards.I haven't tested
it with the nouveau driver so it may work on nvidia cards that use that
driver.
Vlc needs qt-4.8.2 to be installed and it's available for download in
the puppy package manager.

Here's the download link for vlc-2.0.5

http://www.datafilehost.com/download-965dfe10.html

Posted: Mon 28 Jan 2013, 18:40
by tallboy
Hi 01micko.
I saved to the live multisession CD by following the PowerOff procedure from the menu, and that worked as normal. Surprise at the next boot, when the 'Save' icon suddenly appeared above the middle on the screen!
I would have liked to see a 'save-to-some-live-media' dialog, without having to use PowerOff, as a menu item in future releases.

I also found out the hard way, that adding the rox-filer update pet, and then saving to CD, plays havoc with downloads and settings in earlier saves, at next boot. The 'Save' icon disappeared again. So as a tip for others, the update should perhaps be added to an unmodified .iso, to avoid extra work.
In an earlier post in this thread, you wrote:Some reading
I took a look at atop in that link, and it seemed like an interesting tool. Could it be used for diagnosing Slacko problems, specifically the 'freeze' problem, which I have experienced first hand myself?

tallboy

Posted: Mon 28 Jan 2013, 19:34
by tallboy
Next release wish: I miss having a visible 'bullet' indicating that for example an .iso or an .sfs is mounted, like I have had in earlier puppys. It seems that the icon with a bullet that appear when a drive is mounted, is limited to those drives. ROX?

I also miss the mtpaint-based screen capture application in the tray in my dpup484/5, that let you drag a capture to size. Simple and quick.

I installed the jwm-661-plus.pet and jwmconfig2-130125.pet. The mouse cursor now changes it's shape when it is moved over the window border buttons, I hope that effect will be a setup choice and not default, in the stable versions soon to come. To me it feels confusing when the eyes are drawn to that movement, instead of just clicking when the cursor arrow is over a button.
When clicking the clock at the right side of the bottom tray to see the calendar, the calendar places itself so low behind the tray, that the close button is unreachable. Why not let the calendar close itself when the cursor moves away, like it did earlier? Unnessesary clicks are wasting time and destroying arms.
Besides, PupClockSet for setting the clock's format is now a module that have to be downloaded separately, it is not listed in the ppm.

tallboy

Posted: Tue 29 Jan 2013, 09:38
by ally
hey micko

noticed the first hang since running 5.4 again, maybe a coincidence but the partview icon was missing from the taskbar, took about 3-4 minutes from clicking the whitespace to the data displaying, when clicking on drive icons similar time elapsed

one other item to mention, not sure if it's a bug or not but have to click twice on desktop icon to get to clear desktop screen

I have process manager running in pwidgets and only high cpu load shows firefox (11 tabs open 18% load)

repeated attempts to open drives has the same hanging duration

also noticed that /var/log/messages date is one day forward (ie 30 jan)?

access to other apps and 'home' ok so it appears to be isolated to mounting somehow, again, sorry don't know how to gather data for you

:)

** EDIT running partview from the terminal outputs:

"EXIT=exit on timeout"

*** EDIT - drive mounting not resolved by restartx, drive icons not visible after either, would not shutdown correctly and required a power-button hold down to turn-off system

Posted: Tue 29 Jan 2013, 13:36
by npierce
ally wrote:also noticed that /var/log/messages date is one day forward (ie 30 jan)?
This happens because, when Puppy starts, the local time is temporarily set to a fictitious time zone 23 hours ahead of UTC, and is not corrected until after syslogd is started. So syslogd sends us messages from the future. :)

You may be able bring syslogd back from its time warp by modifying one line in /etc/rc.d/rc.sysinit (and rebooting):

Code: Select all

#unset TZ #100319 busybox hwclock gives priority to this (rather than /etc/localtime) and 'init' has set it wrong.
Remove the hash character at the beginning of the line so that it reads:

Code: Select all

unset TZ #100319 busybox hwclock gives priority to this (rather than /etc/localtime) and 'init' has set it wrong.
Although I don't see any potential problem, I have not tried this, so this advice comes with no warranty, and I don't know if there might be any other side-effects.