1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
|
permissions: 0.839
other: 0.776
vnc: 0.763
files: 0.727
debug: 0.722
graphic: 0.702
PID: 0.702
socket: 0.688
performance: 0.678
semantic: 0.676
KVM: 0.671
device: 0.670
boot: 0.606
network: 0.590
tcg.c:1693: tcg fatal error
this started happening after the launchpad buildd trusty deploy
https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439
debconf-updatepo
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error
/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error
this seems to be the patch needed
https://patches.linaro.org/32473/
Hi,
have already tested with that patch to verify that it fixes the
issue? If I put qemu + that patch into a ppa, will your infrastructure
allow you to test that way?
I'm a bit concerned about this patch, as it appears to be one which has
been in the Suse tree for quite some time, begging the question why it is
not upstream. It would be nice to hear from agraf or pmaydell whether
this patch is safe.
That patch is not in mainline because it's an appalling hack. If we care about multi-threaded guests we need to fix them properly, not paper over the issues by constraining multiple threads to one CPU in the hopes the race conditions don't bite us so often.
No, I did not test the patch, I don't think that I can push that patch in lp infrastructure, and I don't have my own one.
Anyway Peter is right, we don't need to hide bugs, but to fix them ;)
Peter: While this is true, is it actually likely to happen? I thought in our conversations in the past (when I previously attempted to escalate this class of problems via Linaro) it had been fairly clear that this was a very difficult task that isn't likely to be scheduled for the foreseeable future.
I think it's likely to happen eventually; it depends rather on the balance between this and other work priorities (at least if it's going to be Linaro doing the work). Regardless, I'm not taking hacky workarounds like this into mainline (hacks are hard to get out once you let them in, and they remove any motivation anybody might have had for fixing things properly).
Right, I can absolutely understand that. The question would I suppose be whether you think this is a completely unreasonable thing to put in a distro patch; I think SUSE are doing so for basically the same reason we would be, that is, a setup such as PPAs where virtualisation isn't available directly on the architecture in question but we can use qemu-user to run foreign-arch binaries reasonably transparently. My understanding is that this patch would make a pretty huge dent in our failure rate for that setup.
Well, it won't make anything any worse, so it's your call based on how much it actually improves your failure rate I guess.
https://launchpad.net/~serge-hallyn/+archive/ubuntu/qemu-user-thread contains a package with this patch applied (built for trusty). Please let us know how much it helps.
I got this morning a new FTBFS in a package that have been always built successfully in the past, just FYI
https://launchpadlibrarian.net/181879742/buildlog_ubuntu-trusty-armhf.boinc_7.4.0~nightly1~~git20140809%2Br21874~r184~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
Interesting enough the utopic build was successful!
And when I retried the failed build it succeeded but a segmentation fault (core dumped) is in the logs
https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6254532
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Are these new failures using the qem upackage in ppa:serge-hallyn/qemu-user-thread, or using the stock trusty qemu package?
How can I use your one? I have no possibility to tweak the host system, I'm not an lp admin, do you think I can try to add your ppa as dependency and it will work?
No, that won't work as it's the emulator in which the build is running.
You should however be able to install the ppa's qemu on a local host,
install a standard ubuntu server vm, apt-get install ubuntu-dev-tools,
copy the package sources over to the vm, and build the packages inside
the vm.
Hi Serge, sorry for the delay,
the problem is that if I run pbuilder-dist utopic armhf create
pbuilder-dist utopic armhf build boinc_whatever.dsc the build never fails also with the trusty qemu, so I cannot test your package with the patch.
(I'm already on trusty, should I really install a server machine?)
Perhaps i don't understand what you are doing.
My understanding was that a package is being built (in the buildds) under qemu. Qemu is failing due to tcg failure. We want to tes twhether a qemu patch fixes it.
That's why I suggest installing the new qemu package on your host, using it to run a new server VM, and building the problematic package inside that VM. That way we can see whether the proposed qemu package fixes the build error.
I didn't install a VM because:
-I'm on ubuntu 14.04 on my laptop
-I use pbuilder-dist (from ubuntu-dev-tools) armhf that uses qemu as underlying virtualization system.
the fact is:
why on my machine it doesn't show this error?
possible solution:
-because qemu+pbuilder-dist is not multithreaded?
This patch is still not applied upstream.
As there has been no discussion in over a year, I assume it is no longer a problem and I'm going to mark it invalid. Please rep;ly if that is not the case.
If it *is* still a problem, then we should go discuss on oftc#qemu.
Well. This is definitely wrong. It is a valid bug, but it needs quite serious work to fix, which requires major refactoring of the tcg code. Upstream is working on it, see http://wiki.qemu.org/Features/tcg-multithread
Ah, thanks for setting me straight.
We're now building armhf/arm64 packages on real arm64 hardware in Launchpad, so, while this problem may well still exist in qemu, it no longer applies to Launchpad builds.
We think we've fixed our linux-user threading issues, so if there are still problems as of qemu-2.11 or later, please raise a fresh bug report with repro instructions.
per former comments, in context qemu 2.11 is in proposed
This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu1
---------------
qemu (1:2.11+dfsg-1ubuntu1) bionic; urgency=medium
* Merge with Debian testing, among other fixes this includes
- fix fatal error on negative maxcpus (LP: #1722495)
- fix segfault on dump-guest-memory on guests without memory (LP: #1723381)
- linux user threading issues (LP: #1350435)
- TOD-Clock Epoch Extension Support on s390x (LP: #1732691)
Remaining changes:
- qemu-kvm to systemd unit
- d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm,
hugepages and architecture specifics
- d/qemu-kvm.service: systemd unit to call qemu-kvm-init
- d/qemu-system-common.install: install systemd unit and helper script
- d/qemu-system-common.maintscript: clean old sysv and upstart scripts
- d/qemu-system-common.qemu-kvm.default: defaults for
/etc/default/qemu-kvm
- d/rules: install /etc/default/qemu-kvm
- Enable nesting by default
- set nested=1 module option on intel. (is default on amd)
- re-load kvm_intel.ko if it was loaded without nested=1
- d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default
in qemu64 cpu type.
- d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default
in qemu64 on amd
- libvirt/qemu user/group support
- qemu-system-common.postinst: remove acl placed by udev, and add udevadm
trigger.
- qemu-system-common.preinst: add kvm group if needed
- Distribution specific machine type
- d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine
types to ease future live vm migration.
- d/qemu-system-x86.NEWS Info on fixed machine type defintions
- improved dependencies
- Make qemu-system-common depend on qemu-block-extra
- Make qemu-utils depend on qemu-block-extra
- let qemu-utils recommend sharutils
- s390x support
- Create qemu-system-s390x package
- Include s390-ccw.img firmware
- Enable numa support for s390x
- ppc64[le] support
- d/qemu-system-ppc.links provide usr/bin/qemu-system-ppc64le symlink
- arch aware kvm wrappers
* Added Changes
- update VCS-git to match the bionic branch
- sdl2 is yet too unstable for the LTS Ubuntu release given the reports
we still see upstream and in Debian - furthermore sdl2 isn't in main yet,
so we revert related changes to stick with the proven for now:
- 0fd25810 - do not build-depend on libx11-dev (libsdl2-dev already
depends on it)
- 9594f820 - switch from sdl1.2 to sdl2 (#870025)
- d/qemu-system-x86.README.Debian: document intention of nested being
default is comfort, not full support
- update Ubuntu machine types for qemu 2.11
- qemu-guest-agent: freeze-hook fixes (LP: #1484990)
- d/p/guest-agent-freeze-hook-skip-dpkg-artifacts.patch
- d/qemu-guest-agent.install: provide /etc/qemu/fsfreeze-hook
- d/qemu-guest-agent.dirs: provide /etc/qemu/fsfreeze-hook.d
- Create and install pxe netboot images for KVM s390x (LP: #1732094)
- d/rules enable install s390x-netboot.img
- debian/patches/ubuntu/partial-SLOF-for-s390x-netboot-compilation.patch
- d/control-in: enable RDMA support in qemu (LP: #1692476)
- on s390x provide facility bits 81 (ppa15) and 82 (bpb) (LP: #1743560)
- d/p/ubuntu/linux-headers-update-to-4.15-rc1.patch
- d/p/ubuntu/linux-headers-update-4.15-rc9.patch
- d/p/ubuntu/lp1743560-s390x-kvm-Handle-bpb-feature.patch
- d/p/ubuntu/lp1743560-s390x-kvm-provide-stfle.81.patch
- tolerate ipxe size change on migrations to >=18.04 (LP: #1713490)
- d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types
reference 256k path
- d/control: depend on ipxe-qemu-256k-compat-efi-roms to be able to
handle incoming migrations from former releases.
- d/control-in: enable seccomp on s390x
* Dropped changes (no more needed):
- Dropped VHOST_NET_ENABLED and KVM_HUGEPAGES from /etc/default/qemu-kvm
The functionality is retained for upgraders, but is deprecated.
Post 18.04 the implementation for these configurations will be removed.
* Dropped changes (in Debian now):
- ppc64[le] support
- Enable seccomp for ppc64el
- bump libseccomp-dev dependency, 2.3 is the minimum for ppc64
- disable missing x32 architecture
- d/rules: or32 is now named or1k (since 4a09d0bb)
- d/qemu-system-common.docs: new paths since (ac06724a)
- d/qemu-system-common.install: qmp-commands.txt removed, but replaced
by qapi-schema.json which is already packaged (since 4d8bb958)
- d/p/02_kfreebsd.patch: utimensat is no more optional upstream (Update
to Debian patch to match qemu 2.10)
- d/qemu-system-common.docs: adapt new path of live-block-operations.rst
since 8508eee7
- d/qemu-system-common.docs: adapt q35 config paths since 9ca019c1
- make nios2/hppa not installed explicitly until further stablized
- d/qemu-guest-agent.install: add the new guest agent reference man page
qemu-ga-ref
- d/qemu-system-common.install: add the now generated qapi/qmp reference
along the qapi intro
- d/not-installed: ignore further generated (since 56e8bdd4) files in
dh_missing that are already provided in other formats qemu-doc,
qemu-qmp-ref,qemu-ga-ref
* Dropped changes (integrated upstream):
- d/p/detect-ITS-and-skip-usage-on-older-kernel.patch to avoid crashes
on arm64 when doing suspend/resume and reboots due to older kernels not
supporting ITS (LP 1731051).
- Apply linux-user-return-EINVAL-from-prctl-PR_-_SECCOMP.patch from
James Cowgill to prevent qemu-user from forwarding prctl seccomp
calls (LP 1726394)
- update to upstream 2.10.1 point release (LP 1722808)
-- Christian Ehrhardt <email address hidden> Mon, 22 Jan 2018 14:35:18 +0100
Hello, this seems to be still an issue
W: Failure while unpacking required packages. This will be attempted up to five times.
W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/bash_4.4.18-1ubuntu1_arm64.deb is at fault)
dpkg -l |grep qemu
ii ipxe-qemu 1.0.0+git-20161027.b991c67+really20150424.a25a16d-1ubuntu2 all PXE boot firmware - ROM images for qemu
ii ipxe-qemu-256k-compat-efi-roms 1.0.0+git-20150424.a25a16d-0ubuntu2 all PXE boot firmware - Compat EFI ROM images for qemu
ii qemu 1:2.11+dfsg-1ubuntu1 amd64 fast processor emulator
ii qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu1 amd64 extra block backend modules for qemu-system and qemu-utils
rc qemu-kvm 1:2.11+dfsg-1ubuntu1 amd64 QEMU Full virtualization on x86 hardware
ii qemu-slof 20170724+dfsg-1ubuntu0.1 all Slimline Open Firmware -- QEMU PowerPC version
ii qemu-system 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries
ii qemu-system-arm 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (arm)
ii qemu-system-common 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-mips 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (mips)
ii qemu-system-misc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (miscellaneous)
ii qemu-system-ppc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (ppc)
ii qemu-system-s390x 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (s390x)
ii qemu-system-sparc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (sparc)
ii qemu-system-x86 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (x86)
ii qemu-user 1:2.11+dfsg-1ubuntu1 amd64 QEMU user mode emulation binaries
ii qemu-user-static 1:2.11+dfsg-1ubuntu1 amd64 QEMU user mode emulation binaries (static version)
ii qemu-utils 1:2.11+dfsg-1ubuntu1 amd64 QEMU utilities
to reproduce: pbuilder-dist bionic arm64 create
(wrong bug, sorry!)
|