This is in response to vtpup's help reply on p. 16, 4 days ago (already!).
I did change from xorg to xvesa, without success. Actually I just got a dark screen with xvesa. I had to reboot.

As to removing all the sfs's in the dpup's home dir from another Puppy, I did, and it didn't help. When I rebooted dpup, the cursor was still glued to the middle of the screen, and I couldn't do anything but go back to console mode.

No big deal, mind you, I wasn't too far ahead in building my personal pupsave / customizing my dpup. I simply started over with pfix=ram.

I am reporting this in the hope that some of you with more knowledge will know if this problem intersects with some other one in dpup, and perhaps point you with an additional hint in the direction of the solution.

I could manage to fix my kernel panic error at boot. Sadly this error will affect any Puppy distribution created with Woof.

I discovered the cause of this error, it´s init script in dpup. Although I can update this script with a new version, in a updated dpup release will present the same problem if Woof is not updated. I´m glad that Barry is working in woof, so I should report to him and hope for a definitive fix.

When I boot dpup for the first time in MWare I created a pupsave file in one of my partition disk (used to test 214x, dpup, 4.3, etc) at shutdown, but I selected one partition with less of 120 MB, the pupsave was 32 MB and I had other pets here too. Then the free space left was about 50 MB.

Later when I boot dpup the second time, it found the pupsave and then it copied the dpup_482.sfs file in that partition. Here is the problem init script does not have a routine to validate free space before the SFS copy (actually this partitions free space is smaller than the SFS file). Anyway the sfs file was copied without any error or alert and the boot process complete successfully. Everything seems to work fine at this second boot.

Then When Pupp boots the third time, CRASH TIME, I get the kernel panic error because Dpup try to use the dpup_482.sfs found in the same directory of pup_save, BUT this is a damaged SFS produced in the second boot when I didn´t have enough free space in that partition (in fact this SFS files was about 40 MB, the original file is over 80 MB).

Well, I don´t like that "feature" (automate copy of xxx.sfs file to home directory) in new Puppys but I can live with that. And I understand Barry´s decision to include that "feature" to reduce successive boot times and increase performance without any user intervention.

The problem is that there are not enough validation before the SFS copy process and not even a single error or alert when you don´t have enough free space, the process just go on and produces a wrong SFS copy. I consider it a mayor bug for the init script that should be fixed in Woof. The good thing is, it only require a quick check in init then a easy fix could be implemented.

I understand Woof is in development and in a early state now.

Barry all your develop efforts are greatly appreciated, I evolve to a Puppy fanatic and a Barry´s admirer. I see Woof as a visionary base system for the future of Puppy and hope you take the voice of this humble Puppy user to improve Woof init script, I also thing a special Woof development thread should be created to discuss this issues.

If on LiveCD boot, Puppy encounters a usable personal savefile on a partition which is nearly full, and has no Puppy sfs file, it will automatically write a new Puppy sfs on that directory, without checking for free space.

Because the newly saved Puppy sfs is larger than available disk space, it is corrupted. This appears as a kernel panic on the next puppy boot.

You would like Puppy to check for free space before automatically saving a copy of the Puppy sfs to disk.

EDIT: I'm surprised by this. I thought you had to explicitly choose to have a Puppy sfs saved on disk, just like the personal savefile. That dialog was always at the end ov a LiveCD session. Has something changed?

Musher0, the only thing that occurs to me is that either Open Office 2.4 overwrote an essential file with one of its own, or inserted a startup script, and now the X startup chain is broken, since Open Office files were removed by hand, rather than an uninstaller.

Have you tried re-installing 2.4 to see if functionality is restored?

If you reinstall, and it works, have you tried overlaying the OO 3.1 on top of it by just adding it to the bootmanager?

Have you made sure the the Open Ofice 3.1 sfs is the new type 4 sfs? (s4s).

Have you tried backing up your personal save (assuming frugal) file, and then booted from LiveCD with pfix=clean, or more radical, pfix=purge?

EDIT: I'm surprised by this. I thought you had to explicitly choose to have a Puppy sfs saved on disk, just like the personal savefile. That dialog was always at the end ov a LiveCD session. Has something changed?

I was surprised too. I explicitly said NO (It sounds weird ) at first shutdown.

Musher0, the only thing that occurs to me is that either Open Office 2.4 overwrote an essential file with one of its own, or inserted a startup script, and now the X startup chain is broken, since Open Office files were removed by hand, rather than an uninstaller.
[...]

I managed to get back my dpupsave file by loading dpup with pfix=ram, and then I loaded the save file. I went in the /usr/lib directory and deleted the OpenOffice sub-directory that was there. Next boot, the sfs manager did not show up to offer BK's Oo sfs. But everything else worked, I could go about dpup and load any program, etc.

I'll make a good back-up of the dpupsave file and try again with either BK's Oo or preferably with the OxygenOffice sfs. If I succeed installing OxygenOffice, that would mean I could actually work in dpup. (As in "putting-bread-on-the-table" kind of work. My operative system is now Puppy 4.12, ... with lots of tweaks and enhancements!)

As to Xvesa not working, my memory failed me, and my notes above are a bit incorrect. Xvesa loads, but the resolution is so low, everything is blurred. You can't bring it say, to 800x600 resolution to read the commands. Also the initial dpup configuration panel seems to appear, which confuses things. But everything was so blurry, I can't be sure if it was this panel or something else.

I solved this one by going to the black console, then typed:

Xvesa -listmodes

* a list of modes appears in 0x0etc. format, with a description, though.
Then I typed

Xvesa -mode 0x011A # to get 1280x1024 resolution.

Then,

xwin

which brought me to the desktop, but Xvesa was still not at the desired resolution (it was probably 800x600). However this time the panel appeared properly and was readable, so I could adjust Xvesa to my desired resolution.

Last thing about Xvesa in dpup: once up and working, ctrl-alt-backspace doesn't bring you back to console, it reboots the wm. Only way out, a radical

busybox reboot

in any console window

Not to complain, but is dpup's Xvesa Puppy's or Debian's? Is it a newer version of Xvesa? I never had this Xvesa problem before in any version of Puppy.

Anyway, to you and your colleagues on this D-Puppy: keep up the good work!_________________musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)

It's probably a xorg 7.4 problem, Barry had heaps of trouble with it (including xvesa, to the point where he was going to exclude xvesa) in early woof builds. Especially with intel graphics. Surprising? Not!!!_________________Puppy Linux Blog - contact me for access

Well using the latest dpup for a few hours now.
I like the new control panel, I really don't like wbar and would like to have the natural desktop icons back. I like the new quicklaunch taskbar links. Gweled is a excellent game also glad X-Soldier is their, the other 3 games well ummm not my cup of tea. The screensaver is cool. So far very nice updates
ttuuxxx_________________http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games

That disable wbar would make a great feature ummm paste doesn't work in the terminal, unless your running parcelite. plus I find the transparent background in the terminal very distracting, I'm not trying to nitpick but I'm used to a few minor comfort zones
also below is the latest and maybe last version of Parcelite I just compiled on dpup, it would be great if it loaded by default after boot
ttuuxxx

I am going to run parcellite in beta5...paste only doesn't work from geany, works with middle mouse button from everywhere else...it has been noted as a bug with the geany developers and apparently a fix is in the works...The console background is configurable...mrxvt-full --help at console will give you all the options...the config file is in /root

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