Do you mind editing /usr/sbin/fatdog-xorgwizard.sh and add "-x" to the first line so it looks like "#!/bin/dash -x" and then run xorgwizard from terminal and copy/paste the output? I tried a few scenarios here to make it fail but I can't reproduce it.LateAdopter wrote:I tried xorgwizard but it didn't work. I got one of those annoying message boxes where the answer is NOT OK, but it only has an OK button.
I wonder what I did wrong!
Okay, I'm not really clear on what you're up to, but here is some random non-sequitur comments about something that I *do* knowTed Dog wrote:OK I'll spill the beans on what I strongly expect is the root cause of these unrelated glitches since my hunch is playing out as we test it.
PLEASE if you have a slow machine or a machine with a AMD family chipset. USE
expand base to ram boot switch!
base2ram=expand
and run same software with and without it boot switch. Yes it will be faster, but that is not what I'm pointing out.
the sfs decompression routine can only be run on one core for the format used, and is blocking file related IO, since puppyliux and Fatdog are really ran with hundreds of tiny text scripts, and it can be a nest of tiny text scripts. I suspect the odd root cause is a side effect of a long history that small files load time is tiny, but the opposite is true in our case. the time to load a tiny file is the same as a large file, and the more tiny files needed the worse the effect.
The packing format of SFS files group tiny files together and compress them as a set, but no decompress buffer exists like a read-ahead ext3 at the kernel driver level.
So each tiny file gets unpacked each and everytime time called and all the other tiny text files it was packed with are as well, but that effort is wasted.
One solution I found was to create a standard ext3 block-device file and have that as a single file within a SFS. This way the read-ahead buffer IO of ext3 at the kernel level takes care of the repetitive decompression problem of small files within the same directory structure.
OK it's out there... I do not have the skills to due the sfs and double loop mount ext3 inside at the init level, but main developers can quickly
1) When running with base2ram=expand ---> the underlying filesystem in memory is ext2, so all you say above (if I get it correctly) is already done.
2) The kernel has a cache at the VFS level, one level above the bare filesystem. So it doesn't really matter when the the filesystem is ext2, ext3, SFS, XFS, JFS ... when a file has been read, it *will* be cached regardless of the underlying filesystem (unless you explicitly disable this).
3) I don't see the point of having ext3 diskimage compressed inside SFS. Doing that will add one level of unnecessary indirection. Which speed bottleneck are you trying to address?
4) As previously said, Fatdog64 can use anything as its basesfs - not only squashfs. I already showed an example here: http://murga-linux.com/puppy/viewtopic. ... 387#707387.
Ok I'm lost here - what is this "SFS problem"?Ted Dog wrote:yes you understand this, also neat plus if ext3 block-file is copied to a harddrive, we could have a win-win type of frugal install, not really INSTALLED per say but that would free up RAM weak machines and remove the sfs problem as a bonus.
The reason for no auto-expand is because there are others who may want to use that RAM for running applications. If we do auto-expand then we also need to add switch for "no-autoexpand" ... messy.Ted Dog wrote:Which is why I wanted an auto-expand if RAM>= 10x sfs size. but no...
Now you're talking ! Problems with own-compiled software should be indicated as such as the beginning.chapchap70 wrote:Hi Jamesbond. Don't go crazy looking into the Thunderbird Pet. I installed Thunderbird 24.0 myself and changed the default icon.
Suspend never works for me, both the old and the new one, probably due to quirks in my graphics card (I've got dual-radeon laptop). All I've got after waking up is a black screen. If the old suspend.sh works then use it. It works on kirk's machine so may be he can help to look into this.When I opened my netbook lid back up, my arrow no longer moved and pushing the power button made my puppy bark and exit X. I put the old suspend.sh file back and renamed the one you rewrote
Do this: blacklist=radeon and pfix=nox. When you get to terminal, delete the file /etc/modprobe.d/radeon-dpm.conf, and then do "modprobe radeon" and wait a couple of minutes to see if you've got any video. If it doesn't work, then perhaps the radeon in this kernel version isn't good for your card.Gobbi wrote:My graphic card is a Radeon HD 7870 XT (Tahiti) and 'radeon workaround' solved the initial problems in FD620 . As then , after loading the kernel everything stopped , freezing the screen after the line where it was loading the kernel modules.
Confirmed, this is a bug in glib. However I hesitate to upgrade glib because it is used by many applications; if the only thing that a new glibc fixes is gtk-chtheme (and it break others) then I prefer not to do it. That being said, there is a "glib-2.36-630.pet" on the broken folder in ibiblio. Test it out if you wish - it fixes the crash with gtk-chtheme but we haven't tested in other situations.I could repeat an error though : Changing the Gtk theme ( Gradent Brown ) and then from the same Gtk window changing font (bold 12) then pushed 'Apply' button and then pushed 'Ok'button gave me a black screen with the mouse pointer functioning and after 10 seconds lxpanel ( strange coloured ) appeared . No wallpaper. Restarted X and the wallpaper I've set was on the desktop.
I even repeated changing the font size from 12 to 13 and then --> Apply --> Ok --> No more wallpaper again and lxpanel issue again . Restarting X put everything in order .
No, this would be the same behaviour even in earlier Fatdogs. I'll add default values the fields are blank.A second issue : Control Panel/Desktop/Fatdog64 Event Manager. Canceling the initial 30 seconds of interval for saving , without putting a zero (0) there gives an error and an increase of CPU activity which grows if I repeat trying to acces that Event Manager from Control Panel/Desktop/ .
Previously I remember the zero (0) value was added by default even if someone forgot to put a value...
What's the graphic card? If it's intel then you'll need to blacklist intel, not radeon (perhaps blacklist=i915 or blacklist=i810 or blacklist=gma500_gfx). How about trying to boot with "nomodeset"?L18L wrote:Never got a terminal.kirk wrote:Could you try booting with pfix=nox and when/if you get to a terminal type:
pfix=nox savefile=none
last thing I could see was :not using savefile
pfix=nox savefile=none loglevel=7
last thing I could see was: [ messages which I am used to see from dmesg command ] error ... video ...
Ok I will leave this to kirk as I said before, it doesn't even work for me so I don't use it.Ted Dog wrote:lid close on laptop drains battery quickly (12-15hrs), did not see that in FD621 lid down for a day or day half.
Which browser, Seamonkey or FF? Do you use noscript or adblock? The usual suspect for runaway plugin container is flash ads ...Pug in contaner is using 60% cpu run as user spot taking 90+Megs and growing , after using FD631rc1 for days, system is freezing and barely able to type.
This is a bug, there should only be two "dbus-launch" process - one for root and one for spot. Do you know how I reproduce this? If it it keeps creating/re-creating that is the problem with hald, and hald is used by Flash ... so it may be related to the plugin container problem above.multiple dbus deamons dups one of each type being created/distroied recreated by both spot and root. system my crash will try to get screen prints.