No I wasn't mucking around with glibc this time. I'm using a frugal install 32-bit XenialPup 7.0.4, and late last night after replacing the fan / cleaning out my T60 Lenovo 2GHz, 4GB RAM I realized that Xandr wasn't giving me my native screen size of 1400x1050. I diddled with manually correcting Monitor0 and MonitorModes in Xorg.conf but nothing worked - I was stuck on 1280x800. I updated (??) my radeon ATI RV515 (Gallium 0.4) drivers via my updated PPM, and went to bed without a reboot check.
This morning I had a frozen setup on startup - mouse, keyboard non-responsive. Rebooting with puppy pfix=ram my machine hardware is all fine, and I broke into the pupsave.sfs /etc/X11 xorg.conf that was last altered and changed everything back to 1280x800. But no go. Assuming that I kyboshed my system with the string of radeon drivers (I think I added about 4 from PPM - all seemed legit and loaded without errors), I was looking for the Puppy boot parameter that enables you to peel back to previous last-working savefiles. I can't seem to find it. Only possible with live-CD where savefiles are burned as successive tracks?
I'm under the pump with a deadline, so will move to my desktop to finish up. Tacit lesson (again) to have my snap2 backups sorted out and my safety nets always in place.
Any suggestions gratefully accepted, as ever
How do I reverse fatal changes to my frugal pupsave [SOLVED]
How do I reverse fatal changes to my frugal pupsave [SOLVED]
Last edited by Puppyt on Thu 03 Aug 2017, 11:15, edited 1 time in total.
Search engines for Puppy
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...
It would be best to do this from a different running Puppy.
Try this:
Boot not using the bad pupsave.
Click on and open the bad Pupsave.
Navigate to the etc/X11 in the Pupsave.
Delete xorg.conf
Close and reopen the Pupsave to make sure xorg.conf got deleted.
Now boot using the Pupsave.
Hopefully it will boot using the generic xorg.conf that is in the main Puppy.sfs. It will have no changes and should boot clean.
If that works.
In PPM uninstall all of the Radeon stuff you installed.
Reboot making sure to save, to make sure the Pupsave updated.
Try this:
Boot not using the bad pupsave.
Click on and open the bad Pupsave.
Navigate to the etc/X11 in the Pupsave.
Delete xorg.conf
Close and reopen the Pupsave to make sure xorg.conf got deleted.
Now boot using the Pupsave.
Hopefully it will boot using the generic xorg.conf that is in the main Puppy.sfs. It will have no changes and should boot clean.
If that works.
In PPM uninstall all of the Radeon stuff you installed.
Reboot making sure to save, to make sure the Pupsave updated.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
The latest 32bit Xenialpup is version 7.0.8.1
http://distro.ibiblio.org/puppylinux/test/xenialpup/
http://distro.ibiblio.org/puppylinux/test/xenialpup/
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Hi bigpup, and thanks very much for your suggestions. I first "snuck behind" from another Puppy install and axed the xorg.conf, but rebooted to the same problem. Then I tried again to track down some method of reversing the damage by targeting any files created/added on the day, and deleting them. As you can imagine, it was like doing neurosurgery with a chainsaw. It didn't work either. The offending radeon (allegedly) files I last installed from PPM were:
radeon_firmware_new-140109.files
radeontop_0.9.files
radeontool_1.6.3-1.files
xserver-xorg-video-radeon-hwe-16.04_7.9.0.files
xserver-xorg-core-hwe-16.04_1.19.3.files
...and all of their dependencies as required. And 'lo, it came to pass that during my forensic excisions I found a readme doc for radeontool "has not been completely audited and may contain bugs that could damage your hardware. Use at your own risk." Notwithstanding where the problem lies, I should have trod more carefully. I think I have white-anted my Xenial 7.0.4 install with a bit of late-night cavaliering. I did find a hopeful reference site regarding manually editing arandr configurations to accept 1400x1050, but I only got as far as "First, update your firmware" - and here I am All for the want of getting the best out of a multiple monitor setup.
Thanks too for the notice on 7.0.8 Xenial, some hiccups there I note with the iso production at the time of writing. I haven't seen whether extracting the 3-4 key files across rather than CD burning actually works, but will look to updating the system, thanks
radeon_firmware_new-140109.files
radeontop_0.9.files
radeontool_1.6.3-1.files
xserver-xorg-video-radeon-hwe-16.04_7.9.0.files
xserver-xorg-core-hwe-16.04_1.19.3.files
...and all of their dependencies as required. And 'lo, it came to pass that during my forensic excisions I found a readme doc for radeontool "has not been completely audited and may contain bugs that could damage your hardware. Use at your own risk." Notwithstanding where the problem lies, I should have trod more carefully. I think I have white-anted my Xenial 7.0.4 install with a bit of late-night cavaliering. I did find a hopeful reference site regarding manually editing arandr configurations to accept 1400x1050, but I only got as far as "First, update your firmware" - and here I am All for the want of getting the best out of a multiple monitor setup.
Thanks too for the notice on 7.0.8 Xenial, some hiccups there I note with the iso production at the time of writing. I haven't seen whether extracting the 3-4 key files across rather than CD burning actually works, but will look to updating the system, thanks
Search engines for Puppy
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...
-
- Posts: 328
- Joined: Wed 25 Jun 2014, 20:31
I have no idea if the following will work...
It might be possible to uninstall the problematic packages from the command prompt. I've tried something like this successfully on Slacko 6.3.2 in a virtual machine: I installed some random xserver-xorg-core package from the Ubuntu repository, tried to restart the X server, and it didn't work. I uninstalled the package from the command prompt, and X was able to start up again.
So you could try booting your system with the puppy pfix=nox boot parameter - this is done the same way as using 'puppy pfix=ram' to avoid the savefile; but rather than doing that, it boots into a command prompt without launching the X server. Hopefully your system is not too broken and can still run the package manager from the command line.
You can uninstall a package by typing petget -packagename. (That's a 'minus' sign in front of the package name. Specifying the package's file extension - .pet, .deb, .txz, etc. - doesn't seem to be necessary.) To get a list with the exact names of your installed packages, show the content of the /root/.packages folder:
Now if you want to uninstall, for example, the package that is listed as 'xserver-xorg-core-hwe-16.04_1.19.3.files', type:
I'm not sure, but maybe you'll have to save and reboot afterwards to make the changes come into effect - type "poweroff" or "reboot".
It might be possible to uninstall the problematic packages from the command prompt. I've tried something like this successfully on Slacko 6.3.2 in a virtual machine: I installed some random xserver-xorg-core package from the Ubuntu repository, tried to restart the X server, and it didn't work. I uninstalled the package from the command prompt, and X was able to start up again.
So you could try booting your system with the puppy pfix=nox boot parameter - this is done the same way as using 'puppy pfix=ram' to avoid the savefile; but rather than doing that, it boots into a command prompt without launching the X server. Hopefully your system is not too broken and can still run the package manager from the command line.
You can uninstall a package by typing petget -packagename. (That's a 'minus' sign in front of the package name. Specifying the package's file extension - .pet, .deb, .txz, etc. - doesn't seem to be necessary.) To get a list with the exact names of your installed packages, show the content of the /root/.packages folder:
Code: Select all
ls /root/.packages
Code: Select all
petget -xserver-xorg-core-hwe-16.04_1.19.3
That boot parameter is 'puppy pfix=n', with 'n' being the number of saves that you want to skip. And yes, as far as I know, it only works with multisession CDs, where each save is stored in a separate folder on a new track.Puppyt wrote:I was looking for the Puppy boot parameter that enables you to peel back to previous last-working savefiles. I can't seem to find it. Only possible with live-CD where savefiles are burned as successive tracks?
Cheers mostly_lurking! I'll try that out, and thank you very much for the tip on 'subtracting' via the petget command.
UPDATE: EUREKA mostly_lurking's anti-petget tip (petget -[problem package name here]) worked a treat! Using the boot parameter "puppy pfix=nox", first I peeled back "xserver-xorg-core-hwe-16.04_1.19.3" and rebooted - same same, and then after I was able to resurrect my desktop, albeit to 1280x800. Chalk that up as "solved", and two new lessons for me. Leaving the fiddling there for now, while I put out spot-fires in the real world...
UPDATE: EUREKA mostly_lurking's anti-petget tip (petget -[problem package name here]) worked a treat! Using the boot parameter "puppy pfix=nox", first I peeled back "xserver-xorg-core-hwe-16.04_1.19.3" and rebooted - same same, and then after
Code: Select all
petget -xserver-xorg-video-radeon-hwe-16.04_7.9.0
Search engines for Puppy
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...
[url]http://puppylinux.us/psearch.html[/url]; [url=https://cse.google.com/cse?cx=015995643981050743583%3Aabvzbibgzxo&q=#gsc.tab=0]Google Custom Search[/url]; [url]http://wellminded.net63.net/[/url] others TBA...