This bug was fixed in the package open-vm-tools -
2:10.3.0-0ubuntu1~18.04.2
---
open-vm-tools (2:10.3.0-0ubuntu1~18.04.2) bionic; urgency=medium
* d/p/ubuntu/lp-1791220-Disable-hgfsServer-not-VMware.patch: avoid crashing
with segfaults when force starting the service in non VMWa
The following log shows the issue before the fix, an upgrade to the
version in proposed and then the fixed situation after the fix.
We checked the same code generally from the identical PPA we built
before.
ubuntu@node-1:~$ for i in /sys/block/sd*/device/timeout; do echo $i; cat $i;
done
/sys/bl
Hello T., or anyone else affected,
Accepted open-vm-tools into bionic-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/open-vm-
tools/2:10.3.0-0ubuntu1~18.04.2 in a few hours, and then in the
-proposed repository.
Please help us by testing this new pac
- SRU Template complete
- Cosmic fixed and confirmed (I retested on vSphere)
- Since other than the version in changelog latest -dev and LTS are kept in
sync the MP we had for cosmic essentially applies here as well.
Pushing the same fix to Bionic, now available in -unapproved for the SRU
Teams c
- SRU Template complete
- Cosmic fixed and confirmed (I retested on vSphere)
- Since other than the version in changelog latest -dev and LTS are kept in
sync the MP we had for cosmic essentially applies here as well.
Pushing the same fix to Bionic, now available in -unapproved for the SRU
Teams c
** Also affects: open-vm-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: open-vm-tools (Ubuntu Bionic)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
This bug was fixed in the package open-vm-tools - 2:10.3.0-0ubuntu2
---
open-vm-tools (2:10.3.0-0ubuntu2) cosmic; urgency=medium
* d/p/ubuntu/lp-1791220-Disable-hgfsServer-not-VMware.patch: avoid crashing
with segfaults when force starting the service in non VMWare environments.
** Changed in: open-vm-tools (Debian)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790145
Title:
99-vmware-scsi-udev.rules has no effect - timeout by 30 not 180
But merging we tried to follow upstream more, so we dropped
ATTRS{timeout}=="?*"
but keeping the nicer Debian style
ATTR{timeout}="180"
But while not perfect that would still work.
But the other part was about DEVTYPE which upstream has adopted.
So we exchanged Debians
ENV{DEVTYPE}=="scsi_d
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/354555
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790145
Title:
99-vmware
Hmm,
the Debian maintainer said it works fine for him.
I OTOH finally got a VM System as well and I can confirm the 30 seconds.
$ cat /sys/block/sd[a-c]/device/timeout
30
30
30
Reverting the udev rule change helps me just as much as it helped you
Timo.
I verified and wonder where these rules a
** Changed in: open-vm-tools (Debian)
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790145
Title:
99-vmware-scsi-udev.rules has no effect - timeout by 30 not 180
To m
FYI: Reported to Debian as well, linked the bug here
** Bug watch added: Debian Bug tracker #908475
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908475
** Also affects: open-vm-tools (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908475
Importance: Unknown
Sta
Hi Christian,
no problem at all.
To your questions, yes with pleasure.
Any disk for a vmware guest should be/is (normally) affected by this rule.
You don`t need to do anything special at all.
You can verify the Type and Vendor with "lshw -C disk" and see if there is a
"Virtual disk" by vendor
** Description changed:
+ [Impact]
+
+ * Debian delta we had carried renders the udev rules of upstream
+dysfunctional.
+
+ * Drop the Debian Delta to follow upstream more closely and fix this
+ bug.
+
+ [Test Case]
+
+ * Set up a VMWare guest
+ * boot into that guest
+ * The disks a
Thanks for the quick turnaround.
That is a change that came in by Debian, which it seems we should remove
when on version 10.3 and >=Bionic.
@Oliver - I think you can abort your investigation as upstream is ok.
I have another fix for open-vm-tools in the pipe, I think I'll try to
address both in
Hi Christian,
changed the files on the same two systems again.
After reboot, the timeout is again 180.
So yes, confirmed.
The change will resolve the situtaion.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
Hi Timo,
I can't reproduce this (I'm sure the bug is right, but I lack the env to do
so), but maybe you could quickly check this for me.
Could you check if reverting the following change:
-ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}==
Hm, again.
I filed an internal bug. Thanks for reporting.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1790145
Title:
99-vmware-scsi-udev.rules has no effect - timeout by 30 not 180
To manage not
Hi Timo,
thanks you for the report! That is an interesting one for sure ...
I know that upstream modified these rules quite a lot for different
things not working as inteneded. I will not go ahead and try to modify
it right now and re-doing all the same errors over and over again.
Instead I subsc
20 matches
Mail list logo
