Red Hat Bugzilla – Bug 1462660
cockpit logical volume resize fails with error message
Last modified: 2017-06-28 12:22:56 EDT
Created attachment 1289046 [details]
Screenshot of error from tests
Description of problem:
During Cockpit upstream integration testing, a test to resize a logical volume fails unexpectedly.
First found in https://fedorapeople.org/groups/cockpit/logs/pull-6360-20170615-152828-dd09a8ca-verify-rhel-7-4/log.html
Version-Release number of selected component (if applicable):
Arch : x86_64
Version : 2.5.2
Release : 3.el
Steps to Reproduce:
Run integration tests for volume resize https://github.com/cockpit-project/cockpit/blob/0177950a4be3abaff3545a92f62e094956b2caa3/test/verify/check-storage-resize#L57
Error message, see screenshot. Trace in issue: https://github.com/cockpit-project/cockpit/issues/6960
This is caused by this change in lvm2 / fsadm:
This change might break usage from scripts in general, as it did for Cockpit.
lvm2 fixed long-term bug.
We cannot let 'script' running automatically in '--yes' mode.
Such option must be always given on command line and is also logged in metadata archive for analysis in case things went wrong somewhere.
So if lvm2 users do want to apply --yes automatically - such option needs to be passed in.
i.e. 'lvresize --yes....'
This BZ is essentially duplicate of bug 1462696 - where we have resolved this 'yes' issue for both 'lvresize' and 'fsadm'.
*** This bug has been marked as a duplicate of bug 1462696 ***
This is not a duplicate of bug 1462696.
This bug is about changing the default behavior of fsadm (nd indirectly lvresize): When stdin is connected to /dev/null, it used to unmount the filesystem if needed, now it fails.
To resolve this bug, we would need to either revert the default behavior of fsadm back to the old one, or decide that the new default behavior is correct and then close this bug as NOTABUG.
Closing this bug as NOTABUG means accepting that all uses of lvresize and fsadm need to be reviewed and possibly changed to pass "--yes".
Bug 1462696 is about the implementation of the new default behavior being broken.
It's been bug and inconsistency in fsadm letting it work in '--yes' mode without terminal without specifying --yes on command line - causing seriously ill behavior as unconfirmed actions may have destabilize user's system.
Lvm2 does not support/handle backward compatibility for bugs - such bug should have been reported immediately and not been abused. Writing software on top of buggy logic will simply stop working the day the bug is fixed.
There is no 'new default' as mentioned in a comment 4. There is always only one consistent default behavior in lvm2 tools.
With terminal by default - prompt waits for answer.
With no terminal - answer 'N' is selected (...was a bug in fsadm doing Y)
If user gives '--yes' - automatically answer 'Y'
If any software using lvm2 tools wants '--yes' answering for prompts it specifies '--yes' - it works this way for last decade.
There is no plan to reintroduce such bug back to lvm2.
If Cocpit needs '--yes' answering 'fsadm' and cannot simply add passing --yes - it maybe can switch to calling a 'wrapper' script i.e. 'fsadm_yes' which will exec system's fsadm and will add --yes argument this way. Eventually create it's own hidden 'fsadm' in private binary PATH which will be found and called instead of system's version of fsadm
As Lvm2 can't do any more here - passing this BZ to cocpit for more fixes.
Story continues in bug 1464953
*** This bug has been marked as a duplicate of bug 1464953 ***