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.
(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.
Also, passing -F twice doesn't help either.
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.
I'l just stick an "if (!force)" around the y/n prompt, as is done in other locations. Sorry about that! -Eric
(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
Sent a patch upstream: http://marc.info/?l=linux-ext4&m=126747319409267&w=2
Committed and built in e2fsprogs-1_41_10-5_fc13 -Eric
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
(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...
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
I can reproduce this every time with the udisks test suite. I confirm that applying the patch fixes this bug, thanks!
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.