Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64.
I've now tested QEMU git master with that sparc64 ISO and qemu-system- sparc64. I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type. So looks like there's some further variable involved beyond just the glib update - perhaps something about the host OS is combining with the glib update to trigger it. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838658 Title: qemu 4.0.0 broken by glib update Status in QEMU: New Bug description: In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from ``` git checkout -f 2.60.4 git revert --no-edit 86c6f7e2b..3bed8a13b git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159 git revert --no-edit 603fb5958..d3074a748 git revert --no-edit 0b45ddc55..0600dd322 ``` When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib. For the full saga, see: http://gnats.netbsd.org/54310 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838658/+subscriptions