Your message dated Mon, 10 Sep 2018 20:17:33 +0200
with message-id
<caatjj0kekx3mwssumsklvu3euvy0mtqerszwwphmgtzfyce...@mail.gmail.com>
and subject line Re: Bug#908475: d/p/debian/scsi-udev-rule no more needed?
has caused the Debian Bug report #908475,
regarding d/p/debian/scsi-udev-rule no more needed?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
908475: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908475
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: open-vm-tools
Version: 2:10.3.0-1
Hi Bernd,
due to a Ubuntu bug report [1] I came to realize that the old delta we had
to make the rule working these days seems to do the inverse.
With d/p/debian/scsi-udev-rule applied it has no effect, but dropping it
seems to resolve the issue.
So it seems these days the udev rules as provided upstream are good as-is
and we could drop that.
Could you take a look if the same is true for your environments and if so
consider dropping this Delta to upstream?
[1]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1790145
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
--- End Message ---
--- Begin Message ---
On Mon, Sep 10, 2018 at 4:50 PM Christian Ehrhardt <
[email protected]> wrote:
> > So it seems these days the udev rules as provided upstream are good
>> > as-is and we could drop that.
>>
>> There was a bug report where the upstream were reported as buggy,
>> resulting in that patch.
>>
>> https://github.com/bzed/pkg-open-vm-tools/pull/10
>>
>>
>> So right now I can't see whats wrong with the current udev rules as
>> they work for me in wheezy/jessie/stretch/buster. Also I don't think
>> that running /bin/sh to set values in /sys is the appropriate way
>> if there is a way around that.
>>
>
> First of all thanks for your immediate answer.
>
> I wanted to quickly reply as well, but deploying my guest is blocked by so
> many things at the moment (mostly memory).
> I want to check on my own how it behaves in the Ubuntu version I got the
> report and if it is any different to Debian/sid.
>
Got hold of a system to test that.
You are absolutely right, the rules I assumed to be the same are not.
There seem to be three versions:
Upstream - work but echo??
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo
180 >/sys$DEVPATH/device/timeout
'"
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="VMware Virtual S", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c
'echo 180 >/sys$DEVPATH/device/time
out'"
Debian - work and look nice
ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device",
ATTRS{vendor}=="VMware*" , ATTRS{model}=="Virtual disk*",
ATTRS{timeout}=="?*", ATTR{timeout}="180"
ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device",
ATTRS{vendor}=="VMware*" , ATTRS{model}=="VMware Virtual S",
ATTRS{timeout}=="?*", ATTR{timeout}="180"
Ubuntu - don't work
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}=="disk", ATTR{timeout}="180"
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="VMware Virtual S", ENV{DEVTYPE}=="disk", ATTR{timeout}="180"
I need to sort out from where ours are, but they surely are our fault that
I need to sort out.
But it is too late for that today :-)
Sorry for the noise and thank you.
Closing the bug.
Given this takes much longer than it should I wanted to let you know that
> I'll report back here what I find as soon as it works.
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
--- End Message ---
