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
|
<think>
Okay, so I need to classify this bug report from QEMU into one of the given categories. Let's start by understanding what the problem is.
The user reported that NVRAM variables aren't persistent across coldboots when there's no attached r/w FAT32 hard drive. They mentioned that without a hard drive, after editing NVRAM variables and doing a cold reboot, the changes are lost. But with a hard drive attached, it works fine because the NvVars file is modified and persists.
Looking at the steps to reproduce: When there's no hard drive, they edit an NVRAM variable, shutdown, restart, and the changes revert. With a hard drive, the variables do persist because the filesystem saves them.
So the issue seems related to how QEMU handles NVRAM persistence without a persistent storage device. Since NVRAM relies on some form of storage to retain data between reboots, the lack of it causes the problem.
Now, looking at the categories: The options include things like "boot," "files," "permissions," and others. This bug is about variables not persisting across cold boots without a hard drive. That sounds related to how QEMU handles storage devices and their filesystems during the boot process.
The key here is that NVRAM persistence relies on having a writable file, which in this case is only present when a hard drive is attached. So without it, the changes are lost after a cold reboot. This affects the EFI shell's ability to retain settings across reboots.
I think the problem relates more to how QEMU initializes or handles storage during the boot process, specifically regarding NVRAM variables. Since the issue occurs when no hard drive is attached, it points to a missing or incorrect handling of the default storage for NVRAM persistence.
Looking at the categories again: "boot" seems relevant because it's about the VM's boot process not retaining certain settings without a hard drive. Alternatively, "files" might be applicable if it's related to how files are persisted across reboots.
But considering that NVRAM is part of the firmware and its persistence depends on having a filesystem (like FAT32) attached, the issue could be under "boot" as it affects the boot process and initialization. Alternatively, it might fall under "files" if it's about how files are managed in QEMU.
Wait, the user mentioned that without the hard drive, even though warm reboots (like via reset) retain changes, cold boots do not. That suggests it's more about the boot process's handling of NVRAM variables when no persistent storage is attached. So perhaps "boot" is the right category because it's related to how QEMU initializes and persists NVRAM during the boot sequence.
Alternatively, since NVRAM uses a file (NvVars) on the filesystem for persistence, maybe it's more about "files." But I think the primary issue is that without a hard drive attached, QEMU isn't persisting NVRAM variables across cold reboots. This seems like a boot-time initialization problem where the necessary storage isn't present.
So after considering, I think "boot" is the appropriate category because it's about how the VM initializes and handles persistence during the boot process without an attached hard drive.
</think>
boot
|