Created attachment 1193917 [details]
File: backtrace

Created attachment 1193918 [details]
File: cgroup

Created attachment 1193919 [details]
File: core_backtrace

Created attachment 1193920 [details]
File: dso_list

Created attachment 1193921 [details]
File: environ

Created attachment 1193922 [details]
File: limits

Created attachment 1193923 [details]
File: maps

Created attachment 1193924 [details]
File: mountinfo

Created attachment 1193925 [details]
File: namespaces

Created attachment 1193926 [details]
File: open_fds

Created attachment 1193927 [details]
File: proc_pid_status

Created attachment 1193928 [details]
File: var_log_messages

Similar problem has been detected:

openQA hit this crash right after logging into the desktop in the Fedora-25-20160923.n.0 default_upload x86_64 test; it crashed back to gdm. https://openqa.fedoraproject.org/tests/35749

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     1486
kernel:         4.8.0-0.rc6.git0.1.fc25.x86_64
package:        gnome-shell-3.21.92-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

openQA also hit this same crash in the UEFI variant of the same test, https://openqa.fedoraproject.org/tests/35750 .

Similar problem has been detected:

This happened in this openQA test: https://openqa.fedoraproject.org/tests/36386

The test was running through g-i-s after a fresh install, as a newly created user, when Shell crashed, sending the system back to gdm.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     1534
kernel:         4.8.0-0.rc6.git0.1.fc25.i686+PAE
package:        gnome-shell-3.22.0-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

So openQA has hit this crash three times now, twice in 25-20160923.n.0 , once in 25-20160926.n.0 , once on 32-bit, twice on 64-bit.

I can reproduce this issue by starting cherrytree on a gnome+wayland session on Fedora 25. Seems to be specific to my cherrytree configuration though.

openQA hit it again in today's Rawhide tests:

https://openqa.fedoraproject.org/tests/37119

that's on x86_64 (in an upgrade test, logging into the upgraded system, looks like it crashed back to GDM immediately after login).

Similar problem has been detected:

Launch a lot of application

reporter:       libreport-2.8.0
backtrace_rating: 3
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     1653
kernel:         4.8.4-301.fc25.x86_64+debug
package:        gnome-shell-3.22.1-2.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

Similar problem has been detected:

This crash happened during an openQA test: https://openqa.fedoraproject.org/tests/44798 . The test does a clean install of Fedora Workstation (in this case, the Fedora-25-20161029.n.0 nightly), then logs into the installed system and clicks through gnome-initial-setup. In this case, Shell crashed back to GDM almost as soon as the user logged in. I believe openQA has run into this crash several times, though it certainly doesn't happen *every* time.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     1537
kernel:         4.8.4-301.fc25.i686+PAE
package:        gnome-shell-3.22.1-2.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

ah, yup, this one. Note from the journal:

...
Oct 29 06:50:28 localhost.localdomain udisksd[1637]: Mounted /dev/sr0 at /run/media/test/Fedora-WS-Live-25-20161029-n-0 on behalf of uid 1000
Oct 29 06:50:29 localhost.localdomain audit[1537]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1537 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=5
Oct 29 06:50:29 localhost.localdomain kernel: do_trap: 189 callbacks suppressed
Oct 29 06:50:29 localhost.localdomain kernel: traps: gnome-shell[1537] trap int3 ip:b51103c1 sp:bfdcfd90 error:0 in libglib-2.0.so.0.5000.1[b50c1000+119000]
Oct 29 06:50:29 localhost.localdomain dbus-daemon[955]: [system] Activating service name='org.freedesktop.fwupd' requested by ':1.68' (uid=1000 pid=1720 comm="/usr/bin/gnome-software --gapplication-service " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") (using servicehelper)
Oct 29 06:50:29 localhost.localdomain abrt-hook-ccpp[1966]: Process 1537 (gnome-shell) of user 1000 killed by SIGTRAP - dumping core
...

Similar problem has been detected:

When gnome-shell crashed I had opened gnome-terminal and firefox. Crash happened exactly when I tried to close firefox (with x button). It probably froze after I clicked on it for the first time and after a while gnome-shell crashed.

reporter:       libreport-2.8.0
backtrace_rating: 3
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     1404
kernel:         4.8.4-301.fc25.x86_64
package:        gnome-shell-3.22.1-2.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

This happened again today in an openQA test:

https://openqa.fedoraproject.org/tests/45717

. I'm a bit concerned about this bug for F25, so throwing on the blocker list for discussion. It doesn't happen *super* often, rough guess in maybe 10% of tests? but still.

can someone give me the core file ?

You got it now, but in case anyone else wants it, it is in https://openqa.fedoraproject.org/tests/45717/file/_graphical_wait_login-spoolabrt.tar.gz . in general, any time you see a 'spoolabrt.tar.gz' on an openQA test it means that the post-fail hook found some content in /var/spool/abrt , indicating abrt caught at least one crash, and that archive contains the entire contents of that tree. The archive isn't created when there's nothing there.

So I fairly strongly suspect this crash happens only on first login to GNOME after system install.

* That always seems to be the point openQA tests reach when it happens - I just checked every test mentioned above, and in every one, it crashed right after the first log in to GNOME.

* We have a few tests which start from a disk image uploaded after a *previous* test has completed g-i-s, and I just checked and none of those tests has ever hit this crash on production or staging (which is quite a large data set).

* I've never seen this crash on my production desktop box.

So with those three points together, I think at least the case of this that openQA is hitting is related to something that happens on first login (the obvious thing is g-i-s running, but probably there's other stuff that happens on first login that doesn't happen the same way afterwards). Petr's case doesn't seem quite to fit the pattern, but hard to tell if he actually hit the same crash without his backtrace.

so i'm stumped at this point. we can see it's crashing here:

  │262     static gboolean
  │263     g_settings_backend_invoke_closure (gpointer user_data)
  │264     {                
  │265       GSettingsBackendClosure *closure = user_data;
  │266                       
  │267       closure->function (closure->target, closure->backend, closure->name,
  │268                          closure->origin_tag, closure->names);
  │269            
  │270       g_object_unref (closure->backend);
 >│271       g_object_unref (closure->target);
  │272       g_strfreev (closure->names);
  │273       g_free (closure->name);
  │274
  │275       g_slice_free (GSettingsBackendClosure, closure);
  │276                    
  │277       return FALSE;
  │278     }

shortly after running settings_backend_changed :

(gdb) p	closure->function
$7 = (void (*)(GObject *, GSettingsBackend *, const gchar *, gpointer, gchar **))
    0x7fe98ef1c2d0 <settings_backend_changed>

settings_backend_changed would normally emit a changed-event for the passed in key:

(gdb) p	closure->name
$8 = (gchar *) 0x7fe960016300 "/org/gnome/desktop/app-folders/folders/Sundry/translate"

but in this case it won't, because the passed in key isn't associated with the same settings object!

(gdb) p ((GSettings *) closure->target)->priv->path
$10 = (gchar *) 0x5601dfa2dda0 "/org/gnome/desktop/media-handling/"

Furthermore, the crash is happening in a toggle ref notify handler:

   │1059        if (is_last_ref) {
   │1060            /* We've transitions from 2 -> 1 references,
   │1061             * The JSObject is rooted and we need to unroot it so it
   │1062             * can be garbage collected
   │1063             */
   │1064            if (is_main_thread) {
   │1065                if (G_UNLIKELY (toggle_up_queued || toggle_down_queued)) {
  >│1066                    g_error("toggling down object %s that's already queued
   │1067                            G_OBJECT_TYPE_NAME(gobj),
   │1068                            toggle_up_queued && toggle_down_queued? "up and
   │1069                            toggle_up_queued? "up" : "down");
   │1070            }
   
Those handlers only get called when the ref count of the object goes from 2→1 or 1→2.  In this case, the ref count of the object went from 2→1 because is_last_ref is true.  But if you look at the ref count of the object... it's 3, not 1!

(gdb) p *((GSettings *) closure->target)        
$11 = {parent_instance = {g_type_instance = {g_class = 0x5601de6dfdb0},	ref_count = 3,
    qdata = 0x5601dfa1d5e1}, priv = 0x5601df0921e0}

This suggests maybe the settings object is getting mucked with in another thread (say from gvfs or the glib worker thread or something), at the same time the toggle ref notify handler is running, but i can't find any evidence of that.

Maybe memory corruption is in play here, but not sure. I'm kinda stumped.

Discussed during the 2016-11-07 blocker review meeting: [1]

The decision to classify this bug as a RejectedBlocker and an AcceptedFreezeException was made as while this is an unfortunate bug, we don't see this as happening often enough to violate the blocker-criteria.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-11-07/f25-blocker-review.2016-11-07-17.01.txt

*** Bug 1397668 has been marked as a duplicate of this bug. ***

FWIW I see this frequently on my Fedora 25 desktop machine, it's not just a firstboot thing.

Are you sure it's actually the same? Did you check the trace? abrt isn't always right.

different backtrace. I opened bug 1398795 for it.

(In reply to Andy Grover from comment #29)
Being the original reporter, I have not seen this issue since mid-october. I would actually suppose it has been fixed in the meantime.

This is shown in the terminal:

[9066.595376] nouveau 0000:00:0d:0: bus: MMIO write of 00000000 FAULT at 00b000

*** Bug 1404264 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

I use this system with a VGA monitor. This crash can happen when VT switching.  I can reproduce it with this script:

for i in 1 2; do sudo chvt 3; sleep 0.5; sudo chvt 4

where VT 3 is a text console, and VT4 is gnome-shell running using Wayland.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     8288
kernel:         4.8.14-300.fc25.x86_64
package:        gnome-shell-3.22.2-2.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1002

Apologies, the above comment was posted to the wrong bug.  I have not yet determined how to reproduce my gnome-software crash, although it's happened a number of times today.

*** Bug 1412789 has been marked as a duplicate of this bug. ***

*** Bug 1415229 has been marked as a duplicate of this bug. ***

*** Bug 1421384 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

I think I was just using chrome and then it just happened. Can't think of anything special happening.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     2411
kernel:         4.9.13-200.fc25.x86_64
package:        gnome-shell-3.22.3-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

*** Bug 1431214 has been marked as a duplicate of this bug. ***

*** Bug 1431601 has been marked as a duplicate of this bug. ***

This happens almost daily on my box ...  There are a slew of duplicate bugs reported. It happens sometimes when I am docking and undocking my laptop E.g. switching from one console to many.

Here's another duplicate with a full-dump...
  Save Changes Bug 1431601 - [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by SIGTRAP (edit)

*** Bug 1445754 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

This bug appear randomly during normal utilisation... I don't know how to reproduce this.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     2009
kernel:         4.10.13-200.fc25.x86_64
package:        gnome-shell-3.22.3-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

*** Bug 1454845 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

Waking up from sleep.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     15361
kernel:         4.10.17-200.fc25.x86_64
package:        gnome-shell-3.22.3-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

Similar problem has been detected:

Waking up from sleep

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
global_pid:     17963
kernel:         4.10.17-200.fc25.x86_64
package:        gnome-shell-3.22.3-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         gnome-shell killed by SIGTRAP
runlevel:       N 5
type:           CCpp
uid:            1000

Just happened again in openQA, on today's F26 compose:

https://openqa.stg.fedoraproject.org/tests/125852

(In reply to Adam Williamson from comment #50)
> Just happened again in openQA, on today's F26 compose:
> 
> https://openqa.stg.fedoraproject.org/tests/125852

Nominating as final blocker, as it violates the following release criteria:
https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#SELinux_and_crash_notifications

If this is not accepted as final blocker, please put it on the list of prioritized bugs.

Not really, as it happens very intermittently. That criterion's intended to cover failures that *always* or *almost always* happen (i.e. we want to avoid the case where every install, or nearly every install, shows a crash or AVC notification during the install / first boot process).

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This is still an issue, at least on Fedora 26.

So, looking at this again in the light of https://bugzilla.redhat.com/show_bug.cgi?id=1510059 and https://bugzilla.redhat.com/show_bug.cgi?id=1469813 , this looks a lot like another case where we're getting multiple different crashes erroneously reported as dupes of one bug, due to the _g_log_abort codepath. I'm assuming all SIGTRAP crashes via the _g_log_abort codepath for whatever release version this bug was set to at the time are getting reported as 'dupes' of this bug.

So, probably the case I was (possibly still am, not sure) encountering on openQA and the case Joachim hit are not the same (not to mention all the other dupe comments and dupe bugs are likely not dupes either). In Joachim's trace, the critical error message is "toggling down object GSettings that's already queued to toggle up".

Unfortunately, all the openQA results I mentioned here have been garbage-collected already, so I can't get the crash data and check the backtrace again. I'll try and find a minute at some point to see if this is still happening in openQA tests, get a hold of the crash data, and look into it properly.

I've gone through all the dupe bugs and unpicked those as appropriate. For any other reporters following along with this, please examine your 'backtrace' and 'var_log_messages' files to see what your problem really is. In 'backtrace', look for the 'currently active thread' (probably thread 1) and look for the few frames after the _g_log_abort call; one of them, probably g_logv , should have a 'msg' property, which is the actual log message associated with the fatal error. That's one important clue. It'll often just be "Connection to xwayland lost" or similar, though, which only tells us that GNOME crashed because XWayland crashed, but doesn't tell us why. The 'var_log_messages' file may well have additional error messages that cast some additional light on the bug.

If your error message *is* "Connection to xwayland lost" or similar, or anything else other than "toggling down object GSettings that's already queued to toggle up" , you don't have the same bug as the original reporter here (Joachim), so we need to separate out your report. It may be a dupe of some *other* bug: searching on the message text (if it's something more useful than the xwayland crash message) and/or messages found in var_log_messages might help you find another bug that really *is* the same as yours. Otherwise, you can file a new bug, with as much information as you can included to help us try and figure out what's actually wrong.

F25 is now EOL, so please try to reproduce your problem with F26 or F27. The suggestions at https://fedoraproject.org/wiki/How_to_debug_Xorg_problems and https://fedoraproject.org/wiki/How_to_debug_Wayland_problems should help you include useful debugging data with your report. Thanks!

Joachim - or anyone else who actually is hitting "toggling down object GSettings that's already queued to toggle up", at least - can you confirm whether you're actually still seeing *that same crash* on F26 or F27? Thanks.

kparal's https://bugzilla.redhat.com/show_bug.cgi?id=1402492#c21 mentions this same error message, and https://bugzilla.redhat.com/show_bug.cgi?id=1484728 is another report for F26, so I think we can say at least that people have encountered this on F26.

*** Bug 1484728 has been marked as a duplicate of this bug. ***

*** Bug 1492312 has been marked as a duplicate of this bug. ***

*** Bug 1502171 has been marked as a duplicate of this bug. ***

*** Bug 1469813 has been marked as a duplicate of this bug. ***

FWIW, I'm starting to suspect that all or most of the crashes openQA encountered were the "toggling down object GSettings that's already queued to toggle up" type.

(In reply to Adam Williamson from comment #55)
I have no information about occurrences of this issue later than in the original report (cf. comment 32).

Thanks. I am indeed starting to suspect this got fixed at some point, but will try to look into it a bit harder.

Hmm. So, I've been looking into this some more. I don't think this has got fixed, at least in F26. I have at least found an openQA test run two days ago on F26 that hit it:

https://openqa.fedoraproject.org/tests/180655

That's with the latest F26 gnome-shell and gjs packages:

gnome-shell-3.24.3-2.fc26.x86_64
gjs-1.48.7-1.fc26.x86_64

For F27, the last time I can find cases where a test crashed on login to GNOME (the time when openQA usually encounters this) is 2017-11-10. I can't find a similar crash since. Unfortunately, the logs for all the F27 cases I can find have been garbage collected, so I can't tell for sure whether those crashes were in fact caused by this bug.

I've reported this upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=791761

Similar problem has been detected:

The gnome-shell crashed spontaneously, while i was scrolling down a webpage with Firefox. And dnf update was running in a terminal in the background. I just found out, that this crash corrupted my dnf database. :(

[root@F28stick ~]# dnf update
Fehler: rpmdb: BDB0113 Thread/process 5633/139789840000832 failed: BDB1507 Thread died in Berkeley DB library
Fehler: db5 Fehler(-30973) von dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Fehler: Packages-Index kann nicht mittels db5 geöffnet werden -  (-30973)
Fehler: Paket-Datenbank in /var/lib/rpm kann nicht geöffnet werden
Fehler: Error: rpmdb open failed
[root@F28stick ~]# 

reporter:       libreport-2.9.2
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
journald_cursor: s=8659c6f3a101454c89cdb73f28c65067;i=2db;b=a09e05fc2f554a09aa8bba065e0bb035;m=1daecdbf6;t=563a5c8fd7973;x=9c589d7b89c73289
kernel:         4.13.9-300.fc27.x86_64
package:        gnome-shell-3.26.1-1.fc27
reason:         gnome-shell killed by SIGTRAP
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

That looks like the RPM database; try the old:

rm -f /var/lib/rpm/__db*
rpm --rebuilddb

hopefully, that'll fix it up. For the future, this is one of the reasons why GNOME recommends offline updates - it avoids this kind of problem. But if you want to update online, I'd recommend doing it from a TTY, or a screen or tmux session. That should protect it from desktop crashes.

Note, your crash may not actually be the same as this bug (there is a problem with abrt causing false duplication of GNOME crashes that are actually different). If possible, can you post the backtrace and the system logs from a few minutes around the crash? That should help figure out what the real cause was.

I submitted the backtrace with my report, or at least i think that abrt did that for me. Can you guide me to those system logs, that you would like to see?

rpmdb --rebuilddb did the trick on the database and i resumed the update beautifully.

Sebastian: the problem is that when abrt decides your report is a dupe of an existing one, it doesn't *send* us the trace :( It just adds a comment to the existing bug, on the theory that the trace (and other data) will be the same as the one in the original report so there's no need to duplicate it. That's why we need you to file a new bug report and attach it manually :/

For the system logs, if you know the time of the crash - abrt should tell you - you can do something like this. For instance, if the time of the crash is 10:35 on January 25, do this as root:

journalctl --since "2018-01-25 10:25:00" --until "2018-01-25 10:45:00" > syslogs

and attach the file 'syslogs' that it creates to the bug - that will include the logs from 10:25 to 10:45 on that day.

Thanks!

Hello Adam, sorry to keep you waiting for so long. Now i can finally present the culprit to you.
https://geizhals.de/adata-elite-s102-pro-grau-32gb-as102p-32g-rgy-a692409.html

There are werewolves hiding inside that stick. They are coming to get to me everytime while i dare to dnf update the system or install even just a little tiny bit more than one package at once. Once updated, the system starts to behave almost as normal as my other Fedora installation, which is located on a HGST Ultrastar 3TB drive. No problems over there.. the Ultrastar is a far too mighty beast itself. Wolves keep their respectful distance. ^^

 So i figured it must be a bad controller on the stick, or bad NAND flash. Or both. The sticks cache is busy while the dnf wolves roam around it. ;)
I just got an error message in the terminal while installing nano, to have a look at the syslogs...
Translated from German: "Creating a child process caused an error in this terminal.
Operation timed out." "Profile settings" "restart"

So there you have it. But i will send the syslogs of today, it might be helpful for the SoC RasPi users. Maybe there is a possibility to mount the dnf update operations to a tempfs?

Ah by the way, the dnf update succeeded after 28 hours on an USB2 port!

Created attachment 1391388 [details]
syslogs.log from ADATA USB Drive system with timeout errors.

Created attachment 1391390 [details]
ADATA USB timeout-provoked additional errors.

(In reply to Sebastian from comment #70)
> Ah by the way, the dnf update succeeded after 28 hours on an USB2 port!

If you're feeling lucky, you could install nosync and then run `LD_PRELOAD=/usr/lib64/nosync/nosync.so dnf upgrade`.

Installiert:
  nosync.x86_64 1.1-1.fc27                                                                

Fertig.
[root@stick lib64]# cd nosync
[root@stick nosync]# ls
nosync.so
[root@stick nosync]# `LD_PRELOAD=/usr/lib64/nosync/nosync.so dnf upgrade`

....

Hm... running for 10 minutes now. Nothing happens. Drive space monitoring with a df -h on another terminal shows no reaction at all. How long is this supposed to run?

Meanwhile, i introduced new entries in my fstab:

UUID=b0bb2100-6245-4679-be1b-dbe7032df12e /                ext4    rw,suid,dev,exec,auto,nouser,async      0 1

UUID=1660a090-7730-43c1-b8c2-321b38ec444f /home            ext4    rw,suid,dev,exec,auto,nouser,async      0 2

tmpfs   /home/burni/.cache    tmpfs      defaults        0 0
tmpfs   /tmp                  tmpfs      defaults        0 0
tmpfs   /dev/shm              tmpfs      defaults        0 0
tmpfs   /var/tmp              tmpfs      defaults        0 0
tmpfs   /var/run              tmpfs      defaults        0 0
tmpfs   /var/lock             tmpfs      defaults        0 0
tmpfs   /var/cache            tmpfs      defaults        0 0

The outcome is very rewarding. System hangs are reduced to a minimum, als long as i open up the stuff i want to use, while the dnf update can work in the background.
And it definitely makes a good german beer taste even better. Very rewarding indeed. ;)

Changed async to noatime. And i got no errors in 48 hours. This should be my last post under this bug. Thank you, for hinting me in the right directions.

Similar problem has been detected:

First login after have encrypted the user's home directory with ecryptfs, I don't know if it's related

reporter:       libreport-2.9.2
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
journald_cursor: s=7e05bf54bc9b43e9b06502f4a49eb475;i=8b3;b=f666458695394194bf2e724f0e59df51;m=3d2d35ef;t=5650025f5e5d0;x=1d6015e2dc3191ac
kernel:         4.13.9-300.fc27.x86_64
package:        gnome-shell-3.26.1-1.fc27
reason:         gnome-shell killed by SIGTRAP
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Similar problem has been detected:

The exact reason is unclear to me. Booted from the F27 live / testing / install stick, a short time into the system, after adjusting time and starting a youtube video, the crash occurs "out of the blue". I am logged-out. After re-login sound does not work any longer. Possible hardware defect?

reporter:       libreport-2.9.2
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
journald_cursor: s=84612cbec8e8408db3c37e31220dcaec;i=81c;b=f470f8faab354287bee41f30e18bf931;m=173cc3f4;t=567ae12b81299;x=b90ce4c7fbd6d4a4
kernel:         4.13.9-300.fc27.x86_64
package:        gnome-shell-3.26.1-1.fc27
reason:         gnome-shell killed by SIGTRAP
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Similar problem has been detected:

I was switching accounts from a non-privileged account to a priveleged account. This occurred at login.

reporter:       libreport-2.9.2
backtrace_rating: 4
cmdline:        /usr/bin/gnome-shell
crash_function: _g_log_abort
executable:     /usr/bin/gnome-shell
journald_cursor: s=99649b030ffe42dda05c6c3fd0a29849;i=9c6;b=1befcc76492b4a929043a909834ca0c2;m=106436e4;t=5698c55a21730;x=fdf8b85cddeefd3c
kernel:         4.13.9-300.fc27.x86_64
package:        gnome-shell-3.26.1-1.fc27
reason:         gnome-shell killed by SIGTRAP
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.