Bug 569021 - mke2fs insists on user interaction even if stdin is not a tty and -F is passed
Summary: mke2fs insists on user interaction even if stdin is not a tty and -F is passed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F13Blocker, F13FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2010-02-27 16:52 UTC by David Zeuthen
Modified: 2013-03-06 04:01 UTC (History)
7 users (show)

Fixed In Version: e2fsprogs-1.41.10-5.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-11 13:23:05 UTC


Attachments (Terms of Use)

Description David Zeuthen 2010-02-27 16:52:18 UTC
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 16:54:14 UTC
(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 16:55:02 UTC
Also, passing -F twice doesn't help either.

Comment 3 Eric Sandeen 2010-03-01 18:56:32 UTC
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 19:06:08 UTC
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 19:08:07 UTC
(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 20:01:42 UTC
Sent a patch upstream:

http://marc.info/?l=linux-ext4&m=126747319409267&w=2

Comment 7 Eric Sandeen 2010-03-01 20:31:01 UTC
Committed and built in e2fsprogs-1_41_10-5_fc13

-Eric

Comment 8 Fedora Update System 2010-03-01 20:38:57 UTC
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 18:47:20 UTC
(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-03 01:47:58 UTC
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 13:34:56 UTC
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 13:22:59 UTC
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.