muj
November 3, 2020, 7:13pm
1
I was just trying to setup the keyserver and auto retrieving keys in gpg.conf
and dirmngr.conf
then I realised gnupg isn’t in my home directory like it normally is after a fresh Arch install. I tried to install gnupg and I got the message saying reinstalling so, lol it is somewhere. I checked /etc couldn’t find it.
I had a little glance in the forum search but couldn’t find anyone asking this basic question. I’m sure I’m missing something that always seems to be the case.
I think it’s a hidden folder in home?
dalto
November 3, 2020, 7:22pm
3
It should be in ~/.gnupg
. Depending on how you are looking for it make sure that you are viewing hidden directories.
muj
November 3, 2020, 7:22pm
4
I checked with ls -la, before I posted. it isn’t there
after .gnome is .gtkrc then .icons
dalto
November 3, 2020, 7:25pm
5
If it isn’t there, just run the command gpg
and it will be created.
muj
November 3, 2020, 7:25pm
6
and then cancel with ctrl c?
muj
November 3, 2020, 7:29pm
8
yep got it thanks.
After I posted this whilst I was waiting I ran the journalctl -p err -e
and I’ve got loads of core dumps.
very little experience but from what I’ve read a core dump is when something crashes and a file gets sent to record it or something. but there’s no information just loads of numbers and stuff. When I tried to google it I can’t find anything. okay well no info that I understand
dalto
November 3, 2020, 7:31pm
9
Yeah, it is when something crashes. journalctl should tell you what is crashing.
It is a binary file. You can’t easily read it.
What does the full error in journalctl say?
muj
November 3, 2020, 7:33pm
10
oh snap I was looking to try to see what had crashed but I didn’t notice systemd. lol doesn’t sound good to me.
sudo journalctl -p err -e
[muj@Blackstone ~]$ sudo journalctl -p err -e
[sudo] password for muj:
#1 0x00007f7abb7a8659 n/a (libgobject-2.0.so.0 + 0x13659)
#2 0x00007f7abb7b613c n/a (libgobject-2.0.so.0 + 0x2113c)
#3 0x00007f7abb7b713d g_object_new_with_properties (libgobject-2.0.so.0 + 0x2213d)
#4 0x00007f7abb7b7c42 g_object_new (libgobject-2.0.so.0 + 0x22c42)
#5 0x00007f7abb88c007 g_task_new (libgio-2.0.so.0 + 0x9f007)
#6 0x00007f7abb8f7d44 n/a (libgio-2.0.so.0 + 0x10ad44)
#7 0x00007f7abb8f8016 n/a (libgio-2.0.so.0 + 0x10b016)
#8 0x00007f7abb8f8563 n/a (libgio-2.0.so.0 + 0x10b563)
#9 0x00007f7abb88e0f4 n/a (libgio-2.0.so.0 + 0xa10f4)
#10 0x00007f7abb88e129 n/a (libgio-2.0.so.0 + 0xa1129)
#11 0x00007f7abb9fb914 g_main_context_dispatch (libglib-2.0.so.0 + 0x52914)
#12 0x00007f7abba4f7d1 n/a (libglib-2.0.so.0 + 0xa67d1)
#13 0x00007f7abb9fae63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
#14 0x00007f7abb8eefe8 n/a (libgio-2.0.so.0 + 0x101fe8)
#15 0x00007f7abba28ce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#16 0x00007f7abb5413e9 start_thread (libpthread.so.0 + 0x93e9)
#17 0x00007f7abb6cc293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 3081:
#0 0x00007f7abb6c146f __poll (libc.so.6 + 0xf546f)
#1 0x00007f7abba4f75f n/a (libglib-2.0.so.0 + 0xa675f)
#2 0x00007f7abb9fa121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
#3 0x00007f7abb9fa172 n/a (libglib-2.0.so.0 + 0x51172)
#4 0x00007f7abba28ce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#5 0x00007f7abb5413e9 start_thread (libpthread.so.0 + 0x93e9)
#6 0x00007f7abb6cc293 __clone (libc.so.6 + 0x100293)
Nov 03 18:57:14 Blackstone systemd-coredump[3091]: Process 3087 (bt-adapter) of user 1000 dumped core.
Stack trace of thread 3087:
#0 0x00007fc757f50615 raise (libc.so.6 + 0x3d615)
#1 0x00007fc757f39862 abort (libc.so.6 + 0x26862)
#2 0x00007fc75830c084 n/a (libglib-2.0.so.0 + 0x1c084)
#3 0x00007fc7583668cd g_assertion_message_expr (libglib-2.0.so.0 + 0x768cd)
#4 0x000055f90e6156ca n/a (bt-adapter + 0x66ca)
#5 0x000055f90e613173 n/a (bt-adapter + 0x4173)
#6 0x00007fc757f3b152 __libc_start_main (libc.so.6 + 0x28152)
#7 0x000055f90e613c3e n/a (bt-adapter + 0x4c3e)
Stack trace of thread 3089:
#0 0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
#1 0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
#2 0x00007fc758341e63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
#3 0x00007fc758235fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
#4 0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#5 0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
#6 0x00007fc758013293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 3088:
#0 0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
#1 0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
#2 0x00007fc758341121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
#3 0x00007fc758341172 n/a (libglib-2.0.so.0 + 0x51172)
#4 0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#5 0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
#6 0x00007fc758013293 __clone (libc.so.6 + 0x100293)
lines 85-139/139 (END)
I have to get used to seeing and reading this type of content
dalto
November 3, 2020, 7:36pm
11
In this case, it is the process bt-adapter
which is the issue.
Potentially a misbehaving bt device.
That doesn’t mean systemd is crashing.
muj
November 3, 2020, 7:37pm
12
is that bluetooth or bt internet, sorry what is bt
muj
November 3, 2020, 7:39pm
14
how’d you know its not libglib-2.0.so.0 + 0x1c084
for example
in the future do I try to individually google those lines?
dalto
November 3, 2020, 7:41pm
15
That is a stacktrace. It applies to the thing above it.
This is the line that tells you what is crashing:
The stacktrace is the calls that application was making when it crashed.
muj
November 3, 2020, 7:43pm
16
deep breath. Just so much info when I have none. So the thing which is crashing will have some sort of recognisable name (if I look very closely)
dalto
November 3, 2020, 7:45pm
17
You want to find the lines that says
Process xxxx (process-name) of user yyyy dumped core.
In this case, the things between the parens is the name of the process.
The indented part is the stack trace.
muj
November 3, 2020, 7:46pm
18
1 min.
okay so when there’s a core dump, something has crashed so I need to find out what crashed. The process is the thing that crashed. so I’ll find the line and google that process right?
I don’t even have bluetooth running. I turned it off. the service is disabled
what is systemctl poweroff
from terminal I normally do just poweroff
[muj@Blackstone ~]$ sudo journalctl -p err -e
[sudo] password for muj:
#0 0x00007fc757f50615 raise (libc.so.6 + 0x3d615)
#1 0x00007fc757f39862 abort (libc.so.6 + 0x26862)
#2 0x00007fc75830c084 n/a (libglib-2.0.so.0 + 0x1c084)
#3 0x00007fc7583668cd g_assertion_message_expr (libglib-2.0.so.0 + 0x768cd)
#4 0x000055f90e6156ca n/a (bt-adapter + 0x66ca)
#5 0x000055f90e613173 n/a (bt-adapter + 0x4173)
#6 0x00007fc757f3b152 __libc_start_main (libc.so.6 + 0x28152)
#7 0x000055f90e613c3e n/a (bt-adapter + 0x4c3e)
Stack trace of thread 3089:
#0 0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
#1 0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
#2 0x00007fc758341e63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
#3 0x00007fc758235fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
#4 0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#5 0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
#6 0x00007fc758013293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 3088:
#0 0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
#1 0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
#2 0x00007fc758341121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
#3 0x00007fc758341172 n/a (libglib-2.0.so.0 + 0x51172)
#4 0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
#5 0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
#6 0x00007fc758013293 __clone (libc.so.6 + 0x100293)
-- Reboot --
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: Transaction timeout
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: Failed terminating the transaction
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
Nov 03 19:55:08 Blackstone kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x0033903c
Nov 03 19:55:13 Blackstone pulseaudio[1220]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.service not found.
that means the issue is still there and not sorted right? or is the bt-adapter lines from before the reboot I just did.
dalto
November 3, 2020, 7:59pm
19
Sure. That seems reasonable.
If you have bluetooth disabled but bt-adapter
is still running, that is probably why it is crashing
The long answer:
systemctl
is a command line interface to systemd. In this case, systemctl poweroff
tells systemd to poweroff the system.
The command poweroff
is part of the package systemd-compat
which provides backwards compatible commands for systemd. This is to keep compatibility with existing scripts and support people who don’t want to learn new commands.
If you look, poweroff
is probably a symbolic link to systemctl
The short answer:
They are the same.
dalto
November 3, 2020, 8:00pm
20
It is from before the reboot.
journalctl -b -p err
will only show errors since the last reboot.