Puppy Linux Discussion Forum

[Henry]

I've opened a new thread here for the "final." (I hope it isn't.)

The situation is similar here. I've just gone through another session of xorgwizard hell. Using the new "TEST" button I get, as before, a good X screen. The only new possible new clue I have is that after I press ctl+alt+bspc I see a fleeting text line, too brief to read, but it seems to say "X connection to 0.0 broken . . ." or such.

Am I the only one with such a problem? All three 2.13s have started without a pup_sav.3fs file, but none start with one - a good one that always works with 2.12. What's wrong with 2.13 that wasn't with 2.12?

Henry

[Sit Heel Speak]

At http://murga-linux.com/puppy/viewtopic.php?t=14092 WhoDo says he had to rename his pup_save.3fs to pup_save.2fs to get it to work.

[Henry]

Yes, thanks, I had seen that and tried it, but it wouldn't go at all.

I have tried several different config files, both 0.5G and my usual 1Gb, different computers, with and without copying sfs and zdrv, etc. Xvesa always worked with all prior puppies, but it won't work at all in this situation.

It's been baffling, so different from the great prior puppy experience I've come to appreciate.

Henry

[BarryK]

The "X connection broken..." message is okay.

Xvesa won't work!? It should do, there's no difference from before.
For the Video Wizard, the very first dlg window now asks do you want Xorg or Xvesa -- what happens if you choose Xvesa?

[Henry]

Yes, I did try that - that's how I know it doesn't work. As I recall I get into a cyclic "type xwin" situation.

Henry

[Henry]

Good morning, Barry,

Finally some news. I've probably been driving people up the wall with this, but mostly myself. Here's what I found.

It's not a video problem at all. But there is something about the pup_sav.3fs file that 2.13 doesn't like and that keeps it from starting the video. As I've said over and over, 2.12 likes the configuration file and works perfectly with it.

So here's what I did. I started 2.12 without any configuration file. I did a modest amount of configuring - set the background to grey, enabled autohide, installed the Gimp, and connected to the internet. A very small amount of customizing compared to my working 2.12 system. This was then saved at exit as a new pup_sav.3fs.

I then booted from 2.13 final. It liked this simple new configuration and took off immediately, in Xvesa which I always use, no wizards, etc. So 2.13 _does_ start with a configuration file, just not the one I want, unfortunately.

So the mystery is what makes a configuration "incompatible," the fear of having to start over at each new version. I think we need to understand this in order to have confidence that a future upgrade will be successful. Right now I will have to start over if I want to use the new features in 2.13.

(Oops, I just noticed that the config is still a .3fs Shouldn't that have been converted into a .2fs? I'll run it again and check.)

Henry

[John Doe]

Henry, what is your hardware?

That might help everyone search for bugs.

[Henry]

OK, I ran 2.13 a second time. It's still .3fs, and I had noticed that the first time it had copied zdrv_213.sfs to the hard drive. It starts quickly, runs Gimp, etc, but one lttle oddity - the grey screen is crosshatched until I choose the Xvesa setup from the menu ??

Well, it's progress of a sort.

Henry

[Henry]

OK, John Doe,

Here's a nutshell. I don't know how much detail is needed. I do note that every version prior to 2.13 worked fine on this hardware.

Number Processors 1
Processor Description AMD Duron(tm), 1597MHz
Total Memory 479MB
Total Hard Drive 149GB
Display Senergy 560, 15.2" (31cm x 23cm)
System Uptime 0 Days, 0 Hours, 14 Minutes
BIOS Version American Megatrends BBS V3.20 0402
User Name  
Timestamp 1/3/07 12:25:33 AM
 
Henry

[Henry]

Here's the video, but again, I think that's a red herring since I had the same problems on another more modern computer.

Device Type Display adapters
Device Name  
Description NVIDIA GeForce4 MX Integrated GPU
Manufacturer NVIDIA
Driver Provider NVIDIA
Driver Date 12-27-2002
Status Code 0
Status Message OK

Henry

[John Doe]

[Lobster]

We need to sort this. I had a similar sort of experience. I was actually trying to create an unleashed from my first pristine boot of Puppy 2.13 . . .

I loaded from the new created distro
got a kernel panic message - OK (I barely know what I am doing so OK)

. . . then I tried running from 2.13 - same

OK I will boot from ram only with "pfix=ram"
SAME - kernel panic

Oh dear . . .
OK I need to boot from HD
to clear the .sfs (which it should not be picking up? Maybe it is picking up from a tmp file or .sfs on another partition - or something . . .)

My Grub from HD broken - oh dear . . .

I had a Pizzapup Alpha (based on 2.12) - no joy (again I got the message 'not synching - kernel panic')

My last resort was booting from a second CD copy of 2.13 (again with pfix=ram) and this time I was OK

So is the boot sequence searching through hard drives partitions (I think I have about 6) and picking up wrong instructions?

Sorry can not offer more help

[Henry]

Thanks for sharing that, Lobster. I can appreciate it.

I have been checking and rechecking. You know how time-consuming that can be, but I have pretty good confidence that everything I reported above is correct, with this one exception
"but one lttle oddity - the grey screen is crosshatched until I choose the Xvesa setup from the menu ?", which was a finger fumble of mine. Forget it.

Also, I am confident that there are no stray instances of configuration files elsewhere on my four hard drive partitions or the one usb flash. (The 98se find function is worthless for this on large files, but I looked in all the plausible places and of course used gtkfind with all mounted.)

So, to recap:

1- I now have 2.13 final working with a simple dummy config file that was upgraded from 2.12 as a test and

2- I have my regular working 2.12 final with all tweaks. There seems to be no way to upgrade this to 2.13, as reported :(

Henry

[BarryK]

[Henry]

Sorry to keep harping on this. I'm just a "user", but it probably could happen to someone else equally unable to fix it. So I have some questions -

Is there a way to examine or test the content of pup_sav.3fs to determine if there is some corruption or whatever that doesn't matter in the current version but prevents upgrading to the next?

Is a pup_sav "cleaner utility" feasible?

If I bit the bullet and started configuring over again in 2.13, is there any assurance that an upgrade to 2.14, etc will work? (Yes, I know - no guarantees, etc. but is this the plan?)

What is thought to be the cause of this - a bug, intolerance of package handling errors (of which I've encountered many), or what, and the outlook for preventing it? Yes, of course I understand that any file can be corrupted, becoming unusable, but if a configuration works in one version it should be (I think) usable in the next, at least to the point of being able to adapt it. It it won't run at all it's a show-stopper.

Thanks for your patience. I know and appreciate that Barry and others are doing superhuman work here that is greatly admired and appreciated. Just wondered what the thinking was on this. No one can expect prompt action on any specific issue. There are many other priorities.

Now I stand to be corrected or informed.

Henry