Oh, too cruel!!! Using a word like that on the very first page of a Bugs & Fixes thread is just downright MEAN!01micko wrote:****CRASH****`f00 wrote:
(definition 13) part of a wave: the tunnel formed when a large rolling wave prepares to break (snip)
Puppy 4.2 RC2 Deep Thought - Bugs & Fixes
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Yes, you mentioned about the wallpaper setter version in RC1 before and when I quoted the version I was using you said "forget it"? Am I using the latest or is my version-0.5.1 an older version? If you have a later one, then I'd be happy to include it. The clashes appear to result from two applications looking in different locations for the background. Pwidgets uses /root/.config/wallpaper/bg_img while Rox Filer uses /root/Choices/ROX-background.jpg - I noticed the conflict after uploading RC2. Can this be standardised for Final?zigbert wrote:- The wallpaper setter is not the latest and conflicts with Pwidgets.
- The earth background could have been replaced with one looking ok also on a widescreen.
I'd be happy to modify the Aurora-Australis wallpaper to suit widescreen as everything other than the earth itself is simply solid black fill - that makes it an easy thing to do without increasing the size of the image too much.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Yes, I saw that in testing on my machine. I just assumed it was pointing to a location on the web that wasn't available while I wasn't connected. I've downloaded the update for inclusion. Thanks, Ed.Lobster wrote:one of the images was not linked on the release notes htm
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
I have PM'd tempestuous to look into the inbuilt wireless driver issues. It would help if you PM'd him with your Dmesg output, too! In the meantime using the potential workaround from the RC1 thread is worth considering.twointo1 wrote:Puppy 4.2rc2 has a problem with the intel ipw2200 wireless pci card - it will not recognize it. Md5sum is right. Dmesg shows kernel tainted.
Works great in 4.1.2
The kernel I'm using is the same one as 4.12, so there shouldn't be any difference for included drivers, but clearly there is. Your assistance in finding the source of the problem is appreciated. Thanks.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Did you boot clean with pfix=ram? The fixmenus script has been updated to improve this issue, and works fine in a clean install, so I don't know from where your issues may be arising.pa_mcclamrock wrote:PETget package manager
Updating menu, please wait . . . and wait . . . and wait . . . and wait . . . and wait . . . . . . . . . . . . . . Something really needs to be done about this before the final release!
I'm sure ttuuxxx is following this thread and will look into your suggestion. I'm glad it works, though.pa_mcclamrock wrote:Printing does work, as expected. Also, you don't have to see a purple dialog window any more before the CUPS window opens up. Good. But . . . it's still not obvious how to set a printer as the default, and it should be. This is especially important with TextMaker (which I use) and any other app that wants to use the default printer. Printing did not work with TextMaker until I remembered how to set my printer as the default.
Back up globicons as well. It contains the definitions for the icons used by PuppyPin. I don't know how ROX uses them internally, but there is some correlation between them and how the icons appear on the pinboard.pa_mcclamrock wrote:I saved my PuppyPin file and copied it to /root/Choices/ROX-Filer before creating a new pup_save file. After rebooting, sure enough, the desktop icons I wanted were where I wanted them--but some I didn't want were there too, like "calc" and "chat." Can this be prevented from happening?
Wish I knew, David. I've not seen that before EVER! Seems you may have managed to copy a corrupt version of ROX into your pup_save file somehow and it's sitting in a layer above the inbuilt original. Delete your pup_save file and try again from a clean install.pa_mcclamrock wrote:And now for something really, really strange. When I booted puppy pfix=ram, ROX-filer was there all right. But after I created pup_save and rebooted . . . ROX-Filer was missing from the Filesystem menu, it didn't appear when I clicked drive icons on the desktop, and here's what I got when I tried to run it from the command line:
What's going on here?!Code: Select all
# rox & bash: rox: command not found
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Re: Wallpaper blend-paper
Try opening the wallpaper in mtPaint and indexing it. When you attempt to save you'll be asked to change to RGB for the PNG format. That should create a new copy of the wallpaper in PNG format, overwriting and hopefully bypassing any corruption in the original. Then try setting it again to see if the problem has been resolved.MinHundHettePerro wrote:Tried all the included wallpapers as well as my own standard background. All worked as expected, except that blend-paper almost completely hangs my (once modern) computer (550 MHz, 192 Mb RAM), on which Puppy normally runs lightning fast. See CPU and RAM usage in the attached images, blend-paper completely uses up my computers resources. Seeing Zigbert's comments above, I checked if any conflict with Pwidgets was causing this by disabling Pwidgets; still the same stalling result, so Pwidgets seems not to be the culprit. Also tried in IceWM; same results. All the other new mini-wallpapers work nicely though. One would have thought a 300x1 wallpaper would leave a small foot-print, but, alas.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Yeah, you are right. I edited (you best edit yours too.)WhoDo wrote: (..snip) Oh, too cruel!!! Using a word like that on the very first page of a Bugs & Fixes thread is just downright MEAN!
Puppy Linux Blog - contact me for access
CUPS setup -> 100% CPU
After booting RC2 using pfix=ram and successfully bringing up the network, I proceeded to configure my network printer.
- start Htop (for this report)
- Menu/Setup/CUPS Printer Wizard
- CUPS page appears
- Click "Add Printer"
- Username/password dialog appears
Htop reports immediate jump to 100% CPU and indicates CUPS is pulling ~93%
- close CUPS dialog
- no change in CPU utilization
- use Htop to kill CUPS process
- CPU utilization drops to <10%
- attempt to re-run CUPS wizard
- "Page Load Error" appears indicating "Failed to connect..."
The above is repeatable.
- start Htop (for this report)
- Menu/Setup/CUPS Printer Wizard
- CUPS page appears
- Click "Add Printer"
- Username/password dialog appears
Htop reports immediate jump to 100% CPU and indicates CUPS is pulling ~93%
- close CUPS dialog
- no change in CPU utilization
- use Htop to kill CUPS process
- CPU utilization drops to <10%
- attempt to re-run CUPS wizard
- "Page Load Error" appears indicating "Failed to connect..."
The above is repeatable.
- pa_mcclamrock
- Posts: 695
- Joined: Fri 03 Jun 2005, 23:13
- Location: Fort Wayne, Indiana, USA
Yes. I don't know why the long waits happened. Then, as you suggested, I got rid of my first RC2 pup_save and booted pfix=ram again. This time--guess what--no long waits. I don't know what made the difference, either!WhoDo wrote:Did you boot clean with pfix=ram?pa_mcclamrock wrote:PETget package manager
Updating menu, please wait . . . and wait . . . and wait . . . and wait . . . and wait . . . . . . . . . . . . . . [ . . . ]
I think not, for at least three reasons: (1) I booted pfix=ram so there was nowhere for a corrupt file to come from; (2) my previous pup_save file didn't contain a corrupt version of ROX; (3) I looked in /usr/local/bin and there was no ROX listed at all; there was neither a corrupt nor an incorrupt version.Wish I knew, David. I've not seen that before EVER! Seems you may have managed to copy a corrupt version of ROX into your pup_save file somehow and it's sitting in a layer above the inbuilt original.pa_mcclamrock wrote:And now for something really, really strange. When I booted puppy pfix=ram, ROX-filer was there all right. But after I created pup_save and rebooted . . . ROX-Filer was missing from the Filesystem menu, it didn't appear when I clicked drive icons on the desktop, and here's what I got when I tried to run it from the command line:
What's going on here?!Code: Select all
# rox & bash: rox: command not found
Done. No problem now. But I wish I knew what caused the problem before, and whether any other users are going to have it!Delete your pup_save file and try again from a clean install.
It's stupid to use inferior software for ideological reasons.
--Linus Torvalds
--Linus Torvalds
Nah! Just funnin' with ya, mate! I got my sense of humour back with the RC2 upload.01micko wrote:Yeah, you are right. I edited (you best edit yours too.)WhoDo wrote: (..snip) Oh, too cruel!!! Using a word like that on the very first page of a Bugs & Fixes thread is just downright MEAN!
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
- MinHundHettePerro
- Posts: 852
- Joined: Thu 05 Feb 2009, 22:22
- Location: SE
Re: Wallpaper blend-paper
.
Last edited by MinHundHettePerro on Sat 16 May 2009, 11:44, edited 1 time in total.
[color=green]Celeron 2.8 GHz, 1 GB, i82845, many ptns, modes 12, 13
Dual Xeon 3.2 GHz, 1 GB, nvidia quadro nvs 285[/color]
Slackos & 214X, ... and Q6xx
[color=darkred]Nämen, vaf....[/color] [color=green]ln -s /dev/null MHHP[/color]
Dual Xeon 3.2 GHz, 1 GB, nvidia quadro nvs 285[/color]
Slackos & 214X, ... and Q6xx
[color=darkred]Nämen, vaf....[/color] [color=green]ln -s /dev/null MHHP[/color]
When you first run ROX is called from the pup_420.sfs file into RAM. If it crashes there, or corrupts, or whatever, it is possible that the system will think you deleted it and cover the original with a .wh file at the higher level. You won't see ROX (not even the original) and the system will believe it doesn't exist. Those are the joys of a layered file system. The good news is that the original, uncorrupted ROX binary is still there and appears again when you delete the pup_save file along with the .wh mask file that prevents it from being seen.pa_mcclamrock wrote:I think not, for at least three reasons: (1) I booted pfix=ram so there was nowhere for a corrupt file to come from; (2) my previous pup_save file didn't contain a corrupt version of ROX; (3) I looked in /usr/local/bin and there was no ROX listed at all; there was neither a corrupt nor an incorrupt version.WhoDo wrote:Wish I knew, David. I've not seen that before EVER! Seems you may have managed to copy a corrupt version of ROX into your pup_save file somehow and it's sitting in a layer above the inbuilt original.
You could even copy the original back from /initrd/pup_ro2/usr/local/bin but only IF you have another working file manager that will let you do that.
Could be flakey RAM, power transients, etc. It doesn't take much to cause a problem for a mounted squash file system (pup_save IOW) to have a bit or two throw things out. That's why you should always make a clean copy of your working pup_save before doing anything critical.pa_mcclamrock wrote:Done. No problem now. But I wish I knew what caused the problem before, and whether any other users are going to have it!Delete your pup_save file and try again from a clean install.
Hope that helps.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Re: CUPS setup -> 100% CPU
There is evidently a misbehaving cups daemon at work here. I noticed a problem with earlier CUPS installations but haven't had a repeat since. The daemon simply refuses to throttle back after completing some operation or other.dogone wrote:Htop reports immediate jump to 100% CPU and indicates CUPS is pulling ~93%
- close CUPS dialog
- no change in CPU utilization
- use Htop to kill CUPS process
- CPU utilization drops to <10%
- attempt to re-run CUPS wizard
- "Page Load Error" appears indicating "Failed to connect..."
The above is repeatable.
Next time instead of killing the process, try manually stopping CUPS and then restarting it again from the CLI.
Hope that helps.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Re: Wallpaper blend-paper
>15 years with the same backdrop!?!? That's gotta be some sort of record, MHHP!MinHundHettePerro wrote:Ain't going to pursue it further, as I'm more than happy (and familiar) with my backdrop of >15 years. Just reported an observation I made, I will not, personally, use any of the supplied wallpapers.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
RC2
On Tower got CUPS to find HP1220C on LPT1 which it did not work on RC1. Still works okay with USB on both machines.
On HP Pavilion zv6100 Laptop could not get to the internet at all on eth0, no problem with 3.x and 4.1.x. On RC1 it took several reboots. Driver is same 8139too.
Does not see wirless B43 at all on Laptop. 3.x and 4.1.x do and work most of the time.
On HP Pavilion zv6100 Laptop could not get to the internet at all on eth0, no problem with 3.x and 4.1.x. On RC1 it took several reboots. Driver is same 8139too.
Does not see wirless B43 at all on Laptop. 3.x and 4.1.x do and work most of the time.
- MinHundHettePerro
- Posts: 852
- Joined: Thu 05 Feb 2009, 22:22
- Location: SE
Re: Wallpaper blend-paper
.
Last edited by MinHundHettePerro on Sat 16 May 2009, 11:44, edited 1 time in total.
Re: RC2
Can't say what the problem might be with the 8139too driver for normal ethernet.NathanO wrote:On Tower got CUPS to find HP1220C on LPT1 which it did not work on RC1. Still works okay with USB on both machines.
On HP Pavilion zv6100 Laptop could not get to the internet at all on eth0, no problem with 3.x and 4.1.x. On RC1 it took several reboots. Driver is same 8139too.
Does not see wirless B43 at all on Laptop. 3.x and 4.1.x do and work most of the time.
As for wireless, try renaming /lib/modules/2.6.25.16/kernel/drivers/net/wireless/r8180 folder to !!!r8180, save and reboot. Both brymway and 01micko have reported success with similar workarounds.
Hope that helps
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
ipw2200 wireless non recognition
posted at end of rc1 thread - it seems this is not yet completely fixed in rc2, so posted again here.
wireless ipw 2200 recognition problem reported by several (minnesota, brymway etc):
o1mick has now given a solution
I went into /lib/modules/2.6.25.16/kernel/drivers/net/wireless and renamed the r8180 folder--!!!r8180, saved and rebooted and my wireless now works.
Apparently this works - being confirmed by one other so far
But for new or old users it is not a full fix yet.
can we please fix it for rc3 so that no file hacking is required?
Many thanks in anticipation of wirelessly testing rc3
PS Nice to hear all the young 'uns life stories - haven't needed the TV all week.
wireless ipw 2200 recognition problem reported by several (minnesota, brymway etc):
o1mick has now given a solution
I went into /lib/modules/2.6.25.16/kernel/drivers/net/wireless and renamed the r8180 folder--!!!r8180, saved and rebooted and my wireless now works.
Apparently this works - being confirmed by one other so far
But for new or old users it is not a full fix yet.
can we please fix it for rc3 so that no file hacking is required?
Many thanks in anticipation of wirelessly testing rc3
PS Nice to hear all the young 'uns life stories - haven't needed the TV all week.
Re: ipw2200 wireless non recognition
The fix was only evident AFTER the RC2 release was uploaded or it would have been patched before I uploaded it. ITM I have asked tempestuous to look at the wireless problems for a more permanent solution, if he has the time and the inclination. After all we are all VOLUNTEERS!jabu2 wrote:can we please fix it for rc3 so that no file hacking is required?
Many thanks in anticipation of wirelessly testing rc3
It would be nice if we had Warren Woodford's resources (Ubuntu founder) to throw at these issues, but I believe we still manage to produce a better, faster, more efficient OS with just a little personal commitment and patience.
Cheers, from one of "the young 'uns".
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Re: CUPS setup -> 100% CPU
SIGKILL (via Htop or kill -9) appears required to squash cupsd post runaway. SIGTERM doesn't cut it. Does this tell us anything?WhoDo wrote:There is evidently a misbehaving cups daemon at work here. I noticed a problem with earlier CUPS installations but haven't had a repeat since. The daemon simply refuses to throttle back after completing some operation or other.dogone wrote:Htop reports immediate jump to 100% CPU and indicates CUPS is pulling ~93%
- close CUPS dialog
- no change in CPU utilization
- use Htop to kill CUPS process
- CPU utilization drops to <10%
- attempt to re-run CUPS wizard
- "Page Load Error" appears indicating "Failed to connect..."
The above is repeatable.
Next time instead of killing the process, try manually stopping CUPS and then restarting it again from the CLI.
Hope that helps.