Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 19 Dec 2014, 19:40
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 59 of 190 [2847 Posts]   Goto page: Previous 1, 2, 3, ..., 57, 58, 59, 60, 61, ..., 188, 189, 190 Next
Author Message
nooby

Joined: 29 Jun 2008
Posts: 10557
Location: SwedenEurope

PostPosted: Wed 21 Dec 2011, 12:39    Post subject:  

Quote:
shinobar wrote:
#Avoid was messing uo with save interval=0 under PUPMODE=13


oh I want to learn more about that one.
I trust that I use it somewhere and do have set it to 0.
Too bad. I did not know it was problematic.

Shinobar if you have time or when you do feel for it.
I would not mind reading more about that problem.
Maybe it need it's own thread though.

_________________
I use Google Search on Puppy Forum
not an ideal solution though
Back to top
View user's profile Send private message 
ETP


Joined: 19 Oct 2010
Posts: 579
Location: UK

PostPosted: Wed 21 Dec 2011, 13:37    Post subject: At last, another patch (6) for sound issues
Subject description: Testing 004 plus patch (6) (Chasing sound phantoms)
 

rerwin

Firstly thanks for your enormous efforts & patches. Your research will no doubt be of benefit to all puppies not just 528.

With regard to your changes to rc.sysinit:
Code:
rm -f /dev/ttyUSB* 2>/dev/null #101210 may have been left there if modem plugged in at shutdown.
rm -f /dev/mixer 2>/dev/null #110113 make sure removed, see test in /etc/init.d/10alsa.
rm -f /dev/snd/* #110304 after a reboot, some of these may be wrong.


You may wish to consider expanding it as follows:
Code:
rm -f /dev/ttyUSB* 2>/dev/null #101210 may have been left there if modem plugged in at shutdown.
rm -f /dev/*mixer* 2>/dev/null #110113 make sure removed, see test in /etc/init.d/10alsa.
rm -f /dev/snd/* #110304 after a reboot, some of these may be wrong.
rm -f /dev/*adsp* 2>/dev/null
rm -f /dev/*audio* 2>/dev/null
rm -f /dev/*dsp* 2>/dev/null
rm -f /dev/*sequencer* 2>/dev/null
rm -f /dev/snd/*
rm -f /dev/snd/by-path/* #added for alsa v1.0.24

This has the benefit of also covering /dev/snd/by-path and also takes out all instances of mixer and sequencer eg mixer, mixer01 etc. Multiple instances of both sequencer and mixer will correctly exist where there are multiple devices.

Attached as image-1 below is a screenshot of a patched up fresh install of 004.
What concerns me, since I first saw the behaviour in my post about 003 on 17/12/11, is the time stamps. (Which I believe have nothing to do with your patches)

These nodes were all in fact created over 5 second period at 9:52 today – 21 Dec.
The bottom 7 however, which were created at the beginning of this period show a stamp 23 hrs earlier. The only explanation for this is that the HWCLOCK command (plus switches) was issued during this 5 second period.
Given that Alsa is a means of playing audio it has to keep accurate time and may be uniquely sensitive to these incorrect time stamps. Things could well go awry when DST turns on or off which could result in times of + 1 hour or + 25 hrs. Alsa could well disregard future times/dates and sound would then be lost.
Depending on the time-zone DST can cut in between MARCH to MAY inclusive and out between SEP to NOV inclusive.
In the attached file is a shot of wuxiandianzi’s 528 k3.1.0 which was based on the original 528 and it simply does not exhibit this behaviour. All of the date and time stamps over a 6 second period are correct.
In conclusion there has been some change to time stamping behaviour since the original 528. As it stands now it is definitely wrong and if what I suspect is correct a possible cause of sudden sound loss in Alsa. Perhaps a puppy time expert could investigate?
528_k3.1.0.tar.gz
Description 
gz

 Download 
Filename  528_k3.1.0.tar.gz 
Filesize  155.67 KB 
Downloaded  138 Time(s) 
image-1.png
 Description   
 Filesize   81.65 KB
 Viewed   650 Time(s)

image-1.png


_________________
Regards ETP
Accessibility Pups: -- Magoo -- The Pup With No Name -- MouseCam -- Obedient
Back to top
View user's profile Send private message 
nooby

Joined: 29 Jun 2008
Posts: 10557
Location: SwedenEurope

PostPosted: Wed 21 Dec 2011, 14:02    Post subject:  

others do have a better memory than I have
but have we not got recommendation to use
RTC and not local time due to this problem with
files suddenly getting wrong time stamp?

Sadly I don't remember who gave the advice and where
but I hope somebody else remember the details.

_________________
I use Google Search on Puppy Forum
not an ideal solution though
Back to top
View user's profile Send private message 
shinobar


Joined: 28 May 2009
Posts: 2631
Location: Japan

PostPosted: Wed 21 Dec 2011, 21:52    Post subject: messing up with save interval=0 under PUPMODE=13  

shinobar wrote:
#Avoid was messing up with save interval=0 under PUPMODE=13

See the report at last posts on the pupsaveconfig and no save:
http://www.murga-linux.com/puppy/viewtopic.php?t=60678&start=106
The problem occurs because the PPM saves the files not to the RAM but directly to the save layer for the flash install.

_________________
Google Chrome portable
Downloads for Puppy Linux http://shino.pos.to/linux/downloads.html
Back to top
View user's profile Send private message Visit poster's website 
Sylvander

Joined: 15 Dec 2008
Posts: 3551
Location: West Lothian, Scotland, UK

PostPosted: Thu 22 Dec 2011, 03:58    Post subject:  

@rerwin

1. I've applied/installed your patch-6, and all seems well.
But...

2. I'm no longer offered the option at shut-down = "Save the session? Yes/No".
So...

3. I'm about to change some code within file /etc/rc.d/rc.shutdown...
As per the instructions given in this post....
But I think You've probably included new code, and it may no longer be OK to make this change, so I thought I'd check back with you.

4. If I did proceed, I'd be changing this:
Code:
  #the above are in unionfs at /.
  update_save_layer_func $SAVEFILE \(${SAVEPART}\) #111208
  ;;

To this:
Code:
#the above are in unionfs at /.
dialog --yesno "Save this session?" 0 0 >/dev/console
if [ $? -eq 0 ]; then
echo "Saving session to $SAVEFILE (${SAVEPART})..." >/dev/console
/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
fi
;;
Back to top
View user's profile Send private message 
aarf

Joined: 30 Aug 2007
Posts: 3620
Location: around the bend

PostPosted: Thu 22 Dec 2011, 12:51    Post subject:  

luci-528.iso___lupu-528.004.iso.delta 13MB
luci-001.iso___lupu-528.004.iso.delta 35MB
luci-529.iso___lupu-528.004.iso.delta 30 MB

Last edited by aarf on Thu 22 Dec 2011, 14:09; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website 
rerwin


Joined: 24 Aug 2005
Posts: 1550
Location: Maine, USA

PostPosted: Thu 22 Dec 2011, 13:02    Post subject:  

Sylvander,
Thanks for your feedback. I think I have addressed the shutdown-issue already.
rerwin wrote:
- Allows user to choose to be asked whether to save during shutdown, by setting "ask" in the /etc/shutdown_save_mode file.
Apparently you missed this "fine print" in my patch announcement. It is already set up, so that you need only uncomment the line containing "#ask". I think that is safer than risking a typo while modifying internal puppy code. My other comment:
rerwin wrote:
In response to playdayz desire for a "user-proof" puppy, but to avoid requiring user modification of a puppy script, I do not want to disrupt shutdown with a question that most users could not answer knowledgeably. A user comfortable with changing /etc/eventmanager for the automatic interval is also capable of editing /etc/shutdown_save_mode.
I think you qualify.


shinobar,
Thanks for pointing me to that background on your install.sh modification. I believe the ability to shut down a flash drive session without saving goes beyond the official design of puppy. It seems to be used as an "undo" function, which could also be accomplished by uninstalling the installed package, then saving (first time, though). Other than package installation, choosing to not save seems OK to do. And keeping your alternative available for user installation seems appropriate. But there is another way to avoid saving....

As part of my mods to remasterpup, I provide a way to make a tailored CD/iso when the remasterer chooses to copy the entire /root and /etc directories to the new puppy. When that kind of CD is made, it by default skips saving on shutdown. To restore saving at shutdown, there is a flag file that (as I recall) would be deleted to override the default. The idea with that is to never save to anything. Again, that scenario is available to a knowledgeable/confident user ready to copy those directories for the remaster.

I am open to advice on improving the user experience with those "nerd-only" options, but am now keeping them "low profile."


EPC,
I have started a discussion with you by PM about the additional /dev removals at boot-up. Bottom line, though, is that Barry needs to be convinced they are necessary. So we need to make the case.
Richard
Back to top
View user's profile Send private message 
Sylvander

Joined: 15 Dec 2008
Posts: 3551
Location: West Lothian, Scotland, UK

PostPosted: Thu 22 Dec 2011, 13:28    Post subject:  

1. "you need only uncomment the line containing "#ask". I think that is safer than risking a typo while modifying internal puppy code"
(a) Oops, sorry about that. Embarassed
What a great feature! How easy is that?
Mind you, I bet a total beginner wouldn't know it was there, or how to do it, unless told.
Obviously some of what you said went straight over my head. Confused
I believe in something I call "Mind Blindness".
The eyes see...
The words are read...
But the full significance and meaning are simply NOT comprehended.

(b) Job now done. Very Happy
Now to see if it does what I expect it should.
Back to top
View user's profile Send private message 
ETP


Joined: 19 Oct 2010
Posts: 579
Location: UK

PostPosted: Thu 22 Dec 2011, 13:50    Post subject:  

rerwin

Reply in the post!

_________________
Regards ETP
Accessibility Pups: -- Magoo -- The Pup With No Name -- MouseCam -- Obedient
Back to top
View user's profile Send private message 
Sylvander

Joined: 15 Dec 2008
Posts: 3551
Location: West Lothian, Scotland, UK

PostPosted: Thu 22 Dec 2011, 16:29    Post subject:  

rewin

1. "Package installations are prevented if an uninstallation has taken place in the same session before a save has been done"
Does this mean...
In relation to things happening within the same session:
(a) If an uninstallation has been completed, followed by clicking the "Save" icon on the desktop...
Then a package installation to follow would be prevented.
The user would need to reboot to a new session before attempting an installation.
OR...
(b) An attempt to install a package...
After an uninstallation...
But BEFORE that uninstallation has been saved...
Will be prevented.
The user would need to 1st save the uninstallation, and only then re-attempt the install.

2. "because the uninstallation may override the installation"
(a) I have no idea why an uninstallation would perhaps override an installation.
Hence, I fail to comprehend the significance.

3. "Uninstallations are prevented if a "save" or installation have been done"
(a) Shouldn't that say:
"Uninstallations are prevented if an installation and/or save have been done"...
This seems to me to be saying that whenever one or other or both [installation/save] have been completed [or even just started but failed to complete?]...
Then a subsequent uninstallation would be prevented.

4. "because the uninstall might corrupt an installation or fail to survive a reboot"
(a) Is this the reason you made the arrangement to prevent an uninstall under the conditions in 3 above?
So as to eliminate this risk; create certainty of success?

5. "The conflicting situations will require a reboot to trigger saving to flash drive between installations and uninstallations"
(a) OUCH! So only 1 install OR uninstall [not both, or multiples of both?] in any 1 session?
And yet, would not it be good enough to do a manual save DURING THE SESSION, and between the two [after the one, and before the other].

6. "Ideally, you should be able to uninstall, then save, then install, all in the same session. But this is not possible due to a problem with the package installer"
(a) A restatement, using other words, of the situation explained in 5 above.
This seems to answer my question in 5.

7. "It must be completely terminated in order for a "save" to be performed. But the installer/uninstaller does not terminate completely, leaving its main process executing, even though its dialog window is closed by the "Exit package manager" button"
(a) And this is the reason for the problem explained in both 5 & 6, as to why certain actions must be prevented, as explained above.

8. "To clarify how the conflict prevention works, it merely instructs the user to reboot if a conflict among packages is possible"
(a) Who decides [and WHEN], that a conflict is possible?
You [during coding?] or the user [at the point he is given the instruction to reboot]?
(b) Perhaps you might have said:
"Where I have previously determined that a conflict might arise when a certain package is being installed/uninstalled...
I have arranged that the code will instruct the user to reboot." [to avoid software corruption].

9. Have I [mis]understood? Confused
Did I get close? Very Happy

10. I'm now offered the choice "to save or not to save" at shutdown/reboot. Very Happy
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1550
Location: Maine, USA

PostPosted: Thu 22 Dec 2011, 19:09    Post subject:  

Sylvander,
You are very close. I know the "explanations" are a little vague, but the details are more than a novice would understand. Here's the deal (which I tried to explain earlier). Say we have a package that updates a puppy component (file):
    - Installing a package in a flash-drive installation (which is what we are talking about here) places the new file in the "save" layer, which is below the "snap" (pup_rw) layer.
    - Uninstalling a package places the original (puppy sfs) version of the component in the "snap" layer.
    - The first time the "save" function is used in a session, it saves everything in the "snap" layer into the "save" layer.
    - Subsequent "saves" copy only the components in the "snap" layer that are newer than the copy in the "save" layer.
So, the following could cause trouble:
    - Uninstalling the components to "snap" layer, then installing them to "save" layer, then doing the first "save" of the session, results in the old versions overwriting the new, thus losing the new package.
    - If the above were done after the first save, the new-package versions of the components would be retained.
    - If you install, then uninstall, then save, the results, as above, will depend on whether the "save" was the first of the session, or not.
The "conflict prevention" logic merely ensures that an uninstall gets saved by the first "save" of the session, and that installations get saved by a subsequent "save" -- but only if both operations are attempted in the same session. If only one of those is done in a session, then the components will exist in only one of the layers, and that's OK.

And you are right about items 5 & 6. It is the package manager (PPM) that interferes with the ideal uninstall-save-install sequence. I originally coded for that sequence (and have it saved, in case we solve the problem), but had to abandon it because I could not figure out how to fix PPM. Expert assistance needed!

Who decides? The logic I coded, not the user.

BTW, "and/or" is unnecessary because "or" is an "inclusive or". Learned that in a "Clear Technical Writing" PI course.

Note that the directions to the user refer to package(s), to mean that multiple packages can be (un)installed as a group. You just cannot mix the two operations without doing a "save" between groups. And you cannot undo the first save, so must reboot to get a new "first save" opportunity for the uninstalls.

One might ask why we don't see more problems of this sort. The exposure is in working with components that are in the main puppy SFS file, because that's where the old versions reside. My guess is that most installations are of components other than puppy files, so that uninstallation only removes the package files, without any replacement. Since my fix packages almost always involve puppy components, they are most subject to the above "conflicts", and thus seem more problem-prone in flash-drive installations than other packages.

Thanks for providing the opening for me explain my reasoning about this. And I am open to word-smithing those messages.
Richard
Back to top
View user's profile Send private message 
l2ulinux


Joined: 25 Jan 2011
Posts: 148
Location: Blountstown, Fl.

PostPosted: Fri 23 Dec 2011, 03:34    Post subject: Lupu 5.2.8
Subject description: .004
 

playdayz wrote:

First, please try 004 in the first message of this thread.

DL and burn, then booted setup was easy and everthing worked witn no problem. At exit saved to file on HD and rebooted and all worked great. Thanks
Back to top
View user's profile Send private message 
rezolt

Joined: 24 Dec 2011
Posts: 7

PostPosted: Sat 24 Dec 2011, 03:14    Post subject:  using Plop boot manager
Subject description: booting puppy usb to an old system
 

Hello everyone just like the rest of you I have problem with the audio system and some minor glitches of our dear puppy from the past. Today I am going to share some simple tips for those who are not aware of Plop boot manager. Before I was using a Pentium 4 1.7Ghz unit but it broke out because I have gambled around with my BIOS. I was so curious how to upgrade it as an experience but wind up having a dead system. Now I am using an older version of my PC which is my old Pentium 3. I encountered a big problem because the memory part was already obsolete and can no longer be found on the market. So I was forced to used Lucid Puppy because of its small size. Now I am using Wary Puppy 5.2.2 which I find to be great even thought I still experiencing some minor glitch like the hang-ups. Now for some tips, if your system cannot boot directly from a usb device you can use Plop boot manager to boot it. The interface was simple and can be learned by a novice. Now to solve the problem of corruption I have formatted my usb thumb drive as ext3 this solves my frequent corruption of thumb drive. There is one thing I cannot solve, the more I use my puppy the more it becomes sluggish specially if I am connected on the web.
Back to top
View user's profile Send private message 
James C


Joined: 26 Mar 2009
Posts: 5970
Location: Kentucky

PostPosted: Sat 24 Dec 2011, 03:47    Post subject:  

James C wrote:
On my last test install http://www.murga-linux.com/puppy/viewtopic.php?p=586162#586162 I forgot to mention that "check drivers" in Quickpet misidentified the Trident video and recommended a Nvidia driver.No problem for me but thought I'd better mention it.


Purely for informational purposes........otherwise all looking good.


VGA compatible controller : Trident Microsystems CyberBlade/i1 (prog-if 00 [VGA controller])
video upgrade.png
 Description   
 Filesize   30.17 KB
 Viewed   2024 Time(s)

video upgrade.png

Back to top
View user's profile Send private message 
Sage

Joined: 04 Oct 2005
Posts: 4833
Location: GB

PostPosted: Sat 24 Dec 2011, 04:39    Post subject:  

rezolt : FUD & BS. PC s don't break unless you throw them out of the window! Time to flash/replace the BIOS and get to grips with the HW. It's shear nonsense to say that parts, incl. memory of any age, aren't available - look on eBay; it's awash with stuff. Machines don't 'slow down' unless you have Winduze present or your ISP has a poor contention ratio. Stop using Intel boxes. Learn to open the case. Hire a six-year-old. Change your ISP.
Some folks might object to my directness, but it's reports like this that put incomers off. It angers me that the capitalist b*st*rds, particularly in one nation, brainwash their young people to believe in magic boxes, preferring to teach them how to open their wallets. The only clever guys in this game are the ones who research solid state sciences and those that write the code, esp. back to assembler and binary levels. Anyone else is entirely capable of building and repairing their own HW - no excuses about lack of time, wife won't let me, electricity is dangerous and all that cr*p.

Before the backlash from across the water, I should again make it clear that I have loads of friends 'over there' and none of them conform to that nation's determination to dumb down its populace. Most correspondents on this Forum do not conform to that norm, either, that's why they are here. All the answers you need are on the InterWeb.

Oh yes - Merry Christmas!
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 59 of 190 [2847 Posts]   Goto page: Previous 1, 2, 3, ..., 57, 58, 59, 60, 61, ..., 188, 189, 190 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1604s ][ Queries: 13 (0.0347s) ][ GZIP on ]