Discussion:
Kernel panic - after upgrade
(too old to reply)
Csányi Pál
2015-01-18 14:22:27 UTC
Permalink
Hi,

I upgrade today my Arch linux desktop.
Later when I did a reboot, on the screen I can to read followings:

Failed to execute /init )error -2)
Kernel panic - not syncing: No working init found. Try passing init=
option to kernel. See Linux Documentation/init.txt for guidance.

I upgraded my system with yaourt-gui.

What can I do to get mz Arch linux desktop back?

--
Regards from Pal
Csányi Pál
2015-01-18 14:39:45 UTC
Permalink
2015-01-18 15:27 GMT+01:00 Savya <***@hawkradius.com>:
>
> On Sun, Jan 18, 2015, at 11:22 PM, Csányi Pál wrote:

>> I upgrade today my Arch linux desktop.
>> Later when I did a reboot, on the screen I can to read followings:
>>
>> Failed to execute /init )error -2)
>> Kernel panic - not syncing: No working init found. Try passing init=
>> option to kernel. See Linux Documentation/init.txt for guidance.
>>
>> I upgraded my system with yaourt-gui.
>>
>> What can I do to get mz Arch linux desktop back?

> I'm not completely sure, but I think you might try to pass the
> init=/usr/bin/systemd option to the kernel. Just edit the corresponding
> line in the bootloader and add this line to the end. In the long run,
> maybe you need to add the systemd hook to your initramfs?
>
> I'm not completely sure about this solution, so just check it out.

I did so but get another error:
Failed to execute /init (error -2)
Failed to execute /usr/bin/systemd (error -2). Attempting defaults...

--
Regards from Pal
Csányi Pál
2015-01-18 14:44:04 UTC
Permalink
2015-01-18 15:39 GMT+01:00 Csányi Pál <***@gmail.com>:
> 2015-01-18 15:27 GMT+01:00 Savya <***@hawkradius.com>:
>>
>> On Sun, Jan 18, 2015, at 11:22 PM, Csányi Pál wrote:
>
>>> I upgrade today my Arch linux desktop.
>>> Later when I did a reboot, on the screen I can to read followings:
>>>
>>> Failed to execute /init )error -2)
>>> Kernel panic - not syncing: No working init found. Try passing init=
>>> option to kernel. See Linux Documentation/init.txt for guidance.
>>>
>>> I upgraded my system with yaourt-gui.
>>>
>>> What can I do to get mz Arch linux desktop back?
>
>> I'm not completely sure, but I think you might try to pass the
>> init=/usr/bin/systemd option to the kernel. Just edit the corresponding
>> line in the bootloader and add this line to the end. In the long run,
>> maybe you need to add the systemd hook to your initramfs?
>>
>> I'm not completely sure about this solution, so just check it out.
>
> I did so but get another error:
> Failed to execute /init (error -2)
> Failed to execute /usr/bin/systemd (error -2). Attempting defaults...

I even tried with option:
init=/usr/bin/init

but that failed too.

--
Regards from Pal
Damien Robert
2015-01-18 15:06:14 UTC
Permalink
Csányi Pál wrote in message
<CAONhAovzSgs87pFfp1G0NiK_=u-Y-FTKWB6-8+***@mail.gmail.com>:
> I did so but get another error:
> Failed to execute /init (error -2)

You don't seem to have a valid /usr/bin/init anymore, try booting on an usb
key and see what happened to it.

> Failed to execute /usr/bin/systemd (error -2). Attempting defaults...

It should be init=/usr/lib/systemd/systemd
/usr/bin/systemd does not exist.
Csányi Pál
2015-01-18 15:12:13 UTC
Permalink
2015-01-18 16:06 GMT+01:00 Damien Robert
<damien.olivier.robert+***@gmail.com>:
> Csányi Pál wrote in message
> <CAONhAovzSgs87pFfp1G0NiK_=u-Y-FTKWB6-8+***@mail.gmail.com>:
>> I did so but get another error:
>> Failed to execute /init (error -2)
>
> You don't seem to have a valid /usr/bin/init anymore, try booting on an usb
> key and see what happened to it.
>
>> Failed to execute /usr/bin/systemd (error -2). Attempting defaults...
>
> It should be init=/usr/lib/systemd/systemd
> /usr/bin/systemd does not exist.

I booted with a systemrescuecd and want to repaire my Arch linux system.

How can I do that?

--
Regards from Pal
Giedrius Statkevičius
2015-01-18 15:19:54 UTC
Permalink
On 2015.01.18 17:12, Csányi Pál wrote:
> 2015-01-18 16:06 GMT+01:00 Damien Robert
> <damien.olivier.robert+***@gmail.com>:
>> Csányi Pál wrote in message
>> <CAONhAovzSgs87pFfp1G0NiK_=u-Y-FTKWB6-8+***@mail.gmail.com>:
>>> I did so but get another error:
>>> Failed to execute /init (error -2)
>>
>> You don't seem to have a valid /usr/bin/init anymore, try booting on an usb
>> key and see what happened to it.
>>
>>> Failed to execute /usr/bin/systemd (error -2). Attempting defaults...
>>
>> It should be init=/usr/lib/systemd/systemd
>> /usr/bin/systemd does not exist.
>
> I booted with a systemrescuecd and want to repaire my Arch linux system.
>
> How can I do that?
>

Maybe try reinstalling the whole base package group?
--
Thanks,
Giedrius
Csányi Pál
2015-01-18 15:23:45 UTC
Permalink
2015-01-18 16:19 GMT+01:00 Giedrius Statkevičius
<***@gmail.com>:
> On 2015.01.18 17:12, Csányi Pál wrote:
>> 2015-01-18 16:06 GMT+01:00 Damien Robert
>> <damien.olivier.robert+***@gmail.com>:
>>> Csányi Pál wrote in message
>>> <CAONhAovzSgs87pFfp1G0NiK_=u-Y-FTKWB6-8+***@mail.gmail.com>:
>>>> I did so but get another error:
>>>> Failed to execute /init (error -2)
>>>
>>> You don't seem to have a valid /usr/bin/init anymore, try booting on an usb
>>> key and see what happened to it.
>>>
>>>> Failed to execute /usr/bin/systemd (error -2). Attempting defaults...
>>>
>>> It should be init=/usr/lib/systemd/systemd
>>> /usr/bin/systemd does not exist.
>>
>> I booted with a systemrescuecd and want to repaire my Arch linux system.
>>
>> How can I do that?
>>
>
> Maybe try reinstalling the whole base package group?

I think I must to chroot into my Arch linux system.
How can I do that?

--
Regards from Pal
Oliver Temlin
2015-01-18 15:30:12 UTC
Permalink
On January 18, 2015 4:23:45 PM CET, "Csányi Pál" <***@gmail.com> wrote:
>I think I must to chroot into my Arch linux system.
>How can I do that?
Just mount your rootfs to /mnt and boot to /mnt/boot and `sudo chroot /mnt', it should be available on your rescue cd.
Or if on the arch install media, substitute arch-chroot for chroot, and use the root user instead of sudo.
--Oliver Temlin
Ralf Mardorf
2015-01-18 16:02:04 UTC
Permalink
On Sun, 18 Jan 2015 16:30:12 +0100, Oliver Temlin wrote:
> Just mount your rootfs to /mnt and boot to /mnt/boot and `sudo
> chroot /mnt', it should be available on your rescue cd.

Assumed the rescue CD should come with systemd, instead of chroot you
could use systemd-nspawn.

Mount the rootfs and then run

sudo systemd-nspawn -D /mount/point
Csányi Pál
2015-01-18 16:49:37 UTC
Permalink
2015-01-18 17:02 GMT+01:00 Ralf Mardorf <***@rocketmail.com>:
> On Sun, 18 Jan 2015 16:30:12 +0100, Oliver Temlin wrote:
>> Just mount your rootfs to /mnt and boot to /mnt/boot and `sudo
>> chroot /mnt', it should be available on your rescue cd.
>
> Assumed the rescue CD should come with systemd, instead of chroot you
> could use systemd-nspawn.
>
> Mount the rootfs and then run
>
> sudo systemd-nspawn -D /mount/point

What I did sofar is the following:

Boot with Arch linux live cd.
lsblk
Note: my root / partition is on /dev/sda3
mkdir /mnt/arch
mount /dev/sda3 /mnt/arch
systemd-nspawn -D /mnt/arch
mkinitcpio -p linux

Here I exit from the prompt and reboot the machine, but get the same
error message: can't run init.

What did I wrong?

--
Regards from Pal
Oliver Temlin
2015-01-18 16:57:34 UTC
Permalink
On January 18, 2015 5:49:37 PM CET, "Csányi Pál" <***@gmail.com> wrote:
>What I did sofar is the following:
>
>Boot with Arch linux live cd.
>lsblk
>Note: my root / partition is on /dev/sda3
>mkdir /mnt/arch
>mount /dev/sda3 /mnt/arch
>systemd-nspawn -D /mnt/arch
>mkinitcpio -p linux
>
>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, but with the files of systemd.
Just run `pacman -S base' after systemd-nspawn.
--Oliver Temlin
Troy Engel
2015-01-18 17:03:59 UTC
Permalink
On Sun, Jan 18, 2015 at 10:57 AM, Oliver Temlin <***@gmail.com> wrote:
> On January 18, 2015 5:49:37 PM CET, "Csányi Pál" <***@gmail.com> wrote:
>>mkinitcpio -p linux
>>
>
> You missed that the base group should be reinstalled, as the error is not with the ramdisk, but with the files of systemd.
> Just run `pacman -S base' after systemd-nspawn.

To try and help you out I ran a listing of what's in the normal
(default options) initramfs. The only change I make is to add lvm2,
everything else is out of the box.

http://pastebin.com/hGT6jSN4

$ egrep -v "^(#|$)" /etc/mkinitcpio.conf
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect modconf block lvm2 filesystems keyboard fsck"

The output in the pastebin shows: /sbin/init -> /usr/bin/init ->
/usr/bin/busybox

hth,
-te
Ralf Mardorf
2015-01-18 17:35:30 UTC
Permalink
On Sun, 18 Jan 2015 11:03:59 -0600, Troy Engel wrote:
> HOOKS="base udev autodetect modconf block lvm2 filesystems keyboard fsck"

HOOKS="base udev autodetect modconf block filesystems keyboard vboxhost"

I removed fsck ;). Use mkinitcpio fsck hook and rw on the kernel
commandline or don't use the hook and ro on the kernel
commandline.
Troy Engel
2015-01-18 17:49:16 UTC
Permalink
On Sun, Jan 18, 2015 at 11:35 AM, Ralf Mardorf
<***@rocketmail.com> wrote:
>
> HOOKS="base udev autodetect modconf block filesystems keyboard vboxhost"
>
> I removed fsck ;). Use mkinitcpio fsck hook and rw on the kernel
> commandline or don't use the hook and ro on the kernel
> commandline.

I think you missed the point where we're trying to help someone with
what the defaults are and things should look like to try and help him
save his system from disaster.

$ tar -JxOf /var/cache/pacman/pkg/mkinitcpio-18-2-any.pkg.tar.xz
etc/mkinitcpio.conf | grep ^HOOKS
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"

Right now he's in a bad way, let's not get off into the weeds; e.g.
you have virtualbox so you'd just screw him up more if he tried to use
your HOOKS line.

-te
Csányi Pál
2015-01-18 17:12:42 UTC
Permalink
2015-01-18 17:57 GMT+01:00 Oliver Temlin <***@gmail.com>:
> On January 18, 2015 5:49:37 PM CET, "Csányi Pál" <***@gmail.com> wrote:
>>What I did sofar is the following:
>>
>>Boot with Arch linux live cd.
>>lsblk
>>Note: my root / partition is on /dev/sda3
>>mkdir /mnt/arch
>>mount /dev/sda3 /mnt/arch
>>systemd-nspawn -D /mnt/arch
>>mkinitcpio -p linux
>>
>>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, but with the files of systemd.
> Just run `pacman -S base' after systemd-nspawn.

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.

What can I do now?

--
Regards from Pal
Damjan Georgievski
2015-01-18 17:20:43 UTC
Permalink
>
> >>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

--
damjan
Ralf Mardorf
2015-01-18 17:40:09 UTC
Permalink
On Sun, 18 Jan 2015 18:35:13 +0100, Csányi Pál wrote:
> 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?

Don't post to [archaudio-discuss], but to [arch-general] ;).
Csányi Pál
2015-01-18 17:49:36 UTC
Permalink
2015-01-18 18:20 GMT+01:00 Damjan Georgievski <***@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
Troy Engel
2015-01-18 18:04:12 UTC
Permalink
On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <***@gmail.com> wrote:
> 2015-01-18 18:20 GMT+01:00 Damjan Georgievski <***@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
Csányi Pál
2015-01-18 18:24:00 UTC
Permalink
2015-01-18 19:04 GMT+01:00 Troy Engel <troyengel+***@gmail.com>:
> On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <***@gmail.com> wrote:
>> 2015-01-18 18:20 GMT+01:00 Damjan Georgievski <***@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
Ralf Mardorf
2015-01-18 18:38:59 UTC
Permalink
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+***@gmail.com>:
> > On Sun, Jan 18, 2015 at 11:49 AM, Csányi Pál <***@gmail.com>
> > wrote:
> >> 2015-01-18 18:20 GMT+01:00 Damjan Georgievski <***@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/
Damjan Georgievski
2015-01-18 18:28:27 UTC
Permalink
> >> 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
Csányi Pál
2015-01-18 18:40:57 UTC
Permalink
2015-01-18 19:28 GMT+01:00 Damjan Georgievski <***@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
Damjan Georgievski
2015-01-18 18:45:18 UTC
Permalink
On 18 January 2015 at 19:40, Csányi Pál <***@gmail.com> wrote:
>
> 2015-01-18 19:28 GMT+01:00 Damjan Georgievski <***@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-together/

» 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
Csányi Pál
2015-01-18 19:01:27 UTC
Permalink
2015-01-18 19:45 GMT+01:00 Damjan Georgievski <***@gmail.com>:
> On 18 January 2015 at 19:40, Csányi Pál <***@gmail.com> wrote:
>>
>> 2015-01-18 19:28 GMT+01:00 Damjan Georgievski <***@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-together/
>
> » 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
Troy Engel
2015-01-18 19:05:53 UTC
Permalink
On Sun, Jan 18, 2015 at 1:01 PM, Csányi Pál <***@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
Ralf Mardorf
2015-01-18 19:21:21 UTC
Permalink
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.
Csányi Pál
2015-01-18 19:22:09 UTC
Permalink
2015-01-18 19:05 GMT+00:00 Troy Engel <troyengel+***@gmail.com>:
> On Sun, Jan 18, 2015 at 1:01 PM, Csányi Pál <***@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
Damjan Georgievski
2015-01-18 19:24:54 UTC
Permalink
> 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
Ralf Mardorf
2015-01-18 19:31:19 UTC
Permalink
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"
Csányi Pál
2015-01-18 19:47:13 UTC
Permalink
2015-01-18 19:31 GMT+00:00 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
Ralf Mardorf
2015-01-18 20:01:59 UTC
Permalink
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?
Csányi Pál
2015-01-18 20:04:21 UTC
Permalink
2015-01-18 20:01 GMT+00:00 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
Oliver Temlin
2015-01-18 20:12:26 UTC
Permalink
On 18 January 2015 at 21:04, Csányi Pál <***@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
Ralf Mardorf
2015-01-18 20:40:43 UTC
Permalink
On Sun, 18 Jan 2015 21:12:26 +0100, Oliver Temlin wrote:
> On 18 January 2015 at 21:04, Csányi Pál <***@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.

[***@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/.
Troy Engel
2015-01-18 20:57:29 UTC
Permalink
On Sun, Jan 18, 2015 at 2:40 PM, 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 <***@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
Ralf Mardorf
2015-01-18 21:30:43 UTC
Permalink
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:

[***@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.
Ralf Mardorf
2015-01-18 22:34:27 UTC
Permalink
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/
Ralf Mardorf
2015-01-18 20:13:59 UTC
Permalink
On Sun, 18 Jan 2015 20:04:21 +0000, Csányi Pál wrote:
> 2015-01-18 20:01 GMT+00:00 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
Troy Engel
2015-01-18 19:47:30 UTC
Permalink
On Sun, Jan 18, 2015 at 1:31 PM, 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
Csányi Pál
2015-01-18 20:09:07 UTC
Permalink
Hello Troy,

2015-01-18 19:47 GMT+00:00 Troy Engel <troyengel+***@gmail.com>:
> On Sun, Jan 18, 2015 at 1:31 PM, 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
Csányi Pál
2015-01-18 20:14:09 UTC
Permalink
2015-01-18 19:47 GMT+00:00 Troy Engel <troyengel+***@gmail.com>:
> On Sun, Jan 18, 2015 at 1:31 PM, 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
Troy Engel
2015-01-18 20:26:25 UTC
Permalink
On Sun, Jan 18, 2015 at 2:14 PM, Csányi Pál <***@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
Uwe Koloska
2015-01-18 22:20:29 UTC
Permalink
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
Jérôme M. Berger
2015-01-19 19:27:01 UTC
Permalink
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:***@free.fr
http://jeberger.free.fr
Jabber: ***@jabber.fr
Csányi Pál
2015-01-30 18:17:17 UTC
Permalink
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
Damjan Georgievski
2015-01-30 18:39:48 UTC
Permalink
> 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
Csányi Pál
2015-01-30 19:04:11 UTC
Permalink
Hi Damjan,

2015-01-30 19:39 GMT+01:00 Damjan Georgievski <***@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
Csányi Pál
2015-01-30 19:21:34 UTC
Permalink
2015-01-30 20:04 GMT+01:00 Csányi Pál <***@gmail.com>:
> Hi Damjan,
>
> 2015-01-30 19:39 GMT+01:00 Damjan Georgievski <***@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
Christian Demsar
2015-01-30 19:33:58 UTC
Permalink
On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <***@gmail.com> wrote:
>2015-01-30 20:04 GMT+01:00 Csányi Pál <***@gmail.com>:
>> Hi Damjan,
>>
>> 2015-01-30 19:39 GMT+01:00 Damjan Georgievski <***@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
Csányi Pál
2015-01-30 20:10:17 UTC
Permalink
2015-01-30 20:33 GMT+01:00 Christian Demsar <***@fastmail.com>:
> On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <***@gmail.com> wrote:
>>2015-01-30 20:04 GMT+01:00 Csányi Pál <***@gmail.com>:
>>> Hi Damjan,
>>>
>>> 2015-01-30 19:39 GMT+01:00 Damjan Georgievski <***@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
Csányi Pál
2015-01-30 20:18:02 UTC
Permalink
2015-01-30 21:10 GMT+01:00 Csányi Pál <***@gmail.com>:
> 2015-01-30 20:33 GMT+01:00 Christian Demsar <***@fastmail.com>:
>> On January 30, 2015 2:21:34 PM EST, "Csányi Pál" <***@gmail.com> wrote:
>>>2015-01-30 20:04 GMT+01:00 Csányi Pál <***@gmail.com>:
>>>> Hi Damjan,
>>>>
>>>> 2015-01-30 19:39 GMT+01:00 Damjan Georgievski <***@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
Simon Hanna
2015-01-30 21:07:18 UTC
Permalink
>
>
> >> 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....)
Simon Hanna
2015-01-30 21:19:14 UTC
Permalink
>> 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....)
>
Christian Demsar
2015-01-30 23:53:30 UTC
Permalink
> > 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
Christian Demsar
2015-01-30 23:56:32 UTC
Permalink
> > 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
Csányi Pál
2015-01-31 17:13:21 UTC
Permalink
2015-01-31 0:53 GMT+01:00 Christian Demsar <***@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].

> [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.

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
Christian Demsar
2015-01-31 20:20:39 UTC
Permalink
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].
>
> > [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.
>
> 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.

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
Guus Snijders
2015-01-31 22:12:15 UTC
Permalink
2015-01-31 21:20 GMT+01:00 Christian Demsar <***@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
Csányi Pál
2015-02-01 11:41:01 UTC
Permalink
2015-01-31 23:12 GMT+01:00 Guus Snijders <***@gmail.com>:
> 2015-01-31 21:20 GMT+01:00 Christian Demsar <***@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
Csányi Pál
2015-02-01 12:48:10 UTC
Permalink
2015-02-01 13:42 GMT+01:00 Guus Snijders <***@gmail.com>:
> Op 1 feb. 2015 12:41 schreef "Csányi Pál" <***@gmail.com> het
> volgende:
>
>> 2015-01-31 23:12 GMT+01:00 Guus Snijders <***@gmail.com>:
>> > 2015-01-31 21:20 GMT+01:00 Christian Demsar <***@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?
>
> A couple of things i noticed:
> -Nvidea complaining about not having a textmode driver configured
> - ext4 mentions 14 errors on sda4
>
> I'm not sure if these are serious or not. Could you try the memtest first?
> Bad memory can cause very strange errors and is easy to test (takes time,
> though).

Before I start the memtest I ask an advice: how long should I run the memtest?

--
Regards from Pal
Marcel Kleinfeller
2015-02-01 16:42:16 UTC
Permalink
Just do two or three passes that should be enough.
Am 01.02.2015 um 13:48 schrieb Csányi Pál:
> 2015-02-01 13:42 GMT+01:00 Guus Snijders <***@gmail.com>:
>> Op 1 feb. 2015 12:41 schreef "Csányi Pál" <***@gmail.com> het
>> volgende:
>>
>>> 2015-01-31 23:12 GMT+01:00 Guus Snijders <***@gmail.com>:
>>>> 2015-01-31 21:20 GMT+01:00 Christian Demsar <***@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?
>> A couple of things i noticed:
>> -Nvidea complaining about not having a textmode driver configured
>> - ext4 mentions 14 errors on sda4
>>
>> I'm not sure if these are serious or not. Could you try the memtest first?
>> Bad memory can cause very strange errors and is easy to test (takes time,
>> though).
> Before I start the memtest I ask an advice: how long should I run the memtest?
>
Csányi Pál
2015-02-02 16:29:25 UTC
Permalink
2015-02-01 17:42 GMT+01:00 Marcel Kleinfeller <***@oompf.de>:
> Just do two or three passes that should be enough.
> Am 01.02.2015 um 13:48 schrieb Csányi Pál:
>
>> 2015-02-01 13:42 GMT+01:00 Guus Snijders <***@gmail.com>:
>>>
>>> Op 1 feb. 2015 12:41 schreef "Csányi Pál" <***@gmail.com> het
>>> volgende:
>>>
>>>> 2015-01-31 23:12 GMT+01:00 Guus Snijders <***@gmail.com>:
>>>>>
>>>>> 2015-01-31 21:20 GMT+01:00 Christian Demsar <***@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?
>>>
>>> A couple of things i noticed:
>>> -Nvidea complaining about not having a textmode driver configured
>>> - ext4 mentions 14 errors on sda4
>>>
>>> I'm not sure if these are serious or not. Could you try the memtest
>>> first?
>>> Bad memory can cause very strange errors and is easy to test (takes time,
>>> though).
>>
>> Before I start the memtest I ask an advice: how long should I run the
>> memtest?

I did the memtest twice: yesterday two pass with 0 error and today two
pass with 0 error, all together this takes 8 h 30 min.

So I can tell that the RAM is all right on this desktop PC box, right?

What do you advices me, what to do further?
Should I try to investigate the sda4 error or not?
Can I do something with the nvidia error?
Or just do a fresh install of my Arch system ( but first backup /etc/
and $HOME directory with all my setup? )

--
Regards from Pal
Ralf Mardorf
2015-02-02 17:27:15 UTC
Permalink
On Mon, 2 Feb 2015 17:29:25 +0100, Csányi Pál wrote:
> So I can tell that the RAM is all right on this desktop PC box, right?

Most likely the main memory is _not_ defect. However, when passing the
memtest it's without guarantee that the RAM is ok and if there would
have been errors, it also wouldn't necessarily mean that the RAM is
broken. Memtest isn't perfect. But since we are talking about "Voodoo",
have you checked, if your power supply is able to handle the worst case
scenario? Have you replaced the battery? Power supply and the battery
unlikely are the culprits either, but both could cause "Voodoo" too.

I suspect that it's a software issue or unlikely a very wicked
hardware issue.

Have you checked the homepage of your mobo regarding BIOS updates (or
whatever the "BIOS" is called nowadays). Are there changelogs that
ever mentioned Linux incompatibilities?

The very last thing I would do, is to care about strange "Voodoo". I
would test Arch's Linux LTS, downgrade systemd and similar.

Most likely it's a user issue, or a complete incompatibility to Linux
of some hardware component. I returned several times hardware that was
mentioned by the vendors by Linux communities as Linux compatible and
not seldom it put out, that there was one revision, chipset nobody cared
about, neither the communities, nor the vendors or nobody did use all
features of the hardware.

Backup your current install and make a clean new install. Replace the
default kernel with
https://www.archlinux.org/packages/core/x86_64/linux-lts/
or with linux-rt-lts from the Arch Audio repository or from AUR, since
it's 3.10..., don't worry about the Rt-patch, when instlling it just
for testing purpose.
Csányi Pál
2015-02-02 18:27:57 UTC
Permalink
2015-02-02 18:27 GMT+01:00 Ralf Mardorf <***@rocketmail.com>:
> On Mon, 2 Feb 2015 17:29:25 +0100, Csányi Pál wrote:
>> So I can tell that the RAM is all right on this desktop PC box, right?
>
> Most likely the main memory is _not_ defect. However, when passing the
> memtest it's without guarantee that the RAM is ok and if there would
> have been errors, it also wouldn't necessarily mean that the RAM is
> broken. Memtest isn't perfect. But since we are talking about "Voodoo",
> have you checked, if your power supply is able to handle the worst case
> scenario? Have you replaced the battery? Power supply and the battery
> unlikely are the culprits either, but both could cause "Voodoo" too.

I don't know how to check if my power supply is able to handle the
worst case scenario?

No, I haven't replaced the battery.

> Have you checked the homepage of your mobo regarding BIOS updates (or
> whatever the "BIOS" is called nowadays). Are there changelogs that
> ever mentioned Linux incompatibilities?

No, I did not checked that. I did not dare even to update the BIOS.

> The very last thing I would do, is to care about strange "Voodoo". I
> would test Arch's Linux LTS, downgrade systemd and similar.
>
> Most likely it's a user issue, or a complete incompatibility to Linux
> of some hardware component. I returned several times hardware that was
> mentioned by the vendors by Linux communities as Linux compatible and
> not seldom it put out, that there was one revision, chipset nobody cared
> about, neither the communities, nor the vendors or nobody did use all
> features of the hardware.

This hardware on which I'm running my Arch linux system I have used
since 3-4 years. During this time I did run on this hardware Debian
GNU/Linux SID, Arch linux, Parabolagnulinux and finally Arch linux
again. Wowever, so far I did not have any hardware issues, as far as I
know.

> Backup your current install and make a clean new install. Replace the
> default kernel with
> https://www.archlinux.org/packages/core/x86_64/linux-lts/
> or with linux-rt-lts from the Arch Audio repository or from AUR, since
> it's 3.10..., don't worry about the Rt-patch, when instlling it just
> for testing purpose.

I shall do that. Thank you for your advices and support.

--
Regards from Pal
pete nikolic
2015-02-02 19:23:29 UTC
Permalink
On Mon, 2 Feb 2015 19:27:57 +0100
Csányi Pál <***@gmail.com> wrote:

> 2015-02-02 18:27 GMT+01:00 Ralf Mardorf <***@rocketmail.com>:
> > On Mon, 2 Feb 2015 17:29:25 +0100, Csányi Pál wrote:
> >> So I can tell that the RAM is all right on this desktop PC box, right?
> >
> > Most likely the main memory is _not_ defect. However, when passing the
> > memtest it's without guarantee that the RAM is ok and if there would
> > have been errors, it also wouldn't necessarily mean that the RAM is
> > broken. Memtest isn't perfect. But since we are talking about "Voodoo",
> > have you checked, if your power supply is able to handle the worst case
> > scenario? Have you replaced the battery? Power supply and the battery
> > unlikely are the culprits either, but both could cause "Voodoo" too.
>
> I don't know how to check if my power supply is able to handle the
> worst case scenario?
Put your machine under heavy load and connect a digital volt meter to the +5 0v
lines ie Red and Black wires going to a floppy drive cable then check the yellow
and black 12 volts if they vary too much under load but recover when load is
removed the the PSU is not big enough .



>
> No, I haven't replaced the battery.
>
> > Have you checked the homepage of your mobo regarding BIOS updates (or
> > whatever the "BIOS" is called nowadays). Are there changelogs that
> > ever mentioned Linux incompatibilities?
>
> No, I did not checked that. I did not dare even to update the BIOS.
>
> > The very last thing I would do, is to care about strange "Voodoo". I
> > would test Arch's Linux LTS, downgrade systemd and similar.
> >
> > Most likely it's a user issue, or a complete incompatibility to Linux
> > of some hardware component. I returned several times hardware that was
> > mentioned by the vendors by Linux communities as Linux compatible and
> > not seldom it put out, that there was one revision, chipset nobody cared
> > about, neither the communities, nor the vendors or nobody did use all
> > features of the hardware.
>
> This hardware on which I'm running my Arch linux system I have used
> since 3-4 years. During this time I did run on this hardware Debian
> GNU/Linux SID, Arch linux, Parabolagnulinux and finally Arch linux
> again. Wowever, so far I did not have any hardware issues, as far as I
> know.
>
> > Backup your current install and make a clean new install. Replace the
> > default kernel with
> > https://www.archlinux.org/packages/core/x86_64/linux-lts/
> > or with linux-rt-lts from the Arch Audio repository or from AUR, since
> > it's 3.10..., don't worry about the Rt-patch, when instlling it just
> > for testing purpose.
>
> I shall do that. Thank you for your advices and support.
>


Pete .


--
Illegitimi non carborundum . ro for the purists out there
Noli nothis permittere te terere.
Csányi Pál
2015-02-06 10:19:08 UTC
Permalink
2015-02-02 18:27 GMT+01:00 Ralf Mardorf <***@rocketmail.com>:

> Most likely it's a user issue,

I confess I did many times system upgrade without taking into account
the advice given here:
https://wiki.archlinux.org/index.php/General_recommendations

<quoted>
it is imperative to keep up to date with changes in Arch Linux that
require manual intervention before upgrading your system. Subscribe to
the arch-announce mailing list or check the front page Arch news every
time before you update. etc..
</quote>

> Backup your current install and make a clean new install. Replace the
> default kernel with
> https://www.archlinux.org/packages/core/x86_64/linux-lts/
> or with linux-rt-lts from the Arch Audio repository or from AUR, since
> it's 3.10..., don't worry about the Rt-patch, when instlling it just
> for testing purpose.

I did so. I have now a fresh install of Arch linux with kernel 3.14.31-1-lts .

--
Regards from Pal
Ralf Mardorf
2015-01-18 19:17:55 UTC
Permalink
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.

[***@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
Ralf Mardorf
2015-01-18 19:04:58 UTC
Permalink
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.
Ralf Mardorf
2015-01-18 18:48:44 UTC
Permalink
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.
Ralf Mardorf
2015-01-18 18:56:18 UTC
Permalink
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*
Maykel Franco
2015-01-18 15:32:32 UTC
Permalink
El 18/1/2015 16:23, "Csányi Pál" <***@gmail.com> escribió:
>
> 2015-01-18 16:19 GMT+01:00 Giedrius Statkevičius
> <***@gmail.com>:
> > On 2015.01.18 17:12, Csányi Pál wrote:
> >> 2015-01-18 16:06 GMT+01:00 Damien Robert
> >> <damien.olivier.robert+***@gmail.com>:
> >>> Csányi Pál wrote in message
> >>> <CAONhAovzSgs87pFfp1G0NiK_=u-Y-FTKWB6-8+***@mail.gmail.com>:
> >>>> I did so but get another error:
> >>>> Failed to execute /init (error -2)
> >>>
> >>> You don't seem to have a valid /usr/bin/init anymore, try booting on
an usb
> >>> key and see what happened to it.
> >>>
> >>>> Failed to execute /usr/bin/systemd (error -2). Attempting
defaults...
> >>>
> >>> It should be init=/usr/lib/systemd/systemd
> >>> /usr/bin/systemd does not exist.
> >>
> >> I booted with a systemrescuecd and want to repaire my Arch linux
system.
> >>
> >> How can I do that?
> >>
> >
> > Maybe try reinstalling the whole base package group?
>
> I think I must to chroot into my Arch linux system.
> How can I do that?
>
> --
> Regards from Pal

You may boot with archlinux ISO. Then install pacstrap base and base-devel
Continue reading on narkive:
Loading...