I'm experiencing the same thing, with identical symptoms. 

I also tried booting into tty2 from grub, which works after the failed update, but I was unable to recover the system.

Hardware Info:
AMD 3700X / X570 installing to an NVMe SSD.

(In reply to Mike B from comment #1)
> I'm experiencing the same thing, with identical symptoms. 
> 
> I also tried booting into tty2 from grub, which works after the failed
> update, but I was unable to recover the system.
> 
> Hardware Info:
> AMD 3700X / X570 installing to an NVMe SSD.

I just spun up a VM (KVM/QEMU) to test this, and the virtual machine *does not* experience this issue.

I've run into this same issue on a Lenovo Yoga 920 while performing updates via dnf in a gnome terminal session inside Gnome 40, and reproduced this on a second run with a fresh install from the Fedora 34 Workstation beta iso.

The hang did not happen if I switched to a text console first without any GUI before performing the first dnf update.

It might help if someone can update by hand with say "sudo rpm -Uvh --noscripts ibus-anthy-*.rpm".

And then try to run: sudo /usr/bin/ibus write-cache --system
and attach any log output here. There may be better ways to debug though.

I cannot reproduce your problem.

We don't know how to reproduce this, but it seems to warrant attention.
Specially not being able to reboot is rather concerning.

If someone could confirm if this is specific to ibus-anthy or not that would be helpful.
ie just `rpm -e ibus-anthy` before attempting to update packages.

Also reported in bug 1948197 against ibus.

I did a fresh install of the Fedora 34 beta and upgraded just the ibus-anthy and ibus-anthy-python packages via dnf without the hang. I'll try a few mutations of that and see if I can repo.

A few more data point:

1. Installation this morning from the 1.3 beta iso immediately upgrading full via dnf inside a wayland session resulted in the hang with the gnome terminal showing "Running scriptlet: ibus-anthy-1.5.12-4.fc34.x86_64". Rebooting the system resulted in a system that was unable to start gdm properly.

2. Installation from the 1.3 beta iso, rebooting into the newly installed system, removing ibus-anthy and ibus-anthy-python via dnf, then doing a "dnf -y update" resulted in the wayland session switching back to a terminal with a blinking cursor in the top left corner of the screen. Rebooting the system resulted in gdm being unable to start.

I'll testing doing a full upgrade from xorg and see if that works next.

I re-tested removing ibus-anthy before the update using wayland, and that worked this go around. I think the screensaver setting timed out in my first test causing the display issue. Anyhow, retesting this it worked flawlessly.

Performing the first 'dnf -y update' using an Xorg session without removing ibus-anthy also seemed to work without issues.

It definitely seems like the ibus-anthy upgrade packed with the rest of the beta package upgrades is causing issues with Wayland sessions.

Brand new T14s, installed Fedora 34 from scratch. ibus-anthy froze the whole system as well. I was able to reboot into the system in single mode, remove some conflicts, but thing got messy with dual installs of grub2-* packages. So, I re-installed the OS, and removed ibus-anthy like some folks here and upgrade finished.

(In reply to Jens Petersen from comment #7)
> Also reported in bug 1948197 against ibus.
(Ugh I meant bug 1949216)

Thank you, Stephen for the additional testing - much appreciated.
Somehow I suspect this might be something on the gnome or kernel side, or maybe via dbus?
I don't think there have been any recent changes related to this in ibus.

Maybe if one runs `dnf update ibus-anthy` first and then `dnf update` the problem might not happen?
Dunno if `strace /usr/bin/ibus write-cache --system` gives any more clues.

Also if this only happens on bare-metal - it seems unlikely the problem is caused directly by ibus.

Any help with narrowing down this problem would be greatly appreciated.

For what it’s worth, upgrading ibus-anthy first in isolation avoids the nasty lock condition.

Does your home directory mount a different partition?

ibus engines including ibus-anthy runs `ibus write-cache --system` in the postscript, which runs sub-scripts in /usr/share/ibus/*.xml internally, and updates /var/cache/ibus/bus/registry file.
E.g. /usr/share/ibus/anthy.xml runs `/usr/libexec/ibus-engine-anthy --xml` which loads /usr/share/ibus/anthy.xml and /usr/share/ibus-anthy/engine/default.xml .

`ibus write-cache --system` checks the time stamps of /var/cache/ibus/bus/registry and $HOME/.cache/ibus/bus/registry. Maybe the home is /home/liveuser .

All I do at the moment is to move both the postinstall and postuninstall to %posttrans but I don't know if it can resolve your issue since I cannot reproduce it.

You can see the postscript with `rpm -q --scripts ibus-anthy`.

I prepared the test package in copr to move both the postinstall and postuninstall to %posttrans :
https://copr.fedorainfracloud.org/coprs/fujiwara/ibus-anthy/

Could you try the new package if your problem can be fixed?

1. Install F34 newly again

2. Add the copr repo to run `dnf copr enable fujiwara/ibus-anthy`

3. Run `dnf update` and make sure ibus-anthy-1.5.12-5 is installed.

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

A friend of mine had the same problem.
He downloaded a new iso (a nightly build) and performed the updates without problems. 
Perhaps that's a bug that isn't present anymore at newly images?

Just adding my experience in case it helps.

Installed Fedora 34 on my Lenovo V155 last night, one of the first things I did was a `sudo dnf update` and it locked up running the ibus-anthy update script as others have mentioned.

I did manage to switch to a tty and login after hard resetting. Ran `dmesg -e` and noted that gnome-shell had listed a segfault in libEGL_mesa.so, but couldn't figure out how to reinstall mesa-libEGL.

Reinstalled Fedora 34 this morning, updated ibus-anthy on its own in a tty first, followed by a `sudo dnf update` and it seems to have worked just fine.

(In reply to Lee Thomas from comment #20)
> Reinstalled Fedora 34 this morning, updated ibus-anthy on its own in a tty
> first, followed by a `sudo dnf update` and it seems to have worked just fine.

Sorry, this way does not help to resolve this issue since it seems to depend on the timing to run the postscripts.
I asked the testing way in comment #17.

Another comment from my side. I restarted from scratch and installed F33 first and then subsequently did the upgrade to F34 and did not have the problem.

I am running it for some days now without an issue (although I have other issues with external monitors and pipewire)

I could not reproduce on a fresh vm. I installed F34 Workstation Beta and ran a dnf update. It successfully updated to ibus-anthy-1.5.12-4.fc34.x86_64.

(In reply to Ben Cotton from comment #23)
> I could not reproduce on a fresh vm. I installed F34 Workstation Beta and
> ran a dnf update. It successfully updated to ibus-anthy-1.5.12-4.fc34.x86_64.

This need to be checked on bare-metal system. VM works fine.

If none verify my fix, I will close this as not a bug.

(In reply to fujiwara from comment #25)
> If none verify my fix, I will close this as not a bug.

Tested. Fresh install of F34 Beta on Dell Latitude 7410 (10th gen core i7). Wayland session. With copr enabled, the issue on ibus-anthy is gone, BUT the updates locks on "Running scriptlet: ibus-typing-booster-2.11.2-1.fc34.noarch".

Same situation as before - session locked. Boot is feasible, when restarted dnf does not suggest to complete transaction, but a conflict with libhandhy. Looks like the transaction will not complete.

(In reply to Luca Botti from comment #26)
> (In reply to fujiwara from comment #25)
> > If none verify my fix, I will close this as not a bug.
> 
> Tested. Fresh install of F34 Beta on Dell Latitude 7410 (10th gen core i7).
> Wayland session. With copr enabled, the issue on ibus-anthy is gone, BUT the
> updates locks on "Running scriptlet:
> ibus-typing-booster-2.11.2-1.fc34.noarch".
> 
> Same situation as before - session locked. Boot is feasible, when restarted
> dnf does not suggest to complete transaction, but a conflict with libhandhy.
> Looks like the transaction will not complete.

Additionally - on my system (vt-d turned on in bios) I need to add intel_iommu=on on the kernel command line to boot, with noapic added as default from fedora.

(In reply to fujiwara from comment #17)
> I prepared the test package in copr to move both the postinstall and
> postuninstall to %posttrans :
> https://copr.fedorainfracloud.org/coprs/fujiwara/ibus-anthy/
> 
> Could you try the new package if your problem can be fixed?
> 
> 1. Install F34 newly again
> 
> 2. Add the copr repo to run `dnf copr enable fujiwara/ibus-anthy`
> 
> 3. Run `dnf update` and make sure ibus-anthy-1.5.12-5 is installed.

Tested fresh install on X1 Carbon Gen6

Enable fujiwara/ibus-anthy repo and confirmed that dnf update was targeting ibus-anthy-1.5.12-5

Starting version Ibus-anthy-1.5.12-1.fc34.x86_64
Successfully installed Ibus-anthy-1.5.12-5.fc34.x86_64
Successfully installed Ibus-anthy-python-1.5.12-5.fc34.x86_64
Dns update gets stuck in Ibus-typing-booster-2.11.2-1.fc34.noarch 

System exhibited same behaviour as when previously stuck at ibus-anthy

Hope this help, let me know if you need further tests done.

(In reply to Luca Botti from comment #27)
(In reply to Frederic Masi from comment #28)

@Luca Botti and @Frederic Masi

Thank you for the testing.
The similar postscript is also saved in ibus-typing-booster and could be the same issue.

Now I updated ibus-typing-booster, ibus-hangul, ibus-libpinyin, ibus-input-pad besides ibus-anthy in the same copr:
https://copr.fedorainfracloud.org/coprs/fujiwara/ibus-anthy/

Could you please try the Fedora 34 installation again?

1. Install F34 newly again

2. Add the copr repo to run `dnf copr enable fujiwara/ibus-anthy`

3. Run `dnf update` and make sure ibus-anthy-1.5.12-5 is installed.

(In reply to fujiwara from comment #29)
> (In reply to Luca Botti from comment #27)
> (In reply to Frederic Masi from comment #28)
> 
> @Luca Botti and @Frederic Masi
> 
> Thank you for the testing.
> The similar postscript is also saved in ibus-typing-booster and could be the
> same issue.
> 
> Now I updated ibus-typing-booster, ibus-hangul, ibus-libpinyin,
> ibus-input-pad besides ibus-anthy in the same copr:
> https://copr.fedorainfracloud.org/coprs/fujiwara/ibus-anthy/
> 
> Could you please try the Fedora 34 installation again?
> 
> 1. Install F34 newly again
> 
> 2. Add the copr repo to run `dnf copr enable fujiwara/ibus-anthy`
> 
> 3. Run `dnf update` and make sure ibus-anthy-1.5.12-5 is installed.

Hi,

just tested and it worked. No issue with ibus-*.

(In reply to Luca Botti from comment #30)
> (In reply to fujiwara from comment #29)
> > (In reply to Luca Botti from comment #27)
> > (In reply to Frederic Masi from comment #28)
> > 
> > @Luca Botti and @Frederic Masi
> > 
> > Thank you for the testing.
> > The similar postscript is also saved in ibus-typing-booster and could be the
> > same issue.
> > 
> > Now I updated ibus-typing-booster, ibus-hangul, ibus-libpinyin,
> > ibus-input-pad besides ibus-anthy in the same copr:
> > https://copr.fedorainfracloud.org/coprs/fujiwara/ibus-anthy/
> > 
> > Could you please try the Fedora 34 installation again?
> > 
> > 1. Install F34 newly again
> > 
> > 2. Add the copr repo to run `dnf copr enable fujiwara/ibus-anthy`
> > 
> > 3. Run `dnf update` and make sure ibus-anthy-1.5.12-5 is installed.
> 
> Hi,
> 
> just tested and it worked. No issue with ibus-*.

Fantastic!

@Luca Botti and @Frederic Masi

Thank you very much for your tests.

I can also confirm the issue is resolved on a Lenovo T490 after adding the COPR repo.

I encountered this issue as well on a custom build AMD Ryzen 9 5950X. 

Fixed after following fujiwara's instructions.

Thanks!

I had encountered this problem over multiple attempts over the past several days. Today I followed fujiwara's most recent instructions above and that resolved the problem.

This is on a Dell Latitude 7490.

+4 in https://pagure.io/fedora-qa/blocker-review/issue/353 , marking accepted. @fujiwara, could you please do an official build/update with the fix? Thanks!

Problem is we need to update all the ibus IMEs - at least the default installed ones.

I am not sure if the fix needs to be in GA though - I think 0-day updates should do the trick?
UNless there are concerns with the %postun scriptlet too.

I think the fix will be available after Fedora 34 GA since we don't have to fix ibus-anthy only but also other packages at the same time with more tests.
Unfortunately ibus does not have the group integration in bodhi.

I will update the release note to describe the copr repository.

Proven packagers can help with fixing other IMEs.
We should address the most common ones first.


dnf repoquery --file /usr/share/ibus/component/*.xml --qf "%{source_name}"
ibus [*]
ibus-anthy [*]
ibus-bogo
ibus-cangjie
ibus-chewing
ibus-handwrite
ibus-hangul [*]
ibus-input-pad
ibus-kkc
ibus-libpinyin [*]
ibus-libzhuyin [*]
ibus-m17n [*]
ibus-pinyin
ibus-rawcode
ibus-rime
ibus-sayura
ibus-skk
ibus-table
ibus-typing-booster [*]
ibus-uniemoji
ibus-unikey
mozc

([*] = default in @input-methods)

(In reply to fujiwara from comment #37)
> I think the fix will be available after Fedora 34 GA since we don't have to
> fix ibus-anthy only but also other packages at the same time with more tests.

That is what updates-testing is for.

> I will update the release note to describe the copr repository.

The copr repo is not an acceptable short-term solution.

(In reply to Jens Petersen from comment #39)
> (In reply to fujiwara from comment #37)
> > I think the fix will be available after Fedora 34 GA since we don't have to
> > fix ibus-anthy only but also other packages at the same time with more tests.
> 
> That is what updates-testing is for.

It cannot do at the same time automatically.

> 
> > I will update the release note to describe the copr repository.
> 
> The copr repo is not an acceptable short-term solution.

Not sure who does not accept the short-term solution.

But since ibus-typing-booster is now updated, I will update ibus-anthy too.

(In reply to Jens Petersen from comment #38)
> Proven packagers can help with fixing other IMEs.
> We should address the most common ones first.

> 
> ([*] = default in @input-methods)

I think the default IMEs would be enough since the reproducing environment is not clarified at the moment and the root cause is not too.

FEDORA-2021-ec82cf176a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec82cf176a

FEDORA-2021-a77c4b6e7a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a77c4b6e7a

FEDORA-2021-ec82cf176a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ec82cf176a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec82cf176a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-a77c4b6e7a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a77c4b6e7a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a77c4b6e7a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-ec82cf176a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec82cf176a

FEDORA-2021-a77c4b6e7a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a77c4b6e7a

FEDORA-2021-850d49df4e has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-eb993b286e has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-125dd83ddc has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-125dd83ddc

When a bug is a blocker or FE for a Fedora release, please don't mark updates for *other* releases as 'fixing' it, or it will get closed and then it won't show up in the tooling I use to do the Fedora compose/push requests and it'll get left out.

FEDORA-2021-9a46e1fdcc has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-9a46e1fdcc

FEDORA-2021-a77c4b6e7a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a77c4b6e7a

FEDORA-2021-ec82cf176a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ec82cf176a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec82cf176a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-a77c4b6e7a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a77c4b6e7a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a77c4b6e7a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-125dd83ddc has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-125dd83ddc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-125dd83ddc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-9a46e1fdcc has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9a46e1fdcc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9a46e1fdcc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Now the test packages are available in updates-testing repo and it would be really great if you could try the installation test again.


1. Install F34 newly again

2. Run `dnf update --enablerepo=updates-testing` and make sure ibus-anthy-1.5.12-5 is installed.

(In reply to Adam Williamson from comment #51)
> When a bug is a blocker or FE for a Fedora release, please don't mark
> updates for *other* releases as 'fixing' it, or it will get closed and then
> it won't show up in the tooling I use to do the Fedora compose/push requests
> and it'll get left out.

Thank you for catching this, Adam, and for tagging all the updating into the compose.

I have tested this issue with two images on bare metal.
 
Image: Fedora-Workstation-Live-x86_64-34-20210421.n.0.iso
 Steps:
 - Was able to reproduce this issue, during dnf update with the default packages(did not enable advisory).
 - Reboot the system and again format, install the new system. Enabled the advisory=FEDORA-2021-ec82cf176a and then ran dnf update.
   
 Observations:
 - Update was smooth, during/post update no system freeze/hang was observed.
 - log: https://paste.opensuse.org/b69c819c
 
 
Image: 34_RC-1.1: Fedora-Workstation-Live-x86_64-34-1.1.iso
 Steps:
 - Installed a new system and checked for package version, all the packages related to this bug were already updated to the latest build(the fixed build).
 
 Observations:
 - No system freeze/hang or any other issue observed.
 - log: https://paste.opensuse.org/1df7a772
 
 
This update[1] works for me.
[1]https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec82cf176a

Image: Fedora-Workstation-Live-x86_64-34_Beta-1.3.iso on bare metal
 Steps:
 - Installed a new system and run "dnf update"
 
 Observations:
 - Update was smooth, during/post update no system freeze/hang was observed.
 - log: https://paste.opensuse.org/eb22d08a

I have also tested upgrading from Fedora 33 to latest Fedora 34 in a VM and
ibus continued to work normally in desktop and flatpak as expected.

I also tested updating F34 Beta in a VM and ibus continued to work correctly afterwards.

FEDORA-2021-02ce3d9d56 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02ce3d9d56

FEDORA-2021-ec82cf176a has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-a77c4b6e7a has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-125dd83ddc has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-9a46e1fdcc has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-02ce3d9d56 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.