Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: kevinfish on March 15, 2010, 04:44:00 PM
-
I added persistent home with home=sda7 in my menu.lst file, removed home/tc from .filetool.lst and now every time it boots ~tc is created with root:root ownership and it gets stuck with:
xauth: timeout in locking authority file /home/tc/.Xauthority
I have to break out with ^C, type:
$ sudo chown tc:staff ~tc; startx
to get it all running again. I have checked there are no other mydata.tgz files on the system and one I have doesn't have home/tc in it.
Why is it doing this?
P.S. also check my other posts because the problems may be related.
-
Is this a fat filesystem?
-
no
-
This is strange, and shouldn't happen. I think it is a matter of considering any possible causes, and eliminating the ones you know are not causing it.
What filesystem is it?
If you save files in /home/tc, are they still there next time you boot?
What other boot options are you using?
Does it still happen if you boot with the norestore boot option?
Is there anything unusual about your installation which may cause it to function differently to a normal one?
-
ext3
yes, persistent /home
kernel /bzImage quiet xvesa=1280x800x16 laptop waitusb=5 root=/dev/ram0 real_ro
ot=/dev/sda7 max_loop=255 home=sda7 tce=sda7 opt=sda7
haven't checked the norestore option (but since I'm not backing up /home/tc I don't see what difference it should make -- but I'll try it anyway).
not that I can think of right off the bat. I have a multi-boot with gentoo but I haven't even booted it in a long time.
-
I started getting this error too. It started happening when I decided to add some files from home/tc to my backup.
I ended up adding `chown -R tc:staff /home/tc` to bootlocal.sh. This may be a problem with an extension that is loaded. You can try booting with just 'norestore' or just 'base' to verify where the permissions errors are coming from.
-
I'm not currently using a usb/cf disk so I doubt it is the waitusb thing. I tried the norestore and my ~tc was still root:root. I put the chown thing in my bootlocal.sh and it still has the same error (although I didn't use the recursive flag, just the chown on the ~tc dir -- I'll try that next).
-
as an afterthought, if I'm using a persistent home it must not be actually creating ~tc, right? So something is actively chowning it to root:root IMHO.
-
If it is an extension, it is good to know so the extension can be fixed.
You can boot with base and see if it happens.
If it is, temporarily remove various extensions until you find out which one it is.
Report it to the person who made the extension.
-
Corrupted filesystem or corrupted grub ?
Why you do not try TC on a FAT pertition to see if the ext3 fs is giving these hiccup ?
Or may be a fresh install on a fresh formated HDD / PenDrive ?
Just a thought !
~ Pats
-
On the second thought, can the culprit be your bootcodes :
root=/dev/ram0 and/or real_root=/dev/hda7 ?
Try to remove both, and try only root=/dev/hda7 - to check the result.
Hope this helps !
~ Pats
-
as per my other posts, I re-installed with 2.10 and the problem went away. Go figger?!? ::)
-
I started getting this in my 2.9 installation too. I then tried a 2.10 version install, but the problem did _NOT_ go away for me. And I am pretty stumped about why we would be getting this. ???
BTW, this is occurring in the frugally-installed version of TC in my eeePC nettop.
--
Mike
-
Update: I cleared out my TCE directory and installed all my regular extensions from the beginning under 2.10. Now I don't have any problem xauth problems at all. Looks like something got messed up in my 2.9 extension set that was not resolved until I made a fresh start. Now 2.10 is working pretty well for me.
Oh, by way, I've added ALSA master sound control support to Flit. It may need some more work before I release it to the public, but its nice to have it now with ALSA (which I use with Skype).
--
Mike L.
-
Glad to hear it is working. Looking forward to an update for flit.
-
Wonder if this might help someone. I just installed v4L and Mplayer to try and see if I can stream my usb webcam, and I started having this .Xauthority problem: booting takes now at least 2 minutes longer than before, like 2 minutes and 20 sec, that is.
I got rid of Mplayer and v4L, but the problem remains. Strange. Especially because the Xauthority message was there before, but with no boot delay.
Oh, and I just noticed that appbrowser is kaput. Can I do anything about it, or just need to reinstall 2.10?
-
Which extensions, exactly?
-
Hard to write down the names of those extensions exactly without a working appbrowser, but the version of Mplayer that I installed was the one dependent on gtk2 (which was already on my machine). As far as v4L goes, there is only one extension in the repository, I believe.
-
To list them, try `cd /usr/local/tce.installed ; ls -1`
-
Did it, but the list I got is identical with what you see if you hit Update Dep Database in AppsAudit. That is, no extensions are listed that have been uninstalled.
However, these are the extensions that seem to have triggered the .Xauthority problem:
MPlayer-svn-gtk2.tcz
v4l-dvb-2.6.29.1-tinycore.tcz
Got their complete names from http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/tcz_2x.html
Is there a way of getting appbrowser work again?
Can the .Xauthority problem be fixed?
One reason I value TCL is the amazing boot time. But with this problem, this is even worse than Windoze7.
-
I could reproduce, and found the issue. It's related to the replacement of tcz-symlinker with cp, and triggered by a small design flaw in the MPlayer-svn-gtk2 extension (maybe others as well, but I confirmed that one).
The difference in behavior is that cp also copies directory permissions. The extension includes /home/tc, owned by root. Jason, could you replace this with a startup script? The current way doesn't take the user name into account either.
dito, quick fix directions:
boot with "text base" + your home= code
remove MPlayer-svn-gtk2.tcz from your onboot.lst file, either using vi (or "sed -i '/MPlayer-svn-gtk2.tcz/d' /path/to/onboot.lst")
sudo chown -R tc.staff /home/tc
-
Thanks curaga, this fix works. I just reloaded mplayer yesterday and the problem came back (the GTK 2 version). Maddening!
Hopefully, the fixed mplayer extension is out now or will be soon.
--
Mike L.
-
I wish I could also confirm that curaga's instructions fix the problem. Unfortunately, I lost my temper and reinstalled everything before I saw them...
-
For what it is worth...
I've encountered the same problem after running wine for the first time.
To support wine, it creates a subdirectory ~tc/.wine with a bunch of files. Some of the files are owned by root:staff instead of tc:staff.
Upon the next boot, it is stuck waiting for .Xauthority because ~tc is owned root:staff.
As indicated in the various posts above, the workaround was:
1) Ctrl-C out of the wait for .Xauthority
2) sudo chown -R tc:staff ~tc ; startx
3) Make sure that a Backup is done on the next TC Exit so that mydata.tgz is updated with all the ~tc files set with tc:staff ownership.
-
I've got the same thing happening..
And it really sucks. I think it comes from my /home/tc/.X.d folder. since that is the only thing I edited.
I put a file in it to launch opera automaticly => it didn't work and it took my system over 2 minutes to boot .
-
As long as you create files in .X.d owned by tc:staff for launching things like flit, conky, etc then things work fine.
I'm not too sure I'd want to start opera this way, but did you remember the "&" at the end?
-
yes, i did..
is there an other way to launch opera at startup then?
-
I made test by creating a file named ~/.X.d/opera containing "opera &"
After booting in text mode, creating the file, loading the opera extension and then "startx", opera opened almost instantly
-
strange.. I'm reinstalling TC right now..
hopefully it will be allright after that..
-
For what it is worth...
I've encountered the same problem after running wine for the first time.
To support wine, it creates a subdirectory ~tc/.wine with a bunch of files. Some of the files are owned by root:staff instead of tc:staff.
Upon the next boot, it is stuck waiting for .Xauthority because ~tc is owned root:staff.
As indicated in the various posts above, the workaround was:
1) Ctrl-C out of the wait for .Xauthority
2) sudo chown -R tc:staff ~tc ; startx
3) Make sure that a Backup is done on the next TC Exit so that mydata.tgz is updated with all the ~tc files set with tc:staff ownership.
Hi I have similiar problem, I installed wine and after subsequence reboot the owner of /home/tc was changed to root.
I tracked down the problem and I found out that there were a bunch of symlinks on ~/.wine/drive_c/users/tc that point to /home/tc (My Documents, My Music etc). On reboot when these symlinks get restored, they were recreated as root somehow.
I deleted those symlinks since I don't need them and I can boot just fine.