[arch-general] gnome fix needed
I discovered this and was able to recover, and think gnome could do with a fix. I put together a script to completely erase gnome from this system and for the most part that script worked really well. The exception was that it also removed wpa_supplicant since I had cascading and recursive and unneeded packages being removed. Without wpa_supplicant on a system that system in command line mode isn't getting out onto the internet. I put wpa_supplicant back on the system using the install disk I have and the internet at least is working correctly. I was trying to get orca talking on the system and couldn't do it so figured it's best if I start with a clean slate which is the reason for the removal script. I'll run it for xorg and mate before I'm finished and try to get all of this stuff running again without questionable configuration files on the system. I think I may get lucky. According to email from another list, apparently neither gdm nor lightdm will get us screen reader users to a talking orca, but xorg should get that job done. If someone has the time, please run sudo -H Xorg --configure and let me know if that command errors out with a segmentation fault at address 0x50 or any other address or if you get a configuration file generated. It could be xorg configuration on this system is also messed up beyond repair and I'll have to clean that out too. --
Op 10 sep. 2017 11:41 schreef "Jude DaShiell" <jdashiel@panix.com>: I discovered this and was able to recover, and think gnome could do with a fix. You do sound a bit mysterious here :). Apparently you discovered something, but don't tell what it is. Kudos for capturing attention, but don't expect a fix for anything soon... I put together a script to completely erase gnome from this system and for the most part that script worked really well. The exception was that it also removed wpa_supplicant [.. ] I put wpa_supplicant back on the system using the install disk Did your script also delete pacman's cache? Otherwise it would have been there in /var/cache/pacman/pkg (from the top of my head). [Sudo, xorg, segfault] Okay, that's a sudden twist. The message starts with the subject of a Gnome problem, continues on a removal script and ends with a question on a sudo/xorg question. With a little work, it could probably become a great forum or blogpost, but for a technical mailinglist it's a bit too puzzling. We usually love to puzzle out a solution for a *specific* problem. In this case, I still don't know where the problem is, other then sudo or xorg crashing. But perhaps it's just me...? Mvg, Guus Snijders
So far as I know, pacman's cache was left untouched by the script. On Sun, 10 Sep 2017, Guus Snijders via arch-general wrote:
Date: Sun, 10 Sep 2017 06:37:48 From: Guus Snijders via arch-general <arch-general@archlinux.org> To: General Discusson about Arch Linux <arch-general@archlinux.org> Cc: Guus Snijders <gsnijders@gmail.com>, arch-general@lists.archlinux.org Subject: Re: [arch-general] gnome fix needed
Op 10 sep. 2017 11:41 schreef "Jude DaShiell" <jdashiel@panix.com>:
I discovered this and was able to recover, and think gnome could do with a fix.
You do sound a bit mysterious here :). Apparently you discovered something, but don't tell what it is. Kudos for capturing attention, but don't expect a fix for anything soon...
I put together a script to completely erase gnome from this system and for the most part that script worked really well. The exception was that it also removed wpa_supplicant
[.. ]
I put wpa_supplicant back on the system using the install disk
Did your script also delete pacman's cache? Otherwise it would have been there in /var/cache/pacman/pkg (from the top of my head).
[Sudo, xorg, segfault]
Okay, that's a sudden twist. The message starts with the subject of a Gnome problem, continues on a removal script and ends with a question on a sudo/xorg question.
With a little work, it could probably become a great forum or blogpost, but for a technical mailinglist it's a bit too puzzling. We usually love to puzzle out a solution for a *specific* problem. In this case, I still don't know where the problem is, other then sudo or xorg crashing. But perhaps it's just me...?
Mvg, Guus Snijders
--
On Sun, 10 Sep 2017 09:03:01 -0400, Jude DaShiell wrote:
So far as I know, pacman's cache was left untouched by the script.
IIUC it shouldn't matter, you got rid of all configs (excepted of those in $HOME) after removing the packages, with or without the -n option. Unlikely the packages in the cache are broken, so IMO it doesn't matter if they are installed from cache or from a fresh download.
On Sun, 10 Sep 2017 12:37:48 +0200, Guus Snijders wrote:
Did your script also delete pacman's cache? Otherwise it would have been there in /var/cache/pacman/pkg (from the top of my head).
Hi, assuming it anyway is the same package version and release, then it makes no difference if the package is installed from the cache or downloaded. If it's in the cache, it will not be downloaded again, but get installed from cache. However, since Jude first -Rs or -Rss the packages and does _not reinstall_ the packages, there should be no old config in the way after removing them ( https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave#.pacsave ), excepted of configs in $HOME. Just reinstalling packages is something else, even after deleting a .pacnew file no new one gets installed, the edited config either way stays untouched. Regards, Ralf
On 09/10/2017 04:41 AM, Jude DaShiell wrote:
please run sudo -H Xorg --configure and let me know if that command errors out with a segmentation fault at address 0x50 or any other address
The 'segmentation fault at address 0x50' is a bug -- plain and simple. Given the address referenced is way, way down in the system-reserved memory range, the most likely cause is an unitialized pointer, or an attempt to access a pointer outside the bounds of an allocated block of memory. Neither I, nor anyone else, can tell you where the segfault is being triggered, but a quick look at 'man Xorg' does provide a few hints on 'Xorg -configure' (not --configure): -configure When this option is specified, the Xorg server loads all video driver modules, probes for available hardware, and writes out an initial xorg.conf(5) file based on what was detected. This option currently has some problems on some platforms, but in most cases it is a good way to bootstrap the configuration process. This option is only available when the server is run as root (i.e, with real-uid 0). It would be worth checking whether your platform is one where -configure "currently has some problems." -- David C. Rankin, J.D.,P.E.
participants (4)
-
David C. Rankin
-
Guus Snijders
-
Jude DaShiell
-
Ralf Mardorf