[Ubuntu-ha] [Bug 1864087] Re: Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs merge
This bug was fixed in the package corosync - 3.0.3-2ubuntu1
---
corosync (3.0.3-2ubuntu1) focal; urgency=medium
* Merge with Debian unstable (LP: #1864087). Remaining changes:
- Skip autopkgtest for unprivileged containers: (LP: 1828228)
- d/t/control: allow stderr and mark tests as skippable
- d/t/{cfgtool,quorumtool}: skips when inside unpriv containers
corosync (3.0.3-2) unstable; urgency=medium
* [d0a06e5] Separate the autopkgtests and make them generate artifacts
* [8680d48] Run Salsa CI reprotest with diffoscope
* [1d89c4f] Recognize the autopkgtest artifacts in Salsa CI
* [8e09226] New patch: man: move cmap_keys man page from section 8 to 7
corosync (3.0.3-1) unstable; urgency=medium
* [d103a33] New upstream release (3.0.3)
* [e6f6831] Refresh our patches
* [f1e85a3] Enable nozzle support
* [19d3dd3] Package the votequorum simulator in corosync-vqsim
* [8ae3235] Update Standards-Version to 4.4.1 (no changes required)
* [bfd9560] Advertise Rules-Requires-Root: no
-- Rafael David Tinoco Fri, 21 Feb 2020
04:33:11 +
** Changed in: corosync (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1864087
Title:
Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs
merge
Status in corosync package in Ubuntu:
Fix Released
Bug description:
Package: corosync (debian: 3.0.3-2, ubuntu: 3.0.2-1ubuntu2) needs
merge
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1864087/+subscriptions
___
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : ubuntu-ha@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
[Ubuntu-ha] [Bug 1866119] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + OBS: This bug was originally into LP: #1865523 but it was split. + + SRU: pacemaker + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, + since the later was fixed at LP: #1865523. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see the following errors: + + Failed Actions: + * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms + * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms + * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', + last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms + + and corosync.log will show: + + warning: unpack_rsc_op_failure: Processing failed op start for + fence_clubionic on clubionic01: unknown error (1) + + [Regression Potential] + + * LP: #1865523 shows fence_scsi fully operational after SRU for that + bug is done. + + * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix + fence_scsi. + + * TODO + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: - fence_clubionic (stonith:fence_scsi): Started clubionic01.private + fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda - LIO-ORG cluster.bionic. 4.0 - Peripheral device type: disk - PR generation=0x0, there are NO registered reservation keys + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** No longer affects: pacemaker (Ubuntu) ** No longer affects: pacemaker (Ubuntu Bionic) ** Description changed: + OBS: I have split this bug into 2 bugs: + - fence-agents (this) and pacemaker (LP: #1866119) + SRU: fence-agents [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, one might try the following command: sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off from nodes "clubionic02 or clubionic03" and check if the reservation worked: (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# property symmetric-cluster=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see that crm_mon won't show fence_clubionic resource operational. [Regression Potential] - * Comments #3 and #4 show this new version fully working. - - * This fix has a potential of breaking other "nowadays working" fencing agent. If that happens, I suggest that ones affected revert previous to previous package AND open a bug against either pacemaker and/or fence-agents. + * Comments #3 and #4 show this new version fully working. + + * This fix has a potential of breaking other "nowadays working" fencing + agent. If that happens, I suggest that ones affected revert previous to + previous package AND open a bug against either pacemaker and/or fence- + agents. * Judging by this issue, it is very likely that any Ubuntu user that have tried using fence_scsi has probably migrated to a newer version because fence_scsi agent is broken since its release. * The way I fixed fence_scsi was this: I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I could bisect fence-agents. At that moment I realized that bisecting was going to be hard because there were multiple issues, not only one. I backported the latest fence-agents together with Pacemaker 1.1.19-0 and saw that it worked. From then on, I bisected the following intervals: 4.3.0 .. 4.4.0 (eoan - working) 4.2.0 .. 4.3.0 4.1.0 .. 4.2.0 4.0.25 .. 4.1.0 (bionic - not working) In each of those intervals I discovered issues. For example, Using 4.3.0 I faced problems so I had to backport fixes that were in between 4.4.0 and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at 4.0.25 version, current Bionic fence-agents version. [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \
[Ubuntu-ha] [Bug 1866119] [NEW] [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
Public bug reported: OBS: This bug was originally into LP: #1865523 but it was split. SRU: pacemaker [Impact] * fence_scsi is not currently working in a share disk environment * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't be able to start the fencing agents OR, in worst case scenarios, the fence_scsi agent might start but won't make scsi reservations in the shared scsi disk. * this bug is taking care of pacemaker 1.1.18 issues with fence_scsi, since the later was fixed at LP: #1865523. [Test Case] * having a 3-node setup, nodes called "clubionic01, clubionic02, clubionic03", with a shared scsi disk (fully supporting persistent reservations) /dev/sda, with corosync and pacemaker operational and running, one might try: rafaeldtinoco@clubionic01:~$ crm configure crm(live)configure# property stonith-enabled=on crm(live)configure# property stonith-action=off crm(live)configure# property no-quorum-policy=stop crm(live)configure# property have-watchdog=true crm(live)configure# commit crm(live)configure# end crm(live)# end rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ stonith:fence_scsi params \ pcmk_host_list="clubionic01 clubionic02 clubionic03" \ devices="/dev/sda" \ meta provides=unfencing And see the following errors: Failed Actions: * fence_clubionic_start_0 on clubionic02 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:12 2020', queued=0ms, exec=1105ms * fence_clubionic_start_0 on clubionic03 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:13 2020', queued=0ms, exec=1109ms * fence_clubionic_start_0 on clubionic01 'unknown error' (1): call=6, status=Error, exitreason='', last-rc-change='Wed Mar 4 19:53:11 2020', queued=0ms, exec=1108ms and corosync.log will show: warning: unpack_rsc_op_failure: Processing failed op start for fence_clubionic on clubionic01: unknown error (1) [Regression Potential] * LP: #1865523 shows fence_scsi fully operational after SRU for that bug is done. * LP: #1865523 used pacemaker 1.1.19 (vanilla) in order to fix fence_scsi. * TODO [Other Info] * Original Description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic (stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held ** Affects: pacemaker (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: In Progress ** Also affects: pacemaker (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pacemaker (Ubuntu) Status: New => Fix Released ** Changed in: pacemaker (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1866119 Title: [bionic] fence_scsi not working
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Description changed: + SRU: fence-agents + + [Impact] + + * fence_scsi is not currently working in a share disk environment + + * all clusters relying in fence_scsi and/or fence_scsi + watchdog won't + be able to start the fencing agents OR, in worst case scenarios, the + fence_scsi agent might start but won't make scsi reservations in the + shared scsi disk. + + [Test Case] + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, one might try the following command: + + sudo fence_scsi --verbose -n clubionic01 -d /dev/sda -k 3abe -o off + + from nodes "clubionic02 or clubionic03" and check if the reservation + worked: + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there are NO registered reservation keys + + (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda + LIO-ORG cluster.bionic. 4.0 + Peripheral device type: disk + PR generation=0x0, there is NO reservation held + + * having a 3-node setup, nodes called "clubionic01, clubionic02, + clubionic03", with a shared scsi disk (fully supporting persistent + reservations) /dev/sda, with corosync and pacemaker operational and + running, one might try: + + rafaeldtinoco@clubionic01:~$ crm configure + crm(live)configure# property stonith-enabled=on + crm(live)configure# property stonith-action=off + crm(live)configure# property no-quorum-policy=stop + crm(live)configure# property have-watchdog=true + crm(live)configure# property symmetric-cluster=true + crm(live)configure# commit + crm(live)configure# end + crm(live)# end + + rafaeldtinoco@clubionic01:~$ crm configure primitive fence_clubionic \ + stonith:fence_scsi params \ + pcmk_host_list="clubionic01 clubionic02 clubionic03" \ + devices="/dev/sda" \ + meta provides=unfencing + + And see that crm_mon won't show fence_clubionic resource operational. + + [Regression Potential] + + * Judging by this issue, it is very likely that any Ubuntu user that + have tried using fence_scsi has probably migrated to a newer version + because fence_scsi agent is broken since its release. + + * The way I fixed fence_scsi was this: + + I packaged pacemaker in latest 1.1.X version and kept it "vanilla" so I + could bisect fence-agents. At that moment I realized that bisecting was + going to be hard because there were multiple issues, not only one. I + backported the latest fence-agents together with Pacemaker 1.1.19-0 and + saw that it worked. + + From then on, I bisected the following intervals: + + 4.3.0 .. 4.4.0 (eoan - working) + 4.2.0 .. 4.3.0 + 4.1.0 .. 4.2.0 + 4.0.25 .. 4.1.0 (bionic - not working) + + In each of those intervals I discovered issues. For example, Using 4.3.0 + I faced problems so I had to backport fixes that were in between 4.4.0 + and 4.3.0. Then, backporting 4.2.0, I faced issues so I had to backport + fixes from the 4.3.0 <-> 4.2.0 interval. I did this until I was at + 4.0.25 version, current Bionic fence-agents version. + + [Other Info] + + * Original Description: + Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ - params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ - meta provides=unfencing + params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ + meta provides=unfencing property cib-bootstrap-options: \ - have-watchdog=false \ - dc-version=1.1.18-2b07d5c5a9 \ - cluster-infrastructure=corosync \ - cluster-name=clubionic \ - stonith-enabled=on \ - stonith-action=off \ - no-quorum-policy=stop \ - symmetric-cluster=true + have-watchdog=false \ + dc-version=1.1.18-2b07d5c5a9 \ + cluster-infrastructure=corosync \ + cluster-name=clubionic \ + stonith-enabled=on \ + stonith-action=off \ + no-quorum-policy=stop \ + symmetric-cluster=true
[Ubuntu-ha] [Bug 1865523] Re: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1
** Merge proposal linked: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/fence-agents/+git/fence-agents/+merge/380242 -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to pacemaker in Ubuntu. https://bugs.launchpad.net/bugs/1865523 Title: [bionic] fence_scsi not working properly with 1.1.18-2ubuntu1.1 Status in fence-agents package in Ubuntu: Fix Released Status in pacemaker package in Ubuntu: Fix Released Status in fence-agents source package in Bionic: Confirmed Status in pacemaker source package in Bionic: Confirmed Status in fence-agents source package in Disco: Confirmed Status in fence-agents source package in Eoan: Fix Released Status in fence-agents source package in Focal: Fix Released Bug description: Trying to setup a cluster with an iscsi shared disk, using fence_scsi as the fencing mechanism, I realized that fence_scsi is not working in Ubuntu Bionic. I first thought it was related to Azure environment (LP: #1864419), where I was trying this environment, but then, trying locally, I figured out that somehow pacemaker 1.1.18 is not fencing the shared scsi disk properly. Note: I was able to "backport" vanilla 1.1.19 from upstream and fence_scsi worked. I have then tried 1.1.18 without all quilt patches and it didnt work as well. I think that bisecting 1.1.18 <-> 1.1.19 might tell us which commit has fixed the behaviour needed by the fence_scsi agent. (k)rafaeldtinoco@clubionic01:~$ crm conf show node 1: clubionic01.private node 2: clubionic02.private node 3: clubionic03.private primitive fence_clubionic stonith:fence_scsi \ params pcmk_host_list="10.250.3.10 10.250.3.11 10.250.3.12" devices="/dev/sda" \ meta provides=unfencing property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.18-2b07d5c5a9 \ cluster-infrastructure=corosync \ cluster-name=clubionic \ stonith-enabled=on \ stonith-action=off \ no-quorum-policy=stop \ symmetric-cluster=true (k)rafaeldtinoco@clubionic02:~$ sudo crm_mon -1 Stack: corosync Current DC: clubionic01.private (version 1.1.18-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 2 15:55:30 2020 Last change: Mon Mar 2 15:45:33 2020 by root via cibadmin on clubionic01.private 3 nodes configured 1 resource configured Online: [ clubionic01.private clubionic02.private clubionic03.private ] Active resources: fence_clubionic(stonith:fence_scsi): Started clubionic01.private (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist --in --read-keys --device=/dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there are NO registered reservation keys (k)rafaeldtinoco@clubionic02:~$ sudo sg_persist -r /dev/sda LIO-ORG cluster.bionic. 4.0 Peripheral device type: disk PR generation=0x0, there is NO reservation held To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-ha Post to : ubuntu-ha@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
