Bug 569021 - mke2fs insists on user interaction even if stdin is not a tty and -F is passed
mke2fs insists on user interaction even if stdin is not a tty and -F is passed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-02-27 11:52 EST by David Zeuthen
Modified: 2013-03-05 23:01 EST (History)
7 users (show)

See Also:
Fixed In Version: e2fsprogs-1.41.10-5.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-11 08:23:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Zeuthen 2010-02-27 11:52:18 EST
I ran into this when calling mke2fs from udisks in response to a D-Bus method. The invocation is roughly 'mkfs.ext3 -F -L somelabel /dev/disk'. Neither of dtdin/stdout/stderr are tty's (isatty(3) returns 0).

The output is this

stderr:
 mke2fs 1.41.10 (10-Feb-2009)

stdout:
 /dev/dm-0 alignment is offset by 520192 bytes.
 This may result in very poor performance, (re)-partitioning suggested.
 Proceed anyway? (y,n) 

There are several problems here.

 1. Even if stdin _was_ a tty, mke2fs shouldn't ask questions in
    the first place since -F is passed

 2. Despite stdin not being a tty, mke2fs asks questions. You should
    really use isatty before doing this. 

 3. It would  be nice to have an option to make mke2fs ask questions
    even if stdin is not a tty. It would complement -F insofar that
    such an option could be considered the inverse. This shouldn't
    be the default though.

The current behavior makes mke2fs unsuitable for non-interactive use.
Comment 1 David Zeuthen 2010-02-27 11:54:14 EST
(In reply to comment #0)
> The current behavior makes mke2fs unsuitable for non-interactive use.    

Marking this as a blocker bug. Current behavior is probably breaking lots of other stuff we haven't found out about yet.
Comment 2 David Zeuthen 2010-02-27 11:55:02 EST
Also, passing -F twice doesn't help either.
Comment 3 Eric Sandeen 2010-03-01 13:56:32 EST
Bah, ok, this was my fault (I added the alignment stuff and the warning)

However, we shouldn't be misaligned so probably worth investigating that too.  :)

I'll fix up the question-asking though.
Comment 4 Eric Sandeen 2010-03-01 14:06:08 EST
I'l just stick an "if (!force)" around the y/n prompt, as is done in other locations.

Sorry about that!

-Eric
Comment 5 Mike Snitzer 2010-03-01 14:08:07 EST
(In reply to comment #0)
> I ran into this when calling mke2fs from udisks in response to a D-Bus method.
> The invocation is roughly 'mkfs.ext3 -F -L somelabel /dev/disk'. Neither of
> dtdin/stdout/stderr are tty's (isatty(3) returns 0).
> 
> The output is this
> 
> stderr:
>  mke2fs 1.41.10 (10-Feb-2009)
> 
> stdout:
>  /dev/dm-0 alignment is offset by 520192 bytes.

David,

Did the DM device (presumably LVM device?) get created from scratch under rawhide (2.6.33 kernel and LVM2 2.02.61) or was it preexisting?

Reason I ask is if it was created from scratch with LVM2 then alignment_offset for the device _should_ be zero.  'data_alignment_offset_detection' must be enabled in lvm.conf in order for this to "just work".  'data_alignment_detection' should also be enabled.

If lvm2 was upgraded, and you had a custom lvm.conf, the upgrade would create /etc/lvm/lvm.conf.rpmnew and preserve your old custom lvm.conf
Comment 6 Eric Sandeen 2010-03-01 15:01:42 EST
Sent a patch upstream:

http://marc.info/?l=linux-ext4&m=126747319409267&w=2
Comment 7 Eric Sandeen 2010-03-01 15:31:01 EST
Committed and built in e2fsprogs-1_41_10-5_fc13

-Eric
Comment 8 Fedora Update System 2010-03-01 15:38:57 EST
e2fsprogs-1.41.10-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/e2fsprogs-1.41.10-5.fc13
Comment 9 David Zeuthen 2010-03-02 13:47:20 EST
(In reply to comment #5)
> (In reply to comment #0)
> > I ran into this when calling mke2fs from udisks in response to a D-Bus method.
> > The invocation is roughly 'mkfs.ext3 -F -L somelabel /dev/disk'. Neither of
> > dtdin/stdout/stderr are tty's (isatty(3) returns 0).
> > 
> > The output is this
> > 
> > stderr:
> >  mke2fs 1.41.10 (10-Feb-2009)
> > 
> > stdout:
> >  /dev/dm-0 alignment is offset by 520192 bytes.
> 
> David,
> 
> Did the DM device (presumably LVM device?) get created from scratch under
> rawhide (2.6.33 kernel and LVM2 2.02.61) or was it preexisting?
> 
> Reason I ask is if it was created from scratch with LVM2 then alignment_offset
> for the device _should_ be zero.  'data_alignment_offset_detection' must be
> enabled in lvm.conf in order for this to "just work". 
> 'data_alignment_detection' should also be enabled.
> 
> If lvm2 was upgraded, and you had a custom lvm.conf, the upgrade would create
> /etc/lvm/lvm.conf.rpmnew and preserve your old custom lvm.conf    

FWIW, this happened on a dm-crypt device (backed by a primary MBR partition with alignment_offset==0) but I can't trigger it anymore...
Comment 10 Fedora Update System 2010-03-02 20:47:58 EST
e2fsprogs-1.41.10-5.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update e2fsprogs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-3349
Comment 11 Martin Pitt 2010-03-09 08:34:56 EST
I can reproduce this every time with the udisks test suite. I confirm that applying the patch fixes this bug, thanks!
Comment 12 Fedora Update System 2010-03-11 08:22:59 EST
e2fsprogs-1.41.10-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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