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
|
mistranslation: 0.504
other: 0.482
boot: 0.481
instruction: 0.480
device: 0.475
network: 0.407
vnc: 0.396
graphic: 0.390
assembly: 0.388
semantic: 0.380
KVM: 0.367
socket: 0.326
fw_cfg_machine_reset destroys user bootorder setting
Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and 3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source package) although the code hasn't changed between them and github master also appears to have this same code branch.
What I was trying to do: select a boot disk using `-fw_cfg name=bootorder,string=/pci@i0cf8/*@6` based on the qemu and seabios documentation. (Why do I want to do that? using qemu for installer testing for a specific kind of real machine and need to match the bios boot order.)
What happened instead: same search-based boot order that I get without that option. Also, /sys/firmware/qemu_fw_cfg/by_name/bootorder/raw is empty and .../size is "0".
Brutal work around that did a useful thing:
--- qemu-3.1+dfsg.orig/hw/nvram/fw_cfg.c
+++ qemu-3.1+dfsg/hw/nvram/fw_cfg.c
@@ -869,8 +869,10 @@ static void fw_cfg_machine_reset(void *o
FWCfgState *s = opaque;
char *bootindex = get_boot_devices_list(&len);
+#if 0
ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
g_free(ptr);
+#endif
}
This change allowed the boot to work (so my bootorder setting was making it to seabios) and also showed up explicitly in /sys/firmware/qemu_fw_cfg.
I don't know if fw_cfg_modify_file is intended to append rather than replace, but it doesn't; based on the seabios "Runtime_config" docs which suggest "look at the Searching bootorder for output and paste that into the bootorder file" I'd instead just have it only fill in bootorder if there's *no* existing setting, since a user can read out the defaults and copy them in as described if they want the fallback, but that's just from my interpretation of the docs.
This bug report is invalid, for a less important reason and for a more important reason.
(1) The less important reason is that "/pci@i0cf8/*@6" is a string that would never be generated by QEMU, as a bootorder entry. QEMU places specific OpenFirmware device paths into the "bootorder" fw_cfg file. Only SeaBIOS uses patterns like "*@6", for matching.
The suggestion in the SeaBIOS wiki at <https://www.seabios.org/Runtime_config>, namely:
"However, it's safe to just copy and paste the pattern into bootorder."
is wrong, generally speaking. It might work if we consider SeaBIOS exclusively -- in that SeaBIOS would manage to parse those entries --, but they are invalid if we consider QEMU (not to mention OVMF).
(2) But, point (1) doesn't even matter much. The more important reason why this report is invalid is that the "bootorder" fw_cfg file is under the sole ownership of QEMU. "docs/specs/fw_cfg.txt" explains, in section "Externally Provided Items":
"""
Use of names not beginning with "opt/" is potentially dangerous and
entirely unsupported. QEMU will warn if you try.
"""
And that matches reality, on my end:
$ qemu-system-x86_64 -fw_cfg name=bootorder,string='/pci@i0cf8/*@6'
qemu-system-x86_64: -fw_cfg name=bootorder,string=/pci@i0cf8/*@6: warning: externally provided fw_cfg item names should be prefixed with "opt/"
The right way for controlling boot order is to use "bootindex=N" properties with the storage front-end devices. For exampe:
...
-device virtio-blk-pci,drive=system-disk,bootindex=1 \
-device scsi-cd,drive=installer-iso,bus=scsi0.0,bootindex=2 \
...
Hah! Thanks, I don't know how I missed the existence of bootindex (given that it looks like it went in in 2011 and is in the docs once I know the name to search for.) I was probably conflating it with the index= option.
I did see the warning, and my reaction was "that must apply to other uses than actually passing things to seabios, since that'll just stop it from looking at them, and isn't that the entire point of the option?" Apparently not, but the warning didn't particular suggest otherwise.
Thank you very much for taking the time to respond in detail (bootindex entirely solves my problem.)
|