Re: Wallpaper blend-paper
Posted: Sun 08 Mar 2009, 01:42
.
READ-ONLY Archive
https://oldforum.puppylinux.com/
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.
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.
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.
>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.
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.
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
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.
Well it doesn't tell ME anything, because I'm not that good , but I'm sure hoping it will speak volumes to Dougal, Patriot, ttuuxxx or one of the other devs quietly working away in the background! Thanks for trialling, dogone.dogone wrote:SIGKILL (via Htop or kill -9) appears required to squash cupsd post runaway. SIGTERM doesn't cut it. Does this tell us anything?
Agreed. I think I remember patching the wireless drivers early in the Alpha cycle for 4.2, and I think it's that patch that is masking the earlier (working) driver set. That's why deleting that directory, or renaming it, works; it takes the driver set back to the inbuilt ones from the kernel.jabu2 wrote:can I just mention again that this problem was not a problem with 4.1.2 (confirmed by others) That version recognised wireless interface and ipw220 drivers loaded every time - and works.
so seems to me not likely to be a kernel or fundamental problem?
Help is always welcome, jabu2. The file differences reported relate to the updated driver set vs the original set. It gave me the clue as to why the problem existed but not how to correct it without reverting to the earlier driver set. I'm hoping tempestuous will have a solution. If he doesn't then I'll simply roll back to the 4.12 driver set and leave it there.jabu2 wrote: - minnesota detected file differences in 4.2 rc1 from 4.1.2 and gave samples (back on p4 of rc1 thread)
I am not knowledgeable enough to know if he/she was onto something, but if correct this seems like a short cut to a soution.....?
trying to help. ATVB (all the very best)
I think that's battery meter not in use (you're using desktop)ttuuxxx wrote:also beside the time on the taskbar theres a extra "space" thats using the "space" from the clock, which I don't think I have a space icone being used before the numbers, and if you switch to the 'Citrus' theme you'll see a black box, any ideas? Oh is this one for my new list of things to do ?
ttuuxxx
Beats me! I haven't changed either the PuppyPin or the globicons files for ages, so it's a video mode detection thing, I think. Something in one of Barry's scripts is picking up the icon locations and putting them over that side when it detects a particular resolution. I think I even read it in one of his scripts when I was looking for why Xlock starts top right when I wanted it bottom right.ttuuxxx wrote:- a whole row of icons was moved in icewm to where the pwidgets sits and then gets trashed by pwidgets, That never happened before? Why now?
I definitely used, and didn't ignore, your xdg menu template as supplied BUT I modified both the jwm and icewm templates to use refresh24 and shutdown24 and then copied the Deep Thought versions of those files to the /usr/local/lib/X11/pixmaps directory so the first level menu would be consistent from top to bottom. That choice was also made to fit with the icon naming rules being developed for desktop/menu icon themes so that themes will switch properly. No slight intended.ttuuxxx wrote:The xdg menu that I supplied with the last icewm package I provided wasn't used or was ignored, I had changed
prog "Shutdown" shutdown24 /usr/bin/shutdown
to
prog "Shutdown" exit24.png /usr/bin/shutdown
that is a way better look to the icons and matches the Refresh Menus icon perfectly.
I definitely didn't change that one! Your new absvolume and launch tray icons are there so why the Seamonkey icon didn't land I've no idea. The menu is still picking up the old 16x Seamonkey icon from /usr/local/lib/X11/mini-icons which is why the uglier icon is in the menu. I'll go back and have a look to see why the new icon didn't come across.ttuuxxx wrote:Also the new Seamonkey icon wasn't used, That took hours to improve and its actually3/4 smaller than the default icon.