Discussion:
[arch-general] gnome fix needed
Jude DaShiell
2017-09-10 09:41:32 UTC
Permalink
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.



--
Guus Snijders via arch-general
2017-09-10 10:37:48 UTC
Permalink
Op 10 sep. 2017 11:41 schreef "Jude DaShiell" <***@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
Jude DaShiell
2017-09-10 13:03:01 UTC
Permalink
So far as I know, pacman's cache was left untouched by the script.
Date: Sun, 10 Sep 2017 06:37:48
Subject: Re: [arch-general] gnome fix needed
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
--
Ralf Mardorf
2017-09-10 13:22:56 UTC
Permalink
Post by Jude DaShiell
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.
Ralf Mardorf
2017-09-10 13:14:57 UTC
Permalink
Post by Guus Snijders via arch-general
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
David C. Rankin
2017-09-14 20:30:47 UTC
Permalink
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.
Loading...