xorg.conf is rebuilt each time I restart X [solved]

Using applications, configuring, problems
Post Reply
Message
Author
User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

xorg.conf is rebuilt each time I restart X [solved]

#1 Post by miriam »

This has cost me days of puzzling and trying everything I could think of. I'm hoping somebody here will have an idea of what to do...

Firstly, many, many thanks to pizzasgood for starting this thread and everybody who has added to it.

I compiled the linuxwacom files from sourceforge and put them in the correct places, then altered my /etc/X11/xorg.conf file to add entries for stylus, eraser, touch, and pad. I also added the /etc/udev/rules.d/65-wacom.rules file with the appropriate line.

When I restarted X everything worked like a charm. I was able to enable Gimp input devices stylus and eraser for screen. Pressure sensitivity worked beautifully. My eraser worked as an eraser. It was wonderful. I spent some joyful hours working on some art I desperately need to finish. Unfortunately a lightning storm started up in my area so I had to turn my computer off (I normally leave it on for weeks or months at a time).

After the storm, when I restarted the computer and the wacom tablet no longer worked... well, not exactly... it works, after a primitive fashion, but without pressure sensitivity, and Gimp and mtpaint no longer see the stylus and eraser as input devices.

I looked at the xorg.conf file and it had reverted to its original form without any of the wacom settings in it. Okay, I thought. I'd previously made a copy of my xorg.conf file, just in case, so I simply copied that over it and restarted X. Once again the xorg.conf file had reverted to its original form.

Now I became suspicious. I made a single tiny edit of the xorg.conf file merely adding a comment near the top of the file -- just "# test" on a line. I exitted from X to the command prompt and saw xorg.conf still had my tiny alteration (head /etc/X11/xorg.conf). Then I ran xwin to start X again. Once X was back up, I looked at xorg.conf again... my little comment inside it was now gone!!

For some strange reason my xorg.conf file is being rewritten whether or not there is anything odd in it. So now my wacom tablet is reduced to being like a mouse -- a comfortable mouse -- but without pressure sensitivity.

Does anybody have any thoughts as to what I can try to undo what is forcing this rewrite on xorg.conf on every X restart?

I don't know how relevant these are, but here is my setup:
Puppy Lupu 528 (full install)
Kernel 2.6.33.2
Wacom Intuos PTS on USB
ATI Radeon 3000 Graphics embedded in the motherboard
I installed the proprietary AMD Catalyst accelerated driver amd-driver-installer-12-1-x86.x86_64.run ages ago... it seems to be still operating. Running glxinfo displays "server glx vendor string: ATI" and "OpenGL vendor string: Advanced Micro Devices, Inc." and "OpenGL renderer string: ATI Radeon 3000 Graphics", so that seems okay.
Last edited by miriam on Mon 22 Sep 2014, 10:26, edited 2 times in total.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

weirder and weirder... but it kinda works now

#2 Post by miriam »

I have been trying everything I can think of, and found something very weird. A solution, of sorts. But I have no idea why it works.

I tried copying the backup version over my xorg.conf file and instead of exitting from X to the command line in the usual way via the main menu, I instead pressed CTRL-ALT-F3 to go to another uh... not sure what the proper name is... another login prompt, anyway. Then I pressed CTRL-ALT-F4 to go back to the X display. When I checked the xorg.conf file all the changes remained. When I tried Gimp it was able to see the stylus, eraser, touch, and pad. and I have pressure sensitivity again! (unfortunately I can't turn off touch, but at least I'm getting somewhere.)
NOTE: as I explain in a later post the CTRL-ALT-Fx strategy doesn't actually do anything.

Here is the weirdest part: I restarted from the main menu as I normally do, to see if the changes to xorg.conf stuck, but when I was back in X the xorg.conf file was stripped of all my additions again. However Gimp still sees the stylus, eraser, etc. Huh???

I wonder if this will disappear after another reboot (or two). In the meantime I have at least a somewhat unsatisfactory way of getting the wacom tablet working (mostly) again.

I'd still love to know what is the culprit causing my changes to xorg.conf to be overwritten though. Any ideas?
Last edited by miriam on Sat 20 Sep 2014, 00:43, edited 1 time in total.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#3 Post by greengeek »

Don't know if this is going to help (because I can never remember exactly what works when I have xorg.conf problems) but I seem to remember doing two things when this happened to me:
1) Copied the "known good" xorg.conf into /etc/x11 multiple times - using the current file names shown there (things like xorg.conf, xorg.conf0, xorg.confNvidia435, etc etc) - make each file exactly the same contents, just different file names.
2) Exit to prompt then reboot by typing "xwin". This should in theory allow it to boot to X without re-running the xorgwizard.

(I seem to recall that automatic xorgwizard activation during full boot became standard at some point in Puppies development, but it is a pain when you want to use a manual xorg config)

Not sure how you can permanently prevent the running of xorgwizard though - I think its a change to /etc/rc.d/something.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#4 Post by miriam »

Thanks for the suggestion greengeek, but no effect. Something is still overwriting my xorg.conf file with a minimal version without the wacom additions.

Strangely, Gimp and mtpaint are nevertheless able to see that I have stylus, eraser, etc attached.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

investigating a little further...

#5 Post by miriam »

Hoping to pin down a bit better what is going on, I shut the computer down, then turned it on again. Gimp and mtpaint could no longer see the stylus or eraser.

I restored my wacom settings in xorg.conf then used CTRL-ALT-F3 to exit from X to another commandline login prompt, then CTRL-ALT-F4 to return to the X display. I was surprised to find Gimp and mtpaint still couldn't see the stylus and eraser even though the xorg.conf settings are still there.

But when I restarted X via the main menu Gimp and mtpaint could now see the stylus and eraser even though the xorg.conf was now devoid of my wacom settings.

Doesn't seem to make sense. There must be something else going on that I don't know about which makes sense of this.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#6 Post by greengeek »

Is this a frugal installation? Is there a possibility of trying a previous savefile?

EDIT - just another thought - I'm not clear on exactly when your xorg.conf is being automatically modified but whatever triggers that process might be using one of the following files:
/usr/sbin/xorgwizard
/usr/sbin/xorgwizard-automatic
/usr/sbin/xorgwizard-cli

Might be worth renaming each of these three files so they cant be accessed (especially /usr/sbin/xorgwizard-automatic) and rewriting the xorg.conf files again with the known-good contents, then exiting to prompt and typing 'xwin' again.

If the xorgs get overwritten again at least you would know that those 3 wizard files are not involved. If that is the case I can't suggest any other possibilities for what is overwriting the xorg.confs.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#7 Post by miriam »

Great idea greengeek. I had a look in /usr/sbin and I only have
xorgwizard (actually a link to xorgwrapper.sh)
xorgwizard.sh
xorgwrapper.sh

I temporarily appended to their names "--disabled" so they couldn't be run, then changed xorg.conf and restarted X. Unfortunately the xorg.conf file was still overwritten again, but at least now I know more than I did before and have a strategy for possibly finding the culprit. Thank you for the idea.

I have a full install, not frugal. Yes, one of the nice things about frugal installs is the way they can be reset back to earlier conditions so easily. Much more difficult with full installs.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

a little more info...

#8 Post by miriam »

I found that my previous step of dropping out of X to another commandline via CTRL-ALT-Fx then returning with CTRL-ALT-F4 was unnecessary.

X uses the version of xorg.conf I last wrote even though something overwrites it with a minimal version each time. So that means X is reading the xorg.conf file before it gets overwritten by something. Suddenly this is not looking quite so crazy anymore.

I'll post more as I find out more.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#9 Post by wjaguar »

After starting X, you get a new "minimal" xorg.conf - but what happens to the preexisting one? Maybe a copy of it does appear, under some transformed name like "xorg.conf.whatever", in /etc/X11 or in /tmp ?

Another thing - does your "original" xorg.conf, the one that gets overwritten, contain string "#PuppyHardwareProfile" at all? And if it does, what is in it?
And the same about the "minimal" xorg.conf.
Because I see Puppy's "startx" aka /usr/bin/xwin can switch xorg.conf files based on that.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#10 Post by miriam »

The old xorg.conf seems to be deleted. There is no other file that age in the /etc/X11 folder.

Yes, both the new minimal file and my edited version containing the wacom settings both have a line:

Code: Select all

#PuppyHardwareProfile=ATI_ATOMBIOSSA300_SA350
I have been trying to work my way through the files that alter or rewrite the xorg.conf file. There is a surprising number of them. I'd been trying to understand their function, but after greengeek's suggestion I've been one by one renaming a file, restarting X, checking the xorg.conf file, then when I see it has still been overwritten I rename the ex-suspect file back to how it was. It is slow, but faster than trying to understand all the code inside the file. Problem is, I'm starting to lose track of which ones I've eliminated as suspects and which I haven't. :)

I made a short two-line program to find all the shellscript files that reference xorg.conf and I'll work my way slowly through it.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#11 Post by wjaguar »

miriam wrote:The old xorg.conf seems to be deleted. There is no other file that age in the /etc/X11 folder.
Age means nothing; scripts never preserve it - a copy gets ctime of when it was made. It is file contents that matter.
Yes, both the new minimal file and my edited version containing the wacom settings both have a line:

Code: Select all

#PuppyHardwareProfile=ATI_ATOMBIOSSA300_SA350
No difference? There goes that possibility, then.
Problem is, I'm starting to lose track of which ones I've eliminated as suspects and which I haven't. :)
Looks like maybe it's time for strace, then. :-) From commandline login, run:

Code: Select all

strace -f -ostracelog.txt -e trace=file,process startx
and exit from X as fast as possible afterwards, to avoid the log growing huge. Or maybe use "trace=open,unlink,process" instead - but no guarantee the problematic syscall will be a simple open() or unlink() and not something more esoteric.
This way, you should then be able to find in the logfile - which PID unlinked your xorg.conf, or opened it for writing, or whatever; what binary was exec()'ed when that PID came to be, and what PID was its parent, and what binary that was, etc., etc. And through this chain, find the offending command.
I made a short two-line program to find all the shellscript files that reference xorg.conf and I'll work my way slowly through it.
I scanned the Lupu's unpacked filesystem for "xorg.conf" in Midnight Commander. Faster and easier. :-) But seemingly useless anyhow; the bug, whatever it is, is not obvious to me.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

Re: a little more info...

#12 Post by greengeek »

miriam wrote:X uses the version of xorg.conf I last wrote even though something overwrites it with a minimal version each time. So that means X is reading the xorg.conf file before it gets overwritten by something
Doesn't xwin contain fallback code that detects 'problems' with the xorg.conf and rewrites the file itself at that time according to whatever method BK chose as a suitable default fallback?

You don't think there is some syntax error in your changes within xorg.conf and xwin is saying "don't like that - I'm reverting to default"?

Is there any alternative way to force X to run without using the /usr/bin/xwin script which seems to be giving it a chance to overwrite xorg.conf?

EDIT : - Maybe some way to trigger /usr/bin/xinit without going through /usr/bin/xwin?

So - set xorg.conf how you want it, then kill X and issue xinit command?
(Just spitballin' here...)

EDIT 2 : Maybe there is something in this BK post which may offer a clue:
http://www.murga-linux.com/puppy/viewto ... 7448#87448
Last edited by greengeek on Sat 20 Sep 2014, 20:29, edited 1 time in total.

oldaolgeezer
Posts: 64
Joined: Sun 03 Dec 2006, 19:34

xorg.conf is rebuilt each time I restart X

#13 Post by oldaolgeezer »

miriam:

I'm not certain if my comments will be of any help but I'll say the following:

There are several differences in my experience from yours:
I had a frugal install, I used Slacko 5.7 and my PC's were IBM/Lenovo Thinkpad Tablet PC's with wacom built into the LCD screen.

When I was tweeking my /etc/X11/xorg.conf file, I found that simple syntax errors (such as omitting a trailing quote) caused my /etc/X11/xorg.conf file to be completely replaced with a "pure" version without any of my wacom tweeks! This syntax scan of /etc/X11/xorg.conf is certainly done when X is first started, but may be done again if certain X controlled hardware such as mouse, keyboard or video, etc is needed.

Look in your /var/log/Xorg.0.log file for any error messages.

(I used, in a terminal window: grep wacom /var/log/Xorg.0.log and I only looked for error messages about wacom stuff.)

In your case, however, any error message at all in /var/log/Xorg.0.log (not even about wacom stuff) may result in the /etc/X11/xorg.conf file being completely replaced.

Also, this page suggests making xorg.conf read-only (and has more explaination of xorg.conf):
http://www.murga-linux.com/puppy/viewtopic.php?p=661718

Hope some of this helps.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

partial soultion!!

#14 Post by miriam »

Wow! Lots to answer here... Thanks folks :)

wjaguar, sorry, I should have said no file that age or more recent, except for the newly created minimal xorg.conf

My problem occurs while X is starting rather than when it is shutting down (but your suggestion for strace is just as useful for that). When I exit from X and check the xorg.conf file my changes are still there. It is when I restart X that the file gets overwritten... and most mysteriously, after X has read it and set up accordingly. It (strace) is yet another command I didn't even know existed. :) Cool. Linux is endlessly fascinating.

Okay... something very strange going on here... I ran strace immediately before starting X and stopped it again as quickly as I could (by which time it had already accumulated 22 megabytes of tracelog text! Holy cow!) Anyway I started going through it looking for all instances that refer to xorg.conf and found something odd. At one point it refers to xorg.conf with parameters O_WRONLY|O_CREAT among other parameters, which I assume means that it is writing to and creating a new xorg.conf file. Immediately after that (and this is the weird part) it opens "xorg.conf0_not_wizard_tablet", which is a file I made some time back when I was trying to get my wizard graphics tablet working on Puppy. Suspiciously, the contents of this file look exactly like the file that ends up as my new xorg.conf file, so on a hunch I renamed it "xorg.conf0-not_wizard_table" (missing only the final 't') then restarted X. Now when I looked at my xorg.conf file it was empty! Zero bytes! This means for some reason my computer has got it into its metaphorical head to always copy a file named exactly "xorg.conf0_not_wizard_tablet" over my xorg.conf file. To further test this I renamed my wacom settings version of the xorg.conf file as "xorg.conf0_not_wizard_tablet" and restarted X. Now my xorg.conf file has all my wacom settings. So I have a partial solution...

But why on Earth would it decide to use that file as its template?
And why bother to when the original is fine?
Weird.

I'm currently doing a long, slow search for any file on my system that refers to "xorg.conf0_not_wizard_tablet". There's nothing in /etc /bin /lib /sbin /var /root that refers to it. Grepping through /usr will take ages...


greengeek, yeah, exactly the same thought (that there might be an error in my xorg.conf file) occurred to me, which is why I tried simply adding a tiny comment to the minimal file, only to find even that still got overwritten.

I had a long, careful look at /usr/bin/xwin and commented out each reference to xorg.conf one by one, each time restarting X. Sloooow and tedious (takes me back to my old MSWindows days. :) ) No effect on this problem.


oldaolgeezer, I looked through the /var/log/Xorg.0.log and it only refers to xorg.conf once. Reading through the wacom log values is very interesting, though they didn't help with my immediate problem.

I tried making xorg.conf read only, without any luck. The system still obliterates it. I'm slowly reading through the goldmine of info npierce presents on
http://www.murga-linux.com/puppy/viewtopic.php?p=661718
Thanks for the pointer to that.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

Re: partial soultion!!

#15 Post by wjaguar »

miriam wrote:At one point it refers to xorg.conf with parameters O_WRONLY|O_CREAT among other parameters, which I assume means that it is writing to and creating a new xorg.conf file. Immediately after that (and this is the weird part) it opens "xorg.conf0_not_wizard_tablet" ...
So now we know what happened. It is some progress. :-)
I'm currently doing a long, slow search for any file on my system that refers to "xorg.conf0_not_wizard_tablet". There's nothing in /etc /bin /lib /sbin /var /root that refers to it. Grepping through /usr will take ages...
And therefore, it would be better to study strace's log instead. ;-)
From it, one can find out not only the what, but the where and who - which might provide enough clue as to the why. :-)

Where you see in the log something like this:

Code: Select all

3206  open("xorg.conf", O_WRONLY|O_CREAT) = 4
the first number is the PID of the process doing the open(). Grepping for that number will produce something that begins like this:

Code: Select all

3204  clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7e08708) = 3206
3206  execve("/usr/bin/cp", ["cp", ...
Here you see the PID of calling process (3204), the command which had later done the open() call (/usr/bin/cp), and the parameters passed to it (in place of "..."). If that would not yet be enough to find the culprit, grep for the calling process' PID. And then for the PID of its caller. And then, for the caller of that caller...
In the end, you will have a chain of calls - from startx down to the simple shell command doing the overwriting. From that, at the very least the location of the problem will become visible.

Or, just upload that log somewhere, and I will do the investigation. :-)

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

solved

#16 Post by miriam »

Thank you so much for your suggestions and help wjaguar. I had no idea the strace command existed and how very helpful it could be. After using your instructions I picked through the trail of clues in the strace log and found that my .xinitrc file has the following code:

Code: Select all

if [ "`lsusb | grep 5543`" = "" ]; then
	cat /etc/X11/xorg.conf0_not_wizard_tablet >/etc/X11/xorg.conf
else
	cat /etc/X11/xorg.conf0_wizard_tablet >/etc/X11/xorg.conf
fi
This had me stumped for a while until I realised the culprit was... me.
Oh, the embarrassment.
It was part of an attempt about a year ago to get my computer to substitute a suitable xorg.conf file depending on whether the wizard graphics tablet was plugged in or not. I think it worked (so I forgot about it), but I never managed to get that tablet functioning fully.

I'm puzzled that grep didn't find it. Thankfully strace let me track it down or I'd still be scratching my head.

Perhaps the code fragment will be of use to someone. The 'if' statement tests whether lsusb finds the tablet whose vendor ID is 0x5543 then copies the appropriate file over xorg.conf

So... solved. The bug wasn't in Puppy. It was in me. :?

Thank you everyone for your patience and help, and especially to wjaguar for your suggestion of strace and explanation of how it works. I'm very grateful.

Now I should probably start looking into alzheimers remedies. :)
[color=blue]A life! Cool! Where can I download one of those from?[/color]

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

Re: solved

#17 Post by wjaguar »

miriam wrote:

Code: Select all

	cat /etc/X11/xorg.conf0_not_wizard_tablet >/etc/X11/xorg.conf
And this is why symlinks are so very useful. ;-)
Were the command "ln -sf /etc/X11/xorg.conf0_not_wizard_tablet /etc/X11/xorg.conf" instead, you would immediately have seen what was going on.
I'm puzzled that grep didn't find it.
Because of "." in the ".xinitrc" name. This is a hidden file, and globbing ignores it, unless special action is taken.
The 'if' statement tests whether lsusb finds the tablet whose vendor ID is 0x5543...
...in an overcomplicated way. ;-)

Code: Select all

if ! lsusb | grep -q 5543 ; then
is how it should be done.

Any extra complexity in shell code adds yet more possibliliies for weird failure modes - of which there are quite enough to begin with. :-)

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#18 Post by miriam »

:) The symlink would have certainly helped. It would have brought me to that file xorg.conf0_not_wizard_tablet sooner, but I would have still spent a lot of time scratching my head as to why. What would have really helped more is if I'd done what I try more to do these days: document what I've done and why. I try to leave copious notes for myself in folders where things are affected and inside any code I write, as in the old saying about why we should document and comment our code: "six months later the program might as well have been written by someone else."

I didn't realise grep normally ignored dot-files. I'll have to change some of my scripts to counter that. Thank you. Another good thing that's come out of this.

Using the NOT (!) operator definitely makes it more elegant. I'm surprised the if statement it works without the brackets though. I tested it and it does indeed work. I doubt I'll omit them in my future programming though, because I think the brackets make it clearer and easier to read. Compact code is not necessarily the same thing as easily maintained code. Sed is incredibly concise, packing so much into a tiny space that many of my of sed scripts would be utterly unmaintainable except for all the comments and explanations I sprinkle through them of why and how they work. Even then it is so dense that it can still be difficult to understand. Decades ago, one of the computer clubs I used to belong to had a competition each month for one-liner programs. Some of those were amazing, and often quite impenetrable. :)

Thanks again for your help and insights wjaguar. I'm very grateful.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

Post Reply