Bug 1462696 - Impossible to say "no" to fsadm
Impossible to say "no" to fsadm
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2 (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Zdenek Kabelac
cluster-qe@redhat.com
: Regression
Depends On:
Blocks: 1459279
  Show dependency treegraph
 
Reported: 2017-06-19 06:19 EDT by Marius Vollmer
Modified: 2017-08-01 17:54 EDT (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.171-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 17:54:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marius Vollmer 2017-06-19 06:19:31 EDT
Description of problem:

When fsadm asks "Do you want to unmount?" there is no way to answer "no".

Version-Release number of selected component (if applicable):
lvm2-2.02.171-4.el7

How reproducible:
Always

Steps to Reproduce:
1. Try to shrink a mounted ext4 filesystem
2. Type "n<RET>"

Actual results:
# /usr/sbin/fsadm resize /dev/TEST/vol 209715200b
Do you want to unmount "/run/media/admin/FSYS"? [Y|n] y
fsck from util-linux 2.23.2
FSYS: 11/102400 files (0.0% non-contiguous), 19342/409600 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/TEST-vol to 204800 (1k) blocks.
The filesystem on /dev/mapper/TEST-vol is now 204800 blocks long.

mount: mount point /run/media/admin/FSYS does not exist


Expected results:
fsadm exits without resizing the filesystem 

Additional info:
This is the code in question:

yes_no() {
    echo -n "$@? [Y|n] "

    if [ -n "$YES" ]; then
        echo y ; return 0
    fi

    while read -r -s -n 1 ANS ; do
        echo $ANS
        case "$ANS" in
            "y" | "Y" ) echo y ; return 0 ;;
            "" ) if [ -t 1 ] ; then
                     echo y ; return 0
                 fi ;;
        esac
    done

    echo n
    return 1
}

You can see that when $AND equals "n", the loops just continues and the "n" is ignored.  "read" will only return 1 when stdin gets a EOF which it doesn't when it is connected to the terminal.
Comment 2 Marius Vollmer 2017-06-19 06:52:42 EDT
> This is the code in question:

This was from sourceware.org, no idea whether the RPM has been patched in this area.
Comment 3 Zdenek Kabelac 2017-06-19 06:57:58 EDT
Oops  mea culpa

Fixed upstream in this commit:

https://www.redhat.com/archives/lvm-devel/2017-June/msg00063.html


Still part of 2.02.172 release  (which is mostly in 7.4 build)

Hopefully this small fix will get into final build.
Comment 4 Marius Vollmer 2017-06-19 07:22:53 EDT
I can't say I like how the behavior without tty has changed from "yes" to "no".
Comment 5 Zdenek Kabelac 2017-06-19 07:28:46 EDT
That's been clear bug which needed a fix.

If user wants an automatic answer '-y'  then he need to use:  'fsadm --yes'.

Otherwise script worked like if --yes was given...
Comment 6 Marius Vollmer 2017-06-19 08:13:18 EDT
(In reply to Zdenek Kabelac from comment #5)
> That's been clear bug which needed a fix.

https://www.youtube.com/watch?v=pWdd6_ZxX8c :-)
Comment 8 Zdenek Kabelac 2017-06-21 08:08:06 EDT
And there was a related issue when user runs  'lvresize'  it now has to use --yes when using fsadm.


lvresize --yes -L-10 -r vg/lvol


Is the proper way to avoid prompting.

Fixed with commit:

https://www.redhat.com/archives/lvm-devel/2017-June/msg00085.html
Comment 10 Zdenek Kabelac 2017-06-22 14:44:12 EDT
*** Bug 1462660 has been marked as a duplicate of this bug. ***
Comment 11 Corey Marthaler 2017-06-22 19:38:52 EDT
Marking verified in the latest rpms. 

3.10.0-685.el7.x86_64
lvm2-2.02.171-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
lvm2-libs-2.02.171-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
lvm2-cluster-2.02.171-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
device-mapper-1.02.140-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
device-mapper-libs-1.02.140-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
device-mapper-event-1.02.140-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
device-mapper-event-libs-1.02.140-7.el7    BUILT: Thu Jun 22 08:35:15 CDT 2017
device-mapper-persistent-data-0.7.0-0.1.rc6.el7    BUILT: Mon Mar 27 10:15:46 CDT 2017



I believe these are all the scenarios:

# initial bug

[root@host-092 ~]# lvreduce -L -300M /dev/snapper_thinp/origin
  WARNING: Reducing active and open logical volume to <1.20 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce snapper_thinp/origin? [y/n]: y
  Size of logical volume snapper_thinp/origin changed from <1.49 GiB (381 extents) to <1.20 GiB (306 extents).
  Logical volume snapper_thinp/origin successfully resized.

[root@host-092 ~]#  /usr/sbin/fsadm resize /dev/snapper_thinp/origin
Do you want to unmount "/mnt/origin"? [Y|n] n
fsadm: Cannot proceed with mounted filesystem "/mnt/origin".


# After recreation due to the resize fs corruption

[root@host-092 ~]# lvextend -L +500M /dev/snapper_thinp/origin
  WARNING: Sum of all thin volume sizes (8.46 GiB) exceeds the size of thin pool snapper_thinp/POOL (6.00 GiB)!
  For thin pool auto extension activation/thin_pool_autoextend_threshold should be below 100.
  Size of logical volume snapper_thinp/origin changed from <1.98 GiB (506 extents) to 2.46 GiB (631 extents).
  Logical volume snapper_thinp/origin successfully resized.

[root@host-092 ~]#  /usr/sbin/fsadm resize /dev/snapper_thinp/origin
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/mapper/snapper_thinp-origin is mounted on /mnt/origin; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mapper/snapper_thinp-origin is now 646144 blocks long.

[root@host-092 ~]# lvresize -L -200M -r /dev/snapper_thinp/origin
Do you want to unmount "/mnt/origin"? [Y|n] n
fsadm: Cannot proceed with mounted filesystem "/mnt/origin".
  /usr/sbin/fsadm failed: 1
  Filesystem resize failed.

[root@host-092 ~]# lvresize -L -200M -r /dev/snapper_thinp/origin
Do you want to unmount "/mnt/origin"? [Y|n] y
fsck from util-linux 2.23.2
/dev/mapper/snapper_thinp-origin: 11/163840 files (0.0% non-contiguous), 19252/646144 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/snapper_thinp-origin to 594944 (4k) blocks.
The filesystem on /dev/mapper/snapper_thinp-origin is now 594944 blocks long.

  Size of logical volume snapper_thinp/origin changed from 2.46 GiB (631 extents) to <2.27 GiB (581 extents).
  Logical volume snapper_thinp/origin successfully resized.

[root@host-092 ~]# lvresize --yes -L -200M -r /dev/snapper_thinp/origin
Do you want to unmount "/mnt/origin"? [Y|n] y
fsck from util-linux 2.23.2
/dev/mapper/snapper_thinp-origin: 11/155648 files (0.0% non-contiguous), 18738/594944 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/snapper_thinp-origin to 543744 (4k) blocks.
The filesystem on /dev/mapper/snapper_thinp-origin is now 543744 blocks long.

  Size of logical volume snapper_thinp/origin changed from <2.27 GiB (581 extents) to 2.07 GiB (531 extents).
  Logical volume snapper_thinp/origin successfully resized.
Comment 12 errata-xmlrpc 2017-08-01 17:54:18 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2222

Note You need to log in before you can comment on or make changes to this bug.