[arch-general] Fwd: Kernel panic - after upgrade
2015-01-18 18:20 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
Here I exit from the prompt and reboot the machine, but get the same error message: can't run init.
What did I wrong?
You missed that the base group should be reinstalled, as the error is not with the ramdisk,
there's no /init outside of the ramdisk, so his problem seems to be in the initramfs, but probably because his base system is a bit borked and it mkinitcpio creates the initramfs out of it.
Well, I did so but can't to run successfully the `pacman -S base' command because of some difficulties. It complains about existing files and folder: it won't overwrite the /usr/lib64 folder.
post the exact errors you're getting
The output of `pacman -S base' command is: (50/50) checking keys in keyring (50/50) checking package integrity (50/50) loading package files (50/50) checking for file conflicts (50/50) checking available disk space ( 1/50) reinstalling filesystem error: extract: not overwriting dir with file /usr/lib64 error: problem occured while upgrading filesystem error: could not commit transaction error: failed to commit transaction (rransaction aborted) Errors occured, no packages were upgraded. I know that that the /usr/lib64 is a symlink only. What to do? -- Regards from Pal
On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <csanyipal@gmail.com> wrote:
2015-01-18 18:20 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
there's no /init outside of the ramdisk, so his problem seems to be in the initramfs, but probably because his base system is a bit borked and it mkinitcpio creates the initramfs out of it.
What to do?
Looking into "mkinitcpio" it makes an assumption that /usr/lib/initcpio/busybox exists -- while in your rescue arch-chroot, try just re-installing "mkinitcpio-busybox" package. It provides the 'init' function as I referenced earlier, which mkinitcpio symlinks to: $ /usr/lib/initcpio/busybox --list | grep init init Perhaps your busybox binary is somehow broken; after reinstall run mkinitcpio -p linux again to rebuild your initramfs and see if that helps. -te
2015-01-18 19:04 GMT+01:00 Troy Engel <troyengel+arch@gmail.com>:
On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <csanyipal@gmail.com> wrote:
2015-01-18 18:20 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
there's no /init outside of the ramdisk, so his problem seems to be in the initramfs, but probably because his base system is a bit borked and it mkinitcpio creates the initramfs out of it.
What to do?
Looking into "mkinitcpio" it makes an assumption that /usr/lib/initcpio/busybox exists -- while in your rescue arch-chroot, try just re-installing "mkinitcpio-busybox" package. It provides the 'init' function as I referenced earlier, which mkinitcpio symlinks to:
$ /usr/lib/initcpio/busybox --list | grep init init
Perhaps your busybox binary is somehow broken; after reinstall run mkinitcpio -p linux again to rebuild your initramfs and see if that helps.
I just did followings when in rescue arch-chroot: pacman -S mkinitcpio-busybox Success. mkinitcpio -p linux Success. exit from arch-chroot reboot Still get the kernel panic error mesage. What can I do now? -- Regards from Pal
On Sun, 18 Jan 2015 19:24:00 +0100, Csányi Pál wrote:
2015-01-18 19:04 GMT+01:00 Troy Engel <troyengel+arch@gmail.com>:
On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <csanyipal@gmail.com> wrote:
2015-01-18 18:20 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
there's no /init outside of the ramdisk, so his problem seems to be in the initramfs, but probably because his base system is a bit borked and it mkinitcpio creates the initramfs out of it.
What to do?
Looking into "mkinitcpio" it makes an assumption that /usr/lib/initcpio/busybox exists -- while in your rescue arch-chroot, try just re-installing "mkinitcpio-busybox" package. It provides the 'init' function as I referenced earlier, which mkinitcpio symlinks to:
$ /usr/lib/initcpio/busybox --list | grep init init
Perhaps your busybox binary is somehow broken; after reinstall run mkinitcpio -p linux again to rebuild your initramfs and see if that helps.
I just did followings when in rescue arch-chroot: pacman -S mkinitcpio-busybox Success.
mkinitcpio -p linux Success.
exit from arch-chroot reboot
Still get the kernel panic error mesage.
What can I do now?
I don't have got the knowledge Troy likely has got. I already would have restored my Arch install from a backup. Assumed you don't have got a backup, I would try a shot in the dark, by installing linux-lts from the official repositories or linux-rt-lts from Arch audio or use the downgrade command [1] to downgrade from 3.18.2-2 to 3.17.6-1, just to ensure that the kernel is or isn't the culprit. [1] https://aur.archlinux.org/packages/downgrade/
it won't overwrite the /usr/lib64 folder.
post the exact errors you're getting
The output of `pacman -S base' command is: (50/50) checking keys in keyring (50/50) checking package integrity (50/50) loading package files (50/50) checking for file conflicts (50/50) checking available disk space ( 1/50) reinstalling filesystem error: extract: not overwriting dir with file /usr/lib64 error: problem occured while upgrading filesystem error: could not commit transaction error: failed to commit transaction (rransaction aborted) Errors occured, no packages were upgraded.
I know that that the /usr/lib64 is a symlink only.
error: extract: not overwriting dir with file /usr/lib64 which means /usr/lib64 is a directory on your system?? since when didn't you upgrade? try "pacman -Syu -ignore filesystem ; pacman -S filesystem" otherwise read through all of the https://www.archlinux.org/news/ and check the steps you need to do for every update you missed so far. -- damjan
2015-01-18 19:28 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
it won't overwrite the /usr/lib64 folder.
post the exact errors you're getting
The output of `pacman -S base' command is: (50/50) checking keys in keyring (50/50) checking package integrity (50/50) loading package files (50/50) checking for file conflicts (50/50) checking available disk space ( 1/50) reinstalling filesystem error: extract: not overwriting dir with file /usr/lib64 error: problem occured while upgrading filesystem error: could not commit transaction error: failed to commit transaction (rransaction aborted) Errors occured, no packages were upgraded.
I know that that the /usr/lib64 is a symlink only.
error: extract: not overwriting dir with file /usr/lib64
which means /usr/lib64 is a directory on your system?? since when didn't you upgrade?
I did almost every day an update since I 'convert' this system from parabolagnulinux to arch linux. First this system was installed as arch linux, then it has ben converted into parabolagnulinux, and finally it was reconverted back into arch linux.
try "pacman -Syu -ignore filesystem ; pacman -S filesystem"
I tried this abowe and the first part is executed successfully, but after that just can't to reinstall the filesystem package because of the existence of the /usr/lib64/ directory.
otherwise read through all of the https://www.archlinux.org/news/ and check the steps you need to do for every update you missed so far.
As I tould abowe, I did update almost every day. What to do next? -- Regards from Pal
On 18 January 2015 at 19:40, Csányi Pál <csanyipal@gmail.com> wrote:
2015-01-18 19:28 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
it won't overwrite the /usr/lib64 folder.
post the exact errors you're getting
The output of `pacman -S base' command is: (50/50) checking keys in keyring (50/50) checking package integrity (50/50) loading package files (50/50) checking for file conflicts (50/50) checking available disk space ( 1/50) reinstalling filesystem error: extract: not overwriting dir with file /usr/lib64 error: problem occured while upgrading filesystem error: could not commit transaction error: failed to commit transaction (rransaction aborted) Errors occured, no packages were upgraded.
I know that that the /usr/lib64 is a symlink only.
error: extract: not overwriting dir with file /usr/lib64
which means /usr/lib64 is a directory on your system?? since when didn't you upgrade?
I did almost every day an update since I 'convert' this system from parabolagnulinux to arch linux. First this system was installed as arch linux, then it has ben converted into parabolagnulinux, and finally it was reconverted back into arch linux.
try "pacman -Syu -ignore filesystem ; pacman -S filesystem"
I tried this abowe and the first part is executed successfully, but after that just can't to reinstall the filesystem package because of the existence of the /usr/lib64/ directory.
otherwise read through all of the https://www.archlinux.org/news/ and check the steps you need to do for every update you missed so far.
As I tould abowe, I did update almost every day.
What to do next?
https://www.archlinux.org/news/update-filesystem-201301-1-and-glibc-217-2-to... » A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib. « afaik there was a wiki page about this too check what files you have in /usr/lib64/ and why. if they are from packages remove those packages. -- damjan
2015-01-18 19:45 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
On 18 January 2015 at 19:40, Csányi Pál <csanyipal@gmail.com> wrote:
2015-01-18 19:28 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
it won't overwrite the /usr/lib64 folder.
post the exact errors you're getting
The output of `pacman -S base' command is: (50/50) checking keys in keyring (50/50) checking package integrity (50/50) loading package files (50/50) checking for file conflicts (50/50) checking available disk space ( 1/50) reinstalling filesystem error: extract: not overwriting dir with file /usr/lib64 error: problem occured while upgrading filesystem error: could not commit transaction error: failed to commit transaction (rransaction aborted) Errors occured, no packages were upgraded.
I know that that the /usr/lib64 is a symlink only.
error: extract: not overwriting dir with file /usr/lib64
which means /usr/lib64 is a directory on your system?? since when didn't you upgrade?
I did almost every day an update since I 'convert' this system from parabolagnulinux to arch linux. First this system was installed as arch linux, then it has ben converted into parabolagnulinux, and finally it was reconverted back into arch linux.
try "pacman -Syu -ignore filesystem ; pacman -S filesystem"
I tried this abowe and the first part is executed successfully, but after that just can't to reinstall the filesystem package because of the existence of the /usr/lib64/ directory.
otherwise read through all of the https://www.archlinux.org/news/ and check the steps you need to do for every update you missed so far.
As I tould abowe, I did update almost every day.
What to do next?
https://www.archlinux.org/news/update-filesystem-201301-1-and-glibc-217-2-to...
» A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib. «
afaik there was a wiki page about this too
check what files you have in /usr/lib64/ and why. if they are from packages remove those packages.
There was only one package; after I remove it I can to reinstall the filesystem package. After that I run again mkinitcpio -p linux then exit from arch-chroot and reboot the machine. Success! I cn now login and start X Window, but say I can't run firefox. When started firefox I get error message: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory. Thank you all for help. Have one advices just for the firefox problem because I think this is related with my kernel-panic problem? -- Regards from Pal
On Sun, Jan 18, 2015 at 1:01 PM, Csányi Pál <csanyipal@gmail.com> wrote:
I cn now login and start X Window, but say I can't run firefox. When started firefox I get error message: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory.
Thank you all for help.
Have one advices just for the firefox problem because I think this is related with my kernel-panic problem?
$ pacman -Qo /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.6 is owned by gcc-libs 4.9.2-2 Try re-installing the gcc-libs package, should fix it. Make sure that you have the proper symlinks too, maybe something else is broken: $ ls -ld /lib* /usr/lib* lrwxrwxrwx 1 root root 7 Oct 25 13:41 /lib -> usr/lib lrwxrwxrwx 1 root root 7 Oct 25 13:41 /lib64 -> usr/lib drwxr-xr-x 222 root root 131072 Jan 18 11:21 /usr/lib lrwxrwxrwx 1 root root 3 Oct 25 13:41 /usr/lib64 -> lib $ ls -ld /*bin /usr/*bin lrwxrwxrwx 1 root root 7 Oct 25 13:41 /bin -> usr/bin lrwxrwxrwx 1 root root 7 Oct 25 13:41 /sbin -> usr/bin drwxr-xr-x 5 root root 86016 Jan 18 11:21 /usr/bin lrwxrwxrwx 1 root root 3 Oct 25 13:41 /usr/sbin -> bin hth, -te
On Sun, 18 Jan 2015 13:05:53 -0600, Troy Engel wrote:
$ pacman -Qo /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.6 is owned by gcc-libs 4.9.2-2
My apologies, indeed libstdc++.so.6 is installed here too.
2015-01-18 19:05 GMT+00:00 Troy Engel <troyengel+arch@gmail.com>:
On Sun, Jan 18, 2015 at 1:01 PM, Csányi Pál <csanyipal@gmail.com> wrote:
I cn now login and start X Window, but say I can't run firefox. When started firefox I get error message: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory.
Thank you all for help.
Have one advices just for the firefox problem because I think this is related with my kernel-panic problem?
$ pacman -Qo /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.6 is owned by gcc-libs 4.9.2-2
Try re-installing the gcc-libs package, should fix it. Make sure that you have the proper symlinks too, maybe something else is broken:
After I reinstalled gcc-libs package, I can start firefox.
$ ls -ld /lib* /usr/lib* lrwxrwxrwx 1 root root 7 Oct 25 13:41 /lib -> usr/lib lrwxrwxrwx 1 root root 7 Oct 25 13:41 /lib64 -> usr/lib drwxr-xr-x 222 root root 131072 Jan 18 11:21 /usr/lib lrwxrwxrwx 1 root root 3 Oct 25 13:41 /usr/lib64 -> lib
$ ls -ld /lib* /usr/lib* lrwxrwxrwx 1 root root 7 okt 25 18.41 /lib -> usr/lib lrwxrwxrwx 1 root root 7 okt 25 18.41 /lib64 -> usr/lib drwxr-xr-x 285 root root 233472 jan 18 19.08 /usr/lib drwxr-xr-x 34 root root 36864 jan 18 18.37 /usr/lib32 lrwxrwxrwx 1 root root 3 okt 25 18.41 /usr/lib64 -> lib These are all right.
$ ls -ld /*bin /usr/*bin lrwxrwxrwx 1 root root 7 Oct 25 13:41 /bin -> usr/bin lrwxrwxrwx 1 root root 7 Oct 25 13:41 /sbin -> usr/bin drwxr-xr-x 5 root root 86016 Jan 18 11:21 /usr/bin lrwxrwxrwx 1 root root 3 Oct 25 13:41 /usr/sbin -> bin
$ ls -ld /*bin /usr/*bin lrwxrwxrwx 1 root root 7 okt 25 18.41 /bin -> usr/bin lrwxrwxrwx 1 root root 7 okt 25 18.41 /sbin -> usr/bin drwxr-xr-x 5 root root 155648 jan 18 19.12 /usr/bin lrwxrwxrwx 1 root root 3 okt 25 18.41 /usr/sbin -> bin These are all right too. Thanks! -- Regards from Pal
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing. Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything. -- damjan
On Sun, 18 Jan 2015 20:24:54 +0100, Damjan Georgievski wrote:
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing.
Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything.
I would ignore "0 missing files" to stay on top of things. sudo pacman -Qk | grep -v "0 missing files"
2015-01-18 19:31 GMT+00:00 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
On Sun, 18 Jan 2015 20:24:54 +0100, Damjan Georgievski wrote:
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing.
Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything.
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
Running this command I found only one package has missing 1 file: warning: celestia-addon-sun: /tmp/gstar.jpg (No such file or directory) celestia-addon-sun: 32 total files, 1 missing file Reinstalling the celestia-addon-sun package doesn't solve this problem. The message still appeares when running the command: sudo pacman -Qk | grep -v "0 missing files" But this is not anymore a problem regarding this thread, I think. Right? -- Regards from Pal
On Sun, 18 Jan 2015 19:47:13 +0000, Csányi Pál wrote:
I found only one package has missing 1 file: warning: celestia-addon-sun: /tmp/ ^^^^ tmp?
2015-01-18 20:01 GMT+00:00 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
On Sun, 18 Jan 2015 19:47:13 +0000, Csányi Pál wrote:
I found only one package has missing 1 file: warning: celestia-addon-sun: /tmp/ ^^^^ tmp?
What does it mean? -- Regards from Pal
On 18 January 2015 at 21:04, Csányi Pál <csanyipal@gmail.com> wrote:
warning: celestia-addon-sun: /tmp/ ^^^^ tmp? What does it mean?
Ramdisk is mounted on /tmp, thus any file installed to it is lost after a reboot. --Oliver Temlin
On Sun, 18 Jan 2015 21:12:26 +0100, Oliver Temlin wrote:
On 18 January 2015 at 21:04, Csányi Pál <csanyipal@gmail.com> wrote:
warning: celestia-addon-sun: /tmp/ ^^^^ tmp? What does it mean?
Ramdisk is mounted on /tmp, thus any file installed to it is lost after a reboot. --Oliver Temlin
True for a default Arch install, but in general not entirely true. [rocketmouse@archlinux ~]$ ls -hAl /mnt/suse11.2/tmp total 1.5M drwx------ 3 108 root 4.0K Aug 17 18:45 .beagleindexwapi.5Qml2BkVwt -rw------- 1 rocketmouse users 149 Dec 31 2013 bug-buddy-ON108W drwx------ 2 rocketmouse users 4.0K Jan 15 07:08 .esd-1000 drwx------ 2 109 112 4.0K Jan 15 04:06 .esd-109 drwxr-xr-x 2 rocketmouse users 4.0K Dec 9 10:56 hsperfdata_spinymouse11.2 drwx------ 2 rocketmouse users 4.0K Oct 30 2013 icedteaplugin-spinymouse11.2 drwxrwxrwt 2 root root 4.0K Jan 15 04:06 .ICE-unix drwx------ 2 rocketmouse users 4.0K Sep 29 21:15 keyring-bRUdWG drwx------ 2 rocketmouse users 4.0K Sep 29 20:44 keyring-ls6N8D drwx------ 2 109 112 36K Jan 15 04:06 orbit-gdm drwx------ 2 rocketmouse users 28K Jan 15 07:08 orbit-spinymouse11.2 drwx------ 2 109 112 4.0K Jan 15 04:06 pulse-PKdhtXMmr18n drwx------ 2 rocketmouse users 4.0K Jan 15 07:08 pulse-YJ5zTKHNh18x drwx------ 2 rocketmouse users 4.0K Oct 28 2013 seahorse-0jqjxk [snip] On Sun, 18 Jan 2015 21:13:59 +0100, Ralf Mardorf wrote:
In /tmp/ there are only temporarily files. Nothing seriously can be installed to /tmp/.
"/tmp
Temporary files (see also /var/tmp). Often not preserved between system reboots." - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
From the same Wiki: "/tmp Temporary files to be preserved between reboots." Anyway, for a default Arch install after a reboot /tmp/ is cleaned and /tmp/ is for temporarily files, so nothing seriously can be installed to /tmp/.
On Sun, Jan 18, 2015 at 2:40 PM, Ralf Mardorf <ralf.mardorf@rocketmail.com> wrote:
On Sun, 18 Jan 2015 21:12:26 +0100, Oliver Temlin wrote:
On 18 January 2015 at 21:04, Csányi Pál <csanyipal@gmail.com> wrote:
warning: celestia-addon-sun: /tmp/ ^^^^ tmp? What does it mean?
Ramdisk is mounted on /tmp, thus any file installed to it is lost after a reboot. --Oliver Temlin
Anyway, for a default Arch install after a reboot /tmp/ is cleaned and /tmp/ is for temporarily files, so nothing seriously can be installed to /tmp/.
I believe Oliver was pointing out that the packager has made a mistake when the file is installed to /tmp, not that /tmp is/is not transient (it's actually tmpfs, so it's not "cleaned" -- it's created on boot by systemd->tmp.mount). A bug report should be filed for that package: https://aur.archlinux.org/packages/ce/celestia-addon-sun/PKGBUILD They're installing that JPG to /tmp/ for some odd reason, that's just wrong on any Linux distribution. $0.02, -te
On Sun, 18 Jan 2015 14:57:29 -0600, Troy Engel wrote:
A bug report should be filed for that package:
https://aur.archlinux.org/packages/ce/celestia-addon-sun/PKGBUILD
They're installing that JPG to /tmp/ for some odd reason, that's just wrong on any Linux distribution.
Full ACK. JFTR I once run into an issue: [rocketmouse@archlinux ~]$ grep tmp /etc/fstab #tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0 It's comment out because I don't need it anymore, while the ramdisk approach has got more advantages, than disadvantages, it could cause issues. I needed to add that line one time when compiling a kernel failed.
On Sun, 18 Jan 2015 14:57:29 -0600, Troy Engel wrote:
A bug report should be filed for that package
I don't use this package, but I have nothing to do, IOW I've got much time so I add a comment. "Comment by Ralf_Mardorf 2015-01-18 22:29 Another user is using your PKGBUILD and noticed that you installed a file to /tmp. https://lists.archlinux.org/pipermail/arch-general/2015-January/038355.html Please fix it." -https://aur.archlinux.org/packages/ce/
On Sun, 18 Jan 2015 20:04:21 +0000, Csányi Pál wrote:
2015-01-18 20:01 GMT+00:00 Ralf Mardorf <ralf.mardorf@rocketmail.com>:
On Sun, 18 Jan 2015 19:47:13 +0000, Csányi Pál wrote:
I found only one package has missing 1 file: warning: celestia-addon-sun: /tmp/ ^^^^ tmp?
What does it mean?
In /tmp/ there are only temporarily files. Nothing seriously can be installed to /tmp/. "/tmp Temporary files (see also /var/tmp). Often not preserved between system reboots." - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
On Sun, Jan 18, 2015 at 1:31 PM, Ralf Mardorf <ralf.mardorf@rocketmail.com> wrote:
On Sun, 18 Jan 2015 20:24:54 +0100, Damjan Georgievski wrote:
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing.
Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything.
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
Here's another little script[1] that might help you, Pal -- it looks at all binaries in $PATH for any missing shared libraries (it would have caught your firefox problem, for example). Some of them are false positives as some packages (not many) include optional binaries that require extra libs (for instance, colord package -> colord-sane binary can report as "bad" if you don't have package sane installed because you don't have a scanner :) ). It may help you find more broken things directly instead of by chance. #!/bin/bash # # Search all binaries in $PATH for missing shared libs IFS=: for BINDIR in ${PATH}; do BINS=$(find "${BINDIR}" -type f -printf "%p:") for BIN in ${BINS}; do ldd "${BIN}" 2>/dev/null | grep -i "not found" | cut -d ' ' -f1 | \ xargs -I '{}' printf "${BIN},%s\n" '{}' done done It prints out a CSV-type file, just change that final printf format to your liking. -te [1] wget https://raw.githubusercontent.com/troyengel/scripts/master/badlibs.sh
Hello Troy, 2015-01-18 19:47 GMT+00:00 Troy Engel <troyengel+arch@gmail.com>:
On Sun, Jan 18, 2015 at 1:31 PM, Ralf Mardorf <ralf.mardorf@rocketmail.com> wrote:
On Sun, 18 Jan 2015 20:24:54 +0100, Damjan Georgievski wrote:
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing.
Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything.
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
Here's another little script[1] that might help you, Pal -- it looks at all binaries in $PATH for any missing shared libraries (it would have caught your firefox problem, for example). Some of them are false positives as some packages (not many) include optional binaries that require extra libs (for instance, colord package -> colord-sane binary can report as "bad" if you don't have package sane installed because you don't have a scanner :) ). It may help you find more broken things directly instead of by chance.
#!/bin/bash # # Search all binaries in $PATH for missing shared libs
IFS=: for BINDIR in ${PATH}; do BINS=$(find "${BINDIR}" -type f -printf "%p:") for BIN in ${BINS}; do ldd "${BIN}" 2>/dev/null | grep -i "not found" | cut -d ' ' -f1 | \ xargs -I '{}' printf "${BIN},%s\n" '{}' done done
It prints out a CSV-type file, just change that final printf format to your liking.
-te
[1] wget https://raw.githubusercontent.com/troyengel/scripts/master/badlibs.sh
Troy, thank you very much for this script. I'm running it now. -- Regards from Pal
2015-01-18 19:47 GMT+00:00 Troy Engel <troyengel+arch@gmail.com>:
On Sun, Jan 18, 2015 at 1:31 PM, Ralf Mardorf <ralf.mardorf@rocketmail.com> wrote:
On Sun, 18 Jan 2015 20:24:54 +0100, Damjan Georgievski wrote:
After I reinstalled gcc-libs package, I can start firefox.
Your system might still have broken packages after those conversions you were doing.
Use pacman {-Q --query} with -k, --check check that package files exist (-kk for file properties) to check everything.
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
Here's another little script[1] that might help you, Pal -- it looks at all binaries in $PATH for any missing shared libraries (it would have caught your firefox problem, for example). Some of them are false positives as some packages (not many) include optional binaries that require extra libs (for instance, colord package -> colord-sane binary can report as "bad" if you don't have package sane installed because you don't have a scanner :) ). It may help you find more broken things directly instead of by chance.
#!/bin/bash # # Search all binaries in $PATH for missing shared libs
IFS=: for BINDIR in ${PATH}; do BINS=$(find "${BINDIR}" -type f -printf "%p:") for BIN in ${BINS}; do ldd "${BIN}" 2>/dev/null | grep -i "not found" | cut -d ' ' -f1 | \ xargs -I '{}' printf "${BIN},%s\n" '{}' done done
It prints out a CSV-type file, just change that final printf format to your liking.
-te
[1] wget https://raw.githubusercontent.com/troyengel/scripts/master/badlibs.sh
The output of this script is: find: "/home/cspal/GNUstep/Tools": No such file or directory /usr/bin/virt-host-validate,libaudit.so.1 /usr/bin/virt-host-validate,libaudit.so.1 /usr/bin/playerjoy,libboost_system.so.1.55.0 /usr/bin/playerjoy,libboost_system.so.1.55.0 /usr/bin/playerjoy,libboost_thread.so.1.55.0 /usr/bin/playerjoy,libboost_signals.so.1.55.0 /usr/bin/virtlockd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/gtkam,libgphoto2_port.so.10 /usr/bin/gphotofs,libgphoto2_port.so.10 /usr/bin/downgrader,libalpm.so.8 /usr/bin/sensord,librrd.so.4 /usr/bin/virt-host-validate,libaudit.so.1 /usr/bin/virt-host-validate,libaudit.so.1 /usr/bin/playerjoy,libboost_system.so.1.55.0 /usr/bin/playerjoy,libboost_system.so.1.55.0 /usr/bin/playerjoy,libboost_thread.so.1.55.0 /usr/bin/playerjoy,libboost_signals.so.1.55.0 /usr/bin/virtlockd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/libvirtd,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/virsh,libaudit.so.1 /usr/bin/gtkam,libgphoto2_port.so.10 /usr/bin/gphotofs,libgphoto2_port.so.10 /usr/bin/downgrader,libalpm.so.8 /usr/bin/sensord,librrd.so.4 So what to do eg. in the case of /usr/bin/gtkam,libgphoto2_port.so.10 ? -- Regards from Pal
On Sun, Jan 18, 2015 at 2:14 PM, Csányi Pál <csanyipal@gmail.com> wrote:
/usr/bin/virt-host-validate,libaudit.so.1 /usr/bin/playerjoy,libboost_system.so.1.55.0 /usr/bin/gtkam,libgphoto2_port.so.10 /usr/bin/downgrader,libalpm.so.8 /usr/bin/sensord,librrd.so.4
OK you have a couple problems that are a little different, but similar: libaudit.so.1 == reinstall "audit" package to get these libraries libboost_*.so.1.55.0 == recompile playerjoy against the new boost-libs (1.57) libgphoto2_port.so.10 == same thing as playerjoy, recompile against new libgphoto2 (port-12) libalpm.so.8 == that's pacman-4.1, recompile downgrader against pacman-4.2 libalpm.so.9 librrd.so.4 == ignore, optional dependency (or install rrdtool to shut it up) hth, -te
Am 18.01.2015 um 20:31 schrieb Ralf Mardorf:
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
If you don't use english as your system language you should use the following or the grep misses the localized output: sudo LANG=C pacman -Qk | grep -v "0 missing files" Uwe
On 01/18/2015 11:20 PM, Uwe Koloska wrote:
Am 18.01.2015 um 20:31 schrieb Ralf Mardorf:
I would ignore "0 missing files" to stay on top of things.
sudo pacman -Qk | grep -v "0 missing files"
If you don't use english as your system language you should use the following or the grep misses the localized output:
sudo LANG=C pacman -Qk | grep -v "0 missing files"
Or `pacman -Qkq` which gives the same result while preserving the language of the output. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
Hello again, the kernel panic error appeares again. I fix my desktop system with commands: lsblk mkdir /mnt/arch mount /dev/sda3 /mnt/arch systemd-nspawn -D /mnt/arch pacman -S base mkinitcpio -p linux exit reboot I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not? What would you do in my case? ( I'm not a bash and Arch linux guru. ) -- Regards from Pal
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again. Normally it shouldn't break by itself. -- damjan
Hi Damjan, 2015-01-30 19:39 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again.
If I could to know that.
Normally it shouldn't break by itself.
I just update my system every day. -- Regards from Pal
2015-01-30 20:04 GMT+01:00 Csányi Pál <csanyipal@gmail.com>:
Hi Damjan,
2015-01-30 19:39 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again.
If I could to know that.
Normally it shouldn't break by itself.
I just update my system every day.
I think it is broken somehow. Say, bash command starts and after a while freezes. Same in Midnight Commander. -- Regards from Pal
On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <csanyipal@gmail.com> wrote:
2015-01-30 20:04 GMT+01:00 Csányi Pál <csanyipal@gmail.com>:
Hi Damjan,
2015-01-30 19:39 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again.
If I could to know that.
Normally it shouldn't break by itself.
I just update my system every day.
I think it is broken somehow. Say, bash command starts and after a while freezes. Same in Midnight Commander.
Your pacman log and journalctl might give some clues. Of course, I'm guilty of using the "throw-it-out" method, because the concept of a repaired system just doesn't compare to an unbroken one, even if they're identical... -- vixsomnis
2015-01-30 20:33 GMT+01:00 Christian Demsar <vixsomnis@fastmail.com>:
On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <csanyipal@gmail.com> wrote:
2015-01-30 20:04 GMT+01:00 Csányi Pál <csanyipal@gmail.com>:
Hi Damjan,
2015-01-30 19:39 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again.
If I could to know that.
Normally it shouldn't break by itself.
I just update my system every day.
I think it is broken somehow. Say, bash command starts and after a while freezes. Same in Midnight Commander.
Your pacman log and journalctl might give some clues.
Of course, I'm guilty of using the "throw-it-out" method, because the concept of a repaired system just doesn't compare to an unbroken one, even if they're identical... -- vixsomnis
In 'journalctl -e' I see these lines: jan 30 11:00:58 csparch org.a11y.Bus[4553]: Activating service name='org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.Bus[4553]: Successfully activated service 'org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.atspi.Registry[4719]: SpiRegistry daemon is running with well-known name - org.a11y..atspi.Registry Are these lines all right? -- Regards from Pal
2015-01-30 21:10 GMT+01:00 Csányi Pál <csanyipal@gmail.com>:
2015-01-30 20:33 GMT+01:00 Christian Demsar <vixsomnis@fastmail.com>:
On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <csanyipal@gmail.com> wrote:
2015-01-30 20:04 GMT+01:00 Csányi Pál <csanyipal@gmail.com>:
Hi Damjan,
2015-01-30 19:39 GMT+01:00 Damjan Georgievski <gdamjan@gmail.com>:
I'm thinking now about following. Whether to purge my Desktop Arch linux installation from hard disk and install a fresh Arch linux again, or not?
What would you do in my case? ( I'm not a bash and Arch linux guru. )
First thing is, how did it happen to become broken again.
If I could to know that.
Normally it shouldn't break by itself.
I just update my system every day.
I think it is broken somehow. Say, bash command starts and after a while freezes. Same in Midnight Commander.
Your pacman log and journalctl might give some clues.
Of course, I'm guilty of using the "throw-it-out" method, because the concept of a repaired system just doesn't compare to an unbroken one, even if they're identical... -- vixsomnis
In 'journalctl -e' I see these lines: jan 30 11:00:58 csparch org.a11y.Bus[4553]: Activating service name='org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.Bus[4553]: Successfully activated service 'org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.atspi.Registry[4719]: SpiRegistry daemon is running with well-known name - org.a11y..atspi.Registry
Are these lines all right?
I suspect I have a virus mybe. So I just installed clamav but when I'm trying to start it with: 'sudo systemctl start clamd.service' I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details. 'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE) Any advices will be appreciated. -- Regards from Pal
Your pacman log and journalctl might give some clues.
I guess he meant more or less complete logs. Give a journalctl log of a boot where you had the issue together with a pacman log including your latest updates (maybe since the problem began/ reappeared together with exact dates)
In 'journalctl -e' I see these lines: jan 30 11:00:58 csparch org.a11y.Bus[4553]: Activating service name='org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.Bus[4553]: Successfully activated service 'org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.atspi.Registry[4719]: SpiRegistry daemon is running with well-known name - org.a11y..atspi.Registry
Are these lines all right?
Looks to be part of https://www.archlinux.org/packages/extra/i686/at-spi2-core/ so yes seems to be all right
I suspect I have a virus mybe.
You do know you are using linux and the probability you do have one is through the sky?
So I just installed clamav but when I'm trying to start it with:
'sudo systemctl start clamd.service'
I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details.
'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE)
It tells you to look in the logs. Did you do that?! Without wanting to be condescending: I don't think you should be using archlinux if you are not capable of looking through logs and searching google (I found the package for your "error" through a fast google search....)
Your pacman log and journalctl might give some clues.
I guess he meant more or less complete logs. Give a journalctl log of a boot where you had the issue together with a pacman log including your latest updates (maybe since the problem began/ reappeared together with exact dates)
In 'journalctl -e' I see these lines: jan 30 11:00:58 csparch org.a11y.Bus[4553]: Activating service name='org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.Bus[4553]: Successfully activated service 'org.a11y.atspi.Registry' jan 30 11:00:58 csparch org.a11y.atspi.Registry[4719]: SpiRegistry daemon is running with well-known name - org.a11y..atspi.Registry
Are these lines all right?
Looks to be part of https://www.archlinux.org/packages/extra/i686/at-spi2-core/ so yes seems to be all right
I suspect I have a virus mybe.
You do know you are using linux and the probability you do have one is through the sky?
I meant practically non-existent --Sorry, english isn't my first language
So I just installed clamav but when I'm trying to start it with:
'sudo systemctl start clamd.service'
I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details.
'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE)
It tells you to look in the logs. Did you do that?! Without wanting to be condescending: I don't think you should be using archlinux if you are not capable of looking through logs and searching google (I found the package for your "error" through a fast google search....)
So I just installed clamav but when I'm trying to start it with:
'sudo systemctl start clamd.service'
I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details.
'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE)
It tells you to look in the logs. Did you do that?! Without wanting to be condescending: I don't think you should be using archlinux if you are not capable of looking through logs and searching google (I found the package for your "error" through a fast google search....)
Honestly, the idea of looking through logs was very foreign to me when I started using linux. And Arch Linux was my first linux distro I actually got to know. I think Arch is an excellent place to learn these skills. Okay, so in regards to ClamAV, I encountered no errors [1] starting clamd with the service file in the clamav package [2]. [1] http://pastebin.com/vDSrAhje [2] http://pastebin.com/3Frbkf3B You should check your service file at "/usr/lib/systemd/system/clamd.service" and make sure it matches the one I uploaded to pastebin. If you can link a paste of your log at "/var/log/clamav/clamd.log", that would help. Your journalctl log can be captured using: journalctl -xe | tail -n 500 | tee journal.log ^^^ ^^^ Takes last 500 lines. Saves and prints output. Make sure to check these 500 lines that get printed to your terminal for anything sensitive, like passwords. NetworkManager doesn't show passwords in the log, but it does show network SSIDs and connection protocols, and other bits of information. There's probably more in there than you would guess (there is in mine). I had some kernel panic problems I couldn't diagnose with a much-used MSI P67 motherboard. I'm pretty sure it was a motherboard issue, since I'm using the same power supply, most of the same RAM, and the same storage (different motherboard and CPU) and I haven't encountered any more. If you decide to do a fresh install and you still get kernel panics, I'd guess it's hardware related. Like a broken SATA port or a loose connection. -- vixsomnis
So I just installed clamav but when I'm trying to start it with:
'sudo systemctl start clamd.service'
I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details.
'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE)
It tells you to look in the logs. Did you do that?! Without wanting to be condescending: I don't think you should be using archlinux if you are not capable of looking through logs and searching google (I found the package for your "error" through a fast google search....)
Honestly, the idea of looking through logs was very foreign to me when I started using linux. And Arch Linux was my first linux distro I actually got to know. I think Arch is an excellent place to learn these skills. Okay, so in regards to ClamAV, I encountered no errors [1] starting clamd with the service file in the clamav package [2]. [1] http://pastebin.com/vDSrAhje [2] http://pastebin.com/3Frbkf3B You should check your service file at "/usr/lib/systemd/system/clamd.service" and make sure it matches the one I uploaded to pastebin. If you can link a paste of your log at "/var/log/clamav/clamd.log", that would help. Your journalctl log can be captured using: journalctl -xe | tail -n 500 | tee journal.log ^^^ ^^^ Takes last 500 lines. Saves and prints output. Make sure to check these 500 lines that get printed to your terminal for anything sensitive, like passwords. NetworkManager doesn't show passwords in the log, but it does show network SSIDs and connection protocols, and other bits of information. There's probably more in there than you would guess (there is in mine). I had some kernel panic problems I couldn't diagnose with a much-used MSI P67 motherboard. I'm pretty sure it was a motherboard issue, since I'm using the same power supply, most of the same RAM, and the same storage (different motherboard and CPU) and I haven't encountered any more. If you decide to do a fresh install and you still get kernel panics, I'd guess it's hardware related. Like a broken SATA port or a loose connection. -- vixsomnis
2015-01-31 0:53 GMT+01:00 Christian Demsar <vixsomnis@fastmail.com>:
So I just installed clamav but when I'm trying to start it with:
'sudo systemctl start clamd.service'
I get: Job for clamd.service failed. See "systemctl status clamd.service" and "journalctl -xe" for details.
'systemctl status clamd.service' clamd.service - clamav daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since p 2015-01-30 21:14:04 CET; 10s ago Process: 9693 ExecStart=/usr/bin/clamd (code=exited, status=1/FAILURE)
It tells you to look in the logs. Did you do that?! Without wanting to be condescending: I don't think you should be using archlinux if you are not capable of looking through logs and searching google (I found the package for your "error" through a fast google search....)
Indeed. I find the solution at: https://wiki.manjaro.org/index.php?title=Clamav
Okay, so in regards to ClamAV, I encountered no errors [1] starting clamd with the service file in the clamav package [2].
You should check your service file at "/usr/lib/systemd/system/clamd.service" and make sure it matches the one I uploaded to pastebin.
I have the same /usr/lib/systemd/system/clamd.service file as you.
If you can link a paste of your log at "/var/log/clamav/clamd.log", that would help.
http://pastebin.com/RC9ZzYMs This log was I get before solve the clamav problem.
Your journalctl log can be captured using:
journalctl -xe | tail -n 500 | tee journal.log ^^^ ^^^ Takes last 500 lines. Saves and prints output.
Make sure to check these 500 lines that get printed to your terminal for anything sensitive, like passwords. NetworkManager doesn't show passwords in the log, but it does show network SSIDs and connection protocols, and other bits of information. There's probably more in there than you would guess (there is in mine).
I did check these 500 lines and don't find anything sensitive, like passwords. Only find the lines bellow and don't know whether are these lines all right: jan 30 21:19:09 csparch org.a11y.atspi.Registry[4719]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. jan 30 21:19:09 csparch org.a11y.Bus[4553]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. jan 30 21:19:16 csparch systemd[4450]: Stopping Default. -- Subject: Unit UNIT has begun shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I had some kernel panic problems I couldn't diagnose with a much-used MSI P67 motherboard. I'm pretty sure it was a motherboard issue, since I'm using the same power supply, most of the same RAM, and the same storage (different motherboard and CPU) and I haven't encountered any more. If you decide to do a fresh install and you still get kernel panics, I'd guess it's hardware related. Like a broken SATA port or a loose connection.
Well, my motherboard is Asus P5N-E SLI. I observe that that I can't use my DVD writer; it can't read neither any CD nor DVD. I must to disassemble this DVD writer and assemble my old IDE CD writer to can reach the broken system when had kernel panic. -- Regards from Pal
On Sat, Jan 31, 2015, at 12:13 PM, Csányi Pál wrote:
Indeed. I find the solution at: https://wiki.manjaro.org/index.php?title=Clamav
Okay, so in regards to ClamAV, I encountered no errors [1] starting clamd with the service file in the clamav package [2].
You should check your service file at "/usr/lib/systemd/system/clamd.service" and make sure it matches the one I uploaded to pastebin.
I have the same /usr/lib/systemd/system/clamd.service file as you.
If you can link a paste of your log at "/var/log/clamav/clamd.log", that would help.
This log was I get before solve the clamav problem.
Glad you solved that problem. Did it have to do with the "/var/lib/clamav/clamd.sock"? Permissions problem with creating the socket?
I did check these 500 lines and don't find anything sensitive, like passwords. Only find the lines bellow and don't know whether are these lines all right:
Oh, I was actually hoping you'd upload the file to pastebin so I could check it (why I recommended checking for sensitive info). I don't think having it would help me understand your issues, though. It might be a systemd bug?
I observe that that I can't use my DVD writer; it can't read neither any CD nor DVD. I must to disassemble this DVD writer and assemble my old IDE CD writer to can reach the broken system when had kernel panic.
At this point, I'd backup configuration files and home directories and do a full reinstall. Sounds like there's something going terribly wrong. Hopefully that works... -- vixsomnis
2015-01-31 21:20 GMT+01:00 Christian Demsar <vixsomnis@fastmail.com>: [...]
At this point, I'd backup configuration files and home directories and do a full reinstall. Sounds like there's something going terribly wrong. Hopefully that works...
Hmm, I'd first check if dmesg shows SATA error (bus reset, seek failed, etc) and if that is not the case, I'd do a memory test (memtest86 is very nice for this). Seeing that the OP is getting kernel panics, my first guess is memory problems (I fail to see how a bad HDD would cause panics), but I might be wrong... mvg, Guus
2015-01-31 23:12 GMT+01:00 Guus Snijders <gsnijders@gmail.com>:
2015-01-31 21:20 GMT+01:00 Christian Demsar <vixsomnis@fastmail.com>: [...]
At this point, I'd backup configuration files and home directories and do a full reinstall. Sounds like there's something going terribly wrong. Hopefully that works...
Hmm, I'd first check if dmesg shows SATA error (bus reset, seek failed, etc) and if that is not the case, I'd do a memory test (memtest86 is very nice for this). Seeing that the OP is getting kernel panics, my first guess is memory problems (I fail to see how a bad HDD would cause panics), but I might be wrong...
The output of dmesg is here: http://pastebin.com/9TnBGHqn I did not see any suspicious in it. Am I right? -- Regards from Pal
On Sun, 18 Jan 2015 20:01:27 +0100, Csányi Pál wrote:
I cn now login and start X Window, but say I can't run firefox. When started firefox I get error message: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory.
I've got Firefiox installed and it runs, but libstdc++[...] and lib32-libstdc++[...] aren't installed. [rocketmouse@archlinux ~]$ pacman -Q libstdc++5 lib32-libstdc++5 firefox error: package 'libstdc++5' was not found error: package 'lib32-libstdc++5' was not found firefox 35.0-1 "Package Contents usr/ usr/lib/ usr/lib/libstdc++.so.5 usr/lib/libstdc++.so.5.0.7" - https://www.archlinux.org/packages/extra/x86_64/libstdc++5/ libstdc++.so.6? What repositories are enabled by your /etc/pacman.conf ? cat /etc/pacman.conf
On Sun, 18 Jan 2015 19:45:18 +0100, Damjan Georgievski wrote:
check what files you have in /usr/lib64/ and why. if they are from packages remove those packages.
JFTR $ pacman -Qo /path/to/file/foo/bar /path/to/file/foo/bar is owned by... IIUC the OP is aware that /usr/lib64/ should be a link, so it likely is a link, assumed the OP didn't got out of bed on the wrong side and missed to take a look using ls.
On Sun, 18 Jan 2015 19:40:57 +0100, Csányi Pál wrote:
I did update almost every day.
Another shot in the dark I would try is to downgrade systemd. Actually I'm still using systemd 217-8 and didn't upgrade to 218-1. I always wait and read mails for a while before I upgrade systemd.
On Sun, 18 Jan 2015 19:28:27 +0100, Damjan Georgievski wrote:
which means /usr/lib64 is a directory on your system??
So the OP should ensure that it's a link by running: ls -ld /usr/lib*
participants (10)
-
"Jérôme M. Berger"
-
Christian Demsar
-
Csányi Pál
-
Damjan Georgievski
-
Guus Snijders
-
Oliver Temlin
-
Ralf Mardorf
-
Simon Hanna
-
Troy Engel
-
Uwe Koloska