​Thanks KC, that makes it interesting. On a restart it stops the service and starts it again - so there is nothing the running program could take over other than what is in config files. Yet on a reboot just the same happens, the difference is that the kernel might have lost some context on the reboot.
While I still can't reproduce in my SAN env which doesn't have a concept like the LUNZ->VRAID transition I wonder if we could somehow force your environment to pick up the new data other than rebooting. rescan-scsi-bus.sh has various options which might help here, please try them one by one (ordered by increased potential impact to your system) --forcerescan (rescan existing devs) --issue-lip (login reset, not sure if that works on your devs or might reset your provisioning) --forceremove (drop and re-add each device) rescan-scsi-bus.sh should call that (also one of the devices changed for you), but to make sure this is not taking any path through rescan-scsi-bus.sh that ends without issuing this you could also run as root: $ echo 1 > /sys/block/device_name/device/rescan Please let me know if any of above four options would get your device properly detected. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1671397 Title: A VNX LUN will still be recognized as LUNZ after provisioning To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1671397/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
