You are not logged in.
Hi all!
I have a problem, I don't know how it is related, but I have to reinstall arch from USB every time after big update. I don't know which exactly package fails, but and DE doesn't want to run. Usually, when arch is starting up, screen is blinking 1 time and after that DE is starting.
After update, screen is not blinking and nothing happens. I found the way, that if I will do 'pacstrap /mnt base base-devel' from USB - it will reinstall packages from pacman cache and everything will be find. Earlier I tried to solve this problem by myself, but now I understand, that I don't know why it is happens.
Maybe you can give me path to xorg archive logs? I saw one error in that logs when DE is tried to start up, but now I can't find it. I guess, the problem is with video driver, but, as I mentioned earlier, I don't know exaclty.
Last edited by Xinevic (2017-08-16 09:27:27)
Offline
When the issue occurs can you switch to another terminal with Ctrl+Alt+F2?
Maybe you can give me path to xorg archive logs?
Xorg#General ( for the location of xorg.log ) Also check the journal and please post your pacman.log as well.
Offline
When the issue occurs can you switch to another terminal with Ctrl+Alt+F2?
Can't remember. Probably no, because every time I wanted to change something in configs required me to reboot to USB.
pacman.log
https://pastebin.com/FVfBbdH7
Latest update, required reinstall was on 2017-04-29.
Offline
Is /boot a separate filesystem and is it mounted when the kernel package is updated?
Offline
Yes, /boot is on a separated partition.
Yes, it is mounted.
Offline
Arch loading is ok. Only DE can't start up.
Offline
What is in the journal from the DE failing to start?
If yours is the last post in the thread please edit that post rather than creating a new one.
Offline
What is in the journal from the DE failing to start?
How can I find logs written so long time ago?
If yours is the last post in the thread please edit that post rather than creating a new one.
OK, thanks.
Offline
How can I find logs written so long time ago?
Systemd#Filtering_output
X only keeps a log for the current invocation and previous invocation so if it is not in the journal you may have to wait for the issue to occur again.
Offline
Found errors.
May 02 21:17:34 pluhin-lap drkonqi[16787]: QXcbConnection: Could not connect to display :0
May 02 21:17:34 pluhin-lap systemd[1]: Requested transaction contradicts existing jobs: Transaction is destructive.
May 02 21:17:34 pluhin-lap systemd[1]: systemd-coredump.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction is destructive.
May 02 21:17:34 pluhin-lap systemd[1]: systemd-coredump.socket: Unit entered failed state.
May 02 21:17:34 pluhin-lap systemd-coredump[16794]: Failed to connect to coredump service: Connection refused
May 02 21:17:34 pluhin-lap klauncher[16792]: QXcbConnection: Could not connect to display :0
May 02 21:17:34 pluhin-lap systemd-coredump[16795]: Failed to connect to coredump service: Connection refusedOffline
Latest update, required reinstall was on 2017-04-29.
The errors you found are from a more recent date and the DE is currently working? If you think it is related please post the full journal for the boot containing those errors.
Are there no journal entries for 2017-04-29 or earlier?
$ journalctl --list-bootsTo list all boots in the journal
$ journalctl -b $IDWhere $ID is an ID from the output of the previous commands alternatively use --since and --until see `man 1 journalctl` for the data/time format required.
Offline
Yes, I updated system on 2017-04-29 and rebooted it on the 2nd of May.
Boot log with error uploaded here
https://ptpb.pw/SOBA
Offline
From the small excerpt, reads like crashes related to an outdated microcode. Setup your microcode updates correctly.
If that wasn't it, look into your coredumps and maybe post a bigger stacktrace that might help in identifying the problem
Last edited by V1del (2017-05-04 09:28:28)
Offline
Issue still exists.
Using this command
coredumpctl listshows me lines like this:
Mon 2017-08-07 23:06:06 +03 304 0 0 11 missing /usr/bin/sddm
Mon 2017-08-07 23:06:07 +03 380 0 0 11 missing /usr/bin/sddm
Mon 2017-08-07 23:06:07 +03 418 0 0 11 missing /usr/bin/sddm
Mon 2017-08-07 23:06:08 +03 453 0 0 11 missing /usr/bin/sddm
Mon 2017-08-07 23:06:09 +03 488 0 0 11 missing /usr/bin/sddm
Wed 2017-08-16 10:05:31 +03 305 0 0 11 error /usr/bin/sddm
Wed 2017-08-16 10:05:32 +03 381 0 0 11 error /usr/bin/sddm
Wed 2017-08-16 10:05:32 +03 419 0 0 11 error /usr/bin/sddm
Wed 2017-08-16 10:05:33 +03 445 0 0 11 error /usr/bin/sddm
Wed 2017-08-16 10:05:33 +03 471 0 0 11 error /usr/bin/sddmOffline
FYI, pacstrap does -Sy with no associated -u, so there is a danger of partial updates when it is used on an existing system.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
So what if you stop using SDDM and try an alternative?
But something definitely sounds fishy with your setup. Instead of reinstalling the same stuff every time, why don't you wipe the system and reinstall from scratch, then see if the problem returns?
Matt
"It is very difficult to educate the educated."
Offline
FYI, pacstrap does -Sy with no associated -u, so there is a danger of partial updates when it is used on an existing system.
I am doing this right after updates, so, I don't think this will affect some packages.
why don't you wipe the system and reinstall from scratch, then see if the problem returns?
I tried, but this didn't help.
So what if you stop using SDDM and try an alternative?
Yea, that's good idea. I'll try to do this.
Offline
Have you checked your microcode as asked earlier?
I possess a device, in my pocket, that is capable of accessing the entirety of information known to man.
I use it to look at funny pictures of cats and to argue with strangers.
Offline
Have you checked your microcode as asked earlier?
Yes, I installed package and add file link to grub config file.
dmesg | grep microcode
[ 1.233322] microcode: sig=0x506e3, pf=0x20, revision=0x74
[ 1.233698] microcode: Microcode Update Driver: v2.2.Last edited by Xinevic (2017-08-17 10:00:54)
Offline
And that doesn't look correct, did you rerun grub-mkconfig to properly apply the change?
You should have a
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29or similar as the very first line in your dmesg. If still in doubt post the contents (and paths) of the files you adjusted as well as a
ls -l /boot
mount
pacman -Q intel-ucode linux
uname -aLast edited by V1del (2017-08-17 10:47:33)
Offline
After an upgrade fails, is the kernel version that is running (uname -a ) the same as the kernel version that is installed ( pacman -Q linux )
I'll bet two credits that the boot partition is not mounted when a kernel update is attempted.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
And that doesn't look correct, did you rerun grub-mkconfig to properly apply the change?
You should have a
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29or similar as the very first line in your dmesg. If still in doubt post the contents (and paths) of the files you adjusted as well as a
ls -l /boot mount pacman -Q intel-ucode linux uname -a
Yup, I executed grub-mkconfig.
ls -l /boot
total 36544
drwxr-xr-x 2 root root 4096 Aug 17 16:26 grub
-rw-r--r-- 1 root root 24036800 Aug 16 09:45 initramfs-linux-fallback.img
-rw-r--r-- 1 root root 6629028 Aug 16 09:44 initramfs-linux.img
-rw-r--r-- 1 root root 1303040 Jul 9 15:15 intel-ucode.img
-rw-r--r-- 1 root root 5437712 Aug 12 10:18 vmlinuz-linux
mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8125380k,nr_inodes=2031345,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
/dev/sda6 on /home type ext4 (rw,relatime,data=ordered)
/dev/sda5 on /programming type ext4 (rw,relatime,data=ordered)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1626020k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
pacman -Q intel-ucode linux
intel-ucode 20170707-1
linux 4.12.6-1\
uname -a
Linux pluhin-lap 4.12.6-1-ARCH #1 SMP PREEMPT Sat Aug 12 09:16:22 CEST 2017 x86_64 GNU/LinuxWhat else do you need?
After an upgrade fails, is the kernel version that is running (uname -a ) the same as the kernel version that is installed ( pacman -Q linux )
I'll bet two credits that the boot partition is not mounted when a kernel update is attempted.
Upgrade does not fail.
But I think, running kernel is older than installed, because I need reboot to start new one.
Offline
In that mount command your /boot isn't mounted, are absolutely certain that that /boot you ls -l'd me is your boot partition (as opposed to a directory that appeared because pacman tried to install stuff there)? I 'm gonna go with no, which explains all of the issues so far. Make sure your /boot is mounted via an entry in /etc/fstab then reinstall linux intel-ucode and rerun grub-mkconfig.
If still in doubt, post your fstab and
lsblk -fOffline
Thank you, that helps. But I don't know exactly, what exactly: switching to LightDM, or adding /boot to fstab.
Today I upgraded my kernel, and system started up without any problems.
Offline
It was definitely adding /boot to your fstab that fixed your problem.
You might want to reinstall the packages (e.g. intel-ucode) that put files in /boot to ensure that they are correct/up-to-date, since they were put on your root partition earlier.
(or move the contents of your root partition's boot folder to your boot partition I guess).
Last edited by Omar007 (2017-08-21 17:37:10)
Offline