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
|
debug: 0.661
device: 0.584
architecture: 0.572
i386: 0.549
boot: 0.464
PID: 0.463
user-level: 0.448
files: 0.443
permissions: 0.418
network: 0.411
socket: 0.390
x86: 0.372
register: 0.362
mistranslation: 0.360
performance: 0.353
semantic: 0.352
virtual: 0.350
graphic: 0.341
hypervisor: 0.290
kernel: 0.275
VMM: 0.273
ppc: 0.264
vnc: 0.263
peripherals: 0.249
risc-v: 0.242
arm: 0.233
TCG: 0.183
KVM: 0.169
assembly: 0.099
qemu: error reading initrd /home/build/pooldir/w.linux.initramfs
Description of problem:
occasionally, qemu can't open the initrd file it's been supplied on the command line (I'm guessing this is qemu and not libvirt)
```
sudo virsh --connect qemu:///system start w.east --console
error: Failed to start domain 'w.east'\r\nerror: internal error: QEMU unexpectedly closed the monitor (vm='w.east'): qemu: error reading initrd /home/build/pooldir/w.linux-transmogrify.initramfs: Failed to open file \xe2\x80\x9c/home/build/pooldir/w.linux-transmogrify.initramfs\xe2\x80\x9d: open() failed: Permission denied\r\n\r\n"
```
Steps to reproduce:
1. create, using libvirt, a config that direct boots from initrd and kernel
it creates a domain call linux, and from that creates {w.,w1,w2,w3}{east,west,north,road}
1. boots and then destroys these domains 1000's of times
2. occasionally above error occurs while trying to boot the domain
Additional information:
I suspect it is this:
```
mapped_file = g_mapped_file_new(initrd_filename, false, &gerr);
if (!mapped_file) {
fprintf(stderr, "qemu: error reading initrd %s: %s\n",
initrd_filename, gerr->message);
exit(1);
}
x86ms->initrd_mapped_file = mapped_file;
```
in `hw/i386/x86-common.c`. Which would suggest `g_mapped_file_new()` occasionally fails, which is worrying.
The test framework is [Libreswan](https://testing.libreswan.org/), unresolved test results indicate a failed boot, for instance [debug log of failure](https://testing.libreswan.org/v5.2-370-ga09c7f410b/interop-ikev2-strongswan-20-strongswan-eap/OUTPUT/debug.log).
The problem didn't happen with f40.
|