The following list is bollocks. There were many, many more.
Conflicts:
core-modules/003QubesTemplateVm.py
core-modules/005QubesNetVm.py
core/qubes.py
core/storage/__init__.py
core/storage/xen.py
doc/qvm-tools/qvm-pci.rst
doc/qvm-tools/qvm-prefs.rst
qubes/tools/qmemmand.py
qvm-tools/qvm-create
qvm-tools/qvm-prefs
qvm-tools/qvm-start
tests/__init__.py
vm-config/xen-vm-template-hvm.xml
This commit took 2 days (26-27.01.2016) and put our friendship to test.
--Wojtek and Marek
We still can't support running HVM template and its VMs simultaneously
(easily), but still, have root-cow.img handled for HVM template, to
allow qvm-revert-template-changes.
FixesQubesOS/qubes-issues#1573
In some (most) cases VM needs to be started to complete resize
operation. This may be unexpected, so make it clear and do not start the
VM when the user did not explicitly allow that.
FixesQubesOS/qubes-issues#1268
When /var/lib/qubes/appvms is a mount point of ext4 filesystem, there
will be already 'lost+found' directory. Avoid this conflict.
FixesQubesOS/qubes-issues#1440
The comment "calling VM have the same netvm" doesn't apply to:
- DispVM started from dom0 menu
- DispVM started from a VM with `dispvm_netvm` property modified
FixesQubesOS/qubes-issues#1334
When VM is shutting down it doesn't disconnect PCI frontend (?), so when
VM is destroyed it ends up in timeouts in PCI backend shutdown (which
can't communicate with frontend at that stage). Prevent this by
detaching PCI devices while VM is still running.
FixesQubesOS/qubes-issues#1494FixesQubesOS/qubes-issues#1425
I had some issue with fstrim and the missing else had caused the code to continue and fail later with a non-descriptive error message. This commit makes the error message more descriptive and helpful.
This is workaround for missing libxl/libvirt functionality: QubesOS/qubes-issues#1426
Also it should improve system shutdown time, as this is the situation
where all the VMs are shutting down simultaneously.
FixesQubesOS/qubes-issues#1425
Forgetting this leads to misterious errors (VM started with different
kernel than it was just set), so simplify the API.
FixesQubesOS/qubes-issues#1400
When using PVGrub it doesn't make sense to attach modules.img, since
modules are already in the VM. Initramfs there will already handle such
situation and will not try to mount it, when VM's root filesystem
already contains appropriate /lib/modules/`uname -r`.
On the other hand, error earlier when initramfs is missing. While also
not used by PV Grub, the file is always specified in libvirt config and
when missing libvirt will throw rather cryptic error message.
QubesOS/qubes-issues#1354
1. Do not start GUI session - to reduce startup time
2. Use user="root" instead of sudo - not all templates have sudo
installed (for example fedora-21-minimal)
3. Add missing wait=True - otherwise VM may be shutdown during the
operation.
QubesOS/qubes-issues#1268
This process may be running as root in case of default NetVM. But do not
kill it forcibly (through sudo or so), because it may also be stale
pid file. After all, QubesDB should automatically terminate when its VM
is terminated, so this code is already some error handling.
FixesQubesOS/qubes-issues#1331
* qubesos/pr/7:
Don't send screen layout to the VM if we haven't received it from xrandr because this breaks proper initial screen layout set by gui-agent FixesQubesOS/qubes-issues#1305QubesOS/qubes-issues#998
If /etc/localtime in dom0 is a hardlink to zoneinfo file (instead of
symlink) and more than one zoneinfo file is hardlinked to this inode,
appVMs will get invalid timezone, e.g. "Europe/Warsaw\x0aPoland".
Reported by @yaqu, fix provided by @yaqu
FixesQubesOS/qubes-issues#1315
When restarting VM (starting it just after it was shut down), it may
happen that previous `qubesdb-daemon` instance is still running - if VM
doesn't properly terminate the connection, dom0 part will not terminate
immediately, but at next alive check (every 10s). Such `qubesdb-daemon`,
when terminating, will remove pid file and socket file. In case of new
daemon already running it would be those of the new daemon, making the
whole QubesDB of this VM inaccessible for dom0 (`qubesdb-daemon` is
running, but its socket is removed).
To prevent this race, ensure that previous instance is terminated before
starting the new one.
There is no need to manually removing socket file, because if some stale
socket exists, it will be replaced by the new one when new
`qubesdb-daemon` starts up.
QubesOS/qubes-issues#1241
This makes easier to handle some corner cases. One of them is having
entry without `dir_path` defined. This may happen when migrating from R2
(using backup+restore or in-place) while some DisposableVM was running
(even if not included in the backup itself).
Fixesqubesos/qubes-issues#1124
Reported by @doncohen, thanks @wyory for providing more details.
