For open-vm-tools this issue will only exist with the planned backport of the
newer version.
Since we will not ship the broken backport as we found it in pre-checks the
correct state for open-vm-tools in xenial is invalid.
** Changed in: open-vm-tools (Ubuntu Xenial)
Status: Triaged =>
Installed another Xenial and Bionic in vmware to take a deper look.
- Xenial (with backported open-vm-tools): affected
- Bionic (with the interim fix reverted): no hit in several retries,
explanation below
Systemd fixed it (via our assumed implicit dependency).
In Bionic the PrivateTmp gives it
1. I updated the ppa we test for a potential xenial-backport.
It now has 10.2.0-3ubuntu0.16.04.1~ppa2 with the fix applied
2. Pushed said fix to Bionic [1] (need to check proposed migration)
3. reported the same to Debian, but then found [2] and chimed in there
[1]:
cloud-init task was just for discussion, marking it invalid to make
clear there is no cloud-init action needed.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Public bug reported:
Since the change in [1] open-vm-tools-service starts very (very) early.
Not so much due to the
Before=cloud-init-local.service
But much more by
DefaultDependencies=no
That can trigger an issue that looks like
root@ubuntuguest:~# systemctl status -l open-vm-tools.service
●
Public bug reported:
When installing cloud-init in vmware without any setup for user/vendor
data it breaks the ubuntu user.
Steps to reproduce:
1. take vmwre (free 30 days is fine)
2. install xenial (maybe newer as well but my case was xenial)
3. set up your user to be ubuntu/ubuntu (through the
** Also affects: cloud-init
Importance: Undecided
Status: New
** Also affects: cloud-images
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Cleaning this after a while, no further action is needed.
- T/X have a workaround in Neutron
- Latter versions of keepalive use systemd MAINPID tracking which is somewhat
more robust in this regard
That said in the context this appeared it is fixed, lets set the old
tasks to Won't Fix unless
Since it is a wanted behavioral change in upstream qemu setting that task to
"Won't Fix" unless we come up with a reason to convince qemu to do so.
Once might argue that info should imply force-share or such, but unless we do
so make clear that no qemu change is expected.
James already mentioned
Hi trying to get the status right here.
AFAIK these things are changed in libvirt 3.2 to be good - at least for x86,
not sure if/how arm followed but since there were major changes we should
consider it fixed and re-analyze from there for the development release.
So the coming merge of a newer
Added neturon/UCA tasks so it shows up more obviously for the Triagers
of those components
** Also affects: neutron (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cloud-archive
Importance: Undecided
Status: New
--
You received this bug notification because you
Seems like a race in populating and using the labels on the disks (or an I/O
error, but I haven't found one in the log).
In any case I think this should get to the attention of the kernel Team.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Triaged
** Changed in: qemu (Ubuntu)
Importance: Undecided => High
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
13 matches
Mail list logo
