startx slow after I stupidly used pacdiff to overwrite everything

fredre · 2013-08-05 15:59:49

In one of the dumbest computer mistakes I've done recently, yesterday I ran pacdiff and overwrote all my config files with the pacnew ones. The only thing I backed up was my pacman.conf. I didn't even pay attention to which files it was replacing. I know for sure it replaced groups, passwd and some TexLive stuff, and possible shadow and gshadow as well. I don't know what else it replaced.

Anyway, I used useradd and passwd to remake my user, and I can login, and startx works but not correctly. It takes ~2 minutes to start instead of the ~4 second it used to take. Also it doesn't seem to run my .xinitrc correctly. In my .xinitrc I have the lines:

unclutter &
setxkbmap us -variant colemak &
exec awesome

setxkbmap runs (and keeps running. I can see it in htop), but it leaves me in qwerty. The command runs fine from a terminal though.

So, what might the problem be and how should I go about fixing this?

Edit:

from my xorg.0.log, I see the following errors (lines labeled (EE)):

[    33.162] (II) LoadModule: "vesa"
[    33.162] (WW) Warning, couldn't open module vesa
[    33.162] (II) UnloadModule: "vesa"
[    33.162] (II) Unloading vesa
[    33.162] (EE) Failed to load module "vesa" (module does not exist, 0)
[    33.163] (II) LoadModule: "modesetting"
[    33.163] (WW) Warning, couldn't open module modesetting
[    33.163] (II) UnloadModule: "modesetting"
[    33.163] (II) Unloading modesetting
[    33.163] (EE) Failed to load module "modesetting" (module does not exist, 0)
[    33.163] (II) LoadModule: "fbdev"
[    33.163] (WW) Warning, couldn't open module fbdev
[    33.164] (II) UnloadModule: "fbdev"
[    33.164] (II) Unloading fbdev
[    33.164] (EE) Failed to load module "fbdev" (module does not exist, 0)
...
[    34.741] (**) Option "xkb_rules" "evdev"
[    34.741] (**) Option "xkb_model" "pc104"
[    34.741] (**) Option "xkb_layout" "colemak"
[    34.776] (EE) Error loading keymap /tmp/server-0.xkm
[    34.776] (EE) XKB: Failed to load keymap. Loading default keymap instead.

Last edited by fredre (2013-08-05 16:40:30)

x33a · 2013-08-05 16:59:29

You can strace startx to see what takes the most time.

prabuselva · 2013-08-05 18:33:09

Hi fredre,
Even I did the same stupidity and overwrote all the files in /etc .. It totally screwed the system. I even posted another topic asking a similar query. I am in the same situation as you are now.. the worst startx doesn't even start for me.

I will try to edit my fstab and give permissions to the root filesystem. Right now My entire rootfs is kind of read-only. I cant modify any files in my root.
I think its the reason for the delay. Have u checked the fstab and permissions to the files in root fs?
what does it say. Is it read only or kinda normal ?

Anyways, Please Let me know if you solved this issue.

fredre · 2013-08-05 19:54:29

I just ran strace on startx, but a statistics report (with the -r switch) shows that the longest process is wait4, but that only takes .6 seconds. Running strace with timestamps confirms that startx takes < 1sec to run, so strace isn't recording whatever the issue is.

What I see when I run startx is <1sec of console output (presumably this time is when strace recorded), then the screen goes blank. Switching to the F2 console and running htop shows some systemd-udevd and pulseaudio processes starting on occasion, then, after ~2 minutes of this, my .xinitrc runs, and my system is usable (though keymap fails here, as mentioned in my previous post). Is there some better way to view whats going on?

@prabuselva
My fstab is fine. I have not checked the permissions on anything, other than to fix my groups. What files are you referring to?

From my pacman.log, the only files pacdiff potentially might have changed are:

/etc/group
/etc/passwd
/etc/gshadow
/etc/shadow
/etc/locale.gen
/etc/pacman.d/mirrorlist
/usr/lib/avahi/service-types.db
/etc/colord.conf
/etc/pacman.conf
/boot/grub/grub.cfg
/etc/ppp/ip-down.d/00-dns.sh
/etc/ppp/ip-up.d/00-dns.sh
/etc/texmf/*

I've already fixed passwd, group, locale.gen, mirrorlist, and pacman.conf. I presume gshadow and shadow are fine, as I can use my passwords to login. Grub, colord, tex, avahi, ip-up, and ip-down are all unlikely to be the problem as they seem to work fine.

prabuselva · 2013-08-05 20:01:31

Thanks for the list of files. I should also check and fix those files as you did.

btw, What about fstab? For me pacdiff overwrote the old fstab with an empty fstab file.
I will try to generate new fstab and will post my results in few hours. I got to sleep now.

x33a · 2013-08-06 05:25:05

fredre wrote:

Is there some better way to view whats going on?

Try strace with the -f switch, as it will record the child processes too. Also, use -v for a more detailed output. And log the output to a file using -o <filename>, in case you want to share it.

prabuselva · 2013-08-06 13:55:23

Hi fredre,

After manually editing all config files, Somehow I managed to bring my system back to life.. But now I got the same problem as yours.
StartX is terribly slow..takes upto 2-4 min to login. I use slim login manager. I tested in both xfce as well as awesome wm.
Login took approx 3 min in both the cases.

Did you solve your slow startup issue?

orschiro · 2013-11-20 07:23:20

Did you create another test user to see whether it is a user config issue?

I faced exactly the same and realised that it was related to the use of a too large cache tmpfs on a conventional HDD which was synced by a profile sync daemon. I disabled the cache tmpfs and now it starts up again instantly.

prabuselva · 2013-11-20 09:41:21

Hi Orschiro,

Thanks for your reply. But never mind, I did solve the problem. It was the issue with /etc/group. I forgot to add my account to the user and sudo group. Because of this all my startup applications and the startup services had permission issues which delayed my startup time. But it was weird though, I was able to login to DE without my account in the user groups.

Finally, I carefully added all the necessary groups to my user account so that I had no more permission issues.

orschiro · 2013-11-20 10:56:21

Thanks for sharing your solution.

I was thinking that maybe we could add our troubleshooting to the Wiki page: https://wiki.archlinux.org/index.php/Im … erformance

prabuselva · 2013-11-20 12:20:10

orschiro wrote:

Thanks for sharing your solution.
I was thinking that maybe we could add our troubleshooting to the Wiki page: https://wiki.archlinux.org/index.php/Im … erformance

I caused my system to slow down by deleting few important files. I suppose my tweaking is not a solution to improve boot performance in any way.
May be your solution of clearing the tmpfs may be included there.

Arch Linux

#1 2013-08-05 15:59:49

startx slow after I stupidly used pacdiff to overwrite everything

#2 2013-08-05 16:59:29

Re: startx slow after I stupidly used pacdiff to overwrite everything

#3 2013-08-05 18:33:09

Re: startx slow after I stupidly used pacdiff to overwrite everything

#4 2013-08-05 19:54:29

Re: startx slow after I stupidly used pacdiff to overwrite everything

#5 2013-08-05 20:01:31

Re: startx slow after I stupidly used pacdiff to overwrite everything

#6 2013-08-06 05:25:05

Re: startx slow after I stupidly used pacdiff to overwrite everything

#7 2013-08-06 13:55:23

Re: startx slow after I stupidly used pacdiff to overwrite everything

#8 2013-11-20 07:23:20

Re: startx slow after I stupidly used pacdiff to overwrite everything

#9 2013-11-20 09:41:21

Re: startx slow after I stupidly used pacdiff to overwrite everything

#10 2013-11-20 10:56:21

Re: startx slow after I stupidly used pacdiff to overwrite everything

#11 2013-11-20 12:20:10

Re: startx slow after I stupidly used pacdiff to overwrite everything

Board footer