New bug to track the anaconda failure.
+++ This bug was initially created as a clone of Bug #553518 +++
Description of problem:
GNU Parted 1.9 and earlier cannot handle disks with a 4K sector size. Such disks are starting to become available on the open market now, and will be commonplace within the lifetime of Fedora 13.
Please update parted to version 2.1 or thereabouts (certainly >= 2.0) to add proper support for such disks.
--- Additional comment from firstname.lastname@example.org on 2010-01-07 23:38:55 EST ---
FYI, parted 1.9 doesn't like 4K sector disk at all. :-)
$ rpm -q parted
# /sbin/parted /dev/sdb print
Warning: Device /dev/sdb has a logical sector size of 4096. Not all parts of GNU Parted support this at the moment, and the working code is HIGHLY
*** stack smashing detected ***: <unknown> terminated
======= Backtrace: =========
======= Memory map: ========
00400000-00412000 r-xp 00000000 fd:00 30384 /sbin/parted.old
00612000-00613000 rw-p 00012000 fd:00 30384 /sbin/parted.old
00613000-00614000 rw-p 00000000 00:00 0
0158c000-015ce000 rw-p 00000000 00:00 0 [heap]
328b000000-328b03a000 r-xp 00000000 fd:00 82206 /lib64/libreadline.so.6.0
328b03a000-328b23a000 ---p 0003a000 fd:00 82206 /lib64/libreadline.so.6.0
328b23a000-328b242000 rw-p 0003a000 fd:00 82206 /lib64/libreadline.so.6.0
328b242000-328b243000 rw-p 00000000 00:00 0
3293800000-3293816000 r-xp 00000000 fd:00 67316 /lib64/libgcc_s-4.4.2-20091222.so.1
3293816000-3293a15000 ---p 00016000 fd:00 67316 /lib64/libgcc_s-4.4.2-20091222.so.1
3293a15000-3293a16000 rw-p 00015000 fd:00 67316 /lib64/libgcc_s-4.4.2-20091222.so.1
3297c00000-3297c1d000 r-xp 00000000 fd:00 82205 /lib64/libtinfo.so.5.7
3297c1d000-3297e1d000 ---p 0001d000 fd:00 82205 /lib64/libtinfo.so.5.7
3297e1d000-3297e21000 rw-p 0001d000 fd:00 82205 /lib64/libtinfo.so.5.7
329b000000-329b00e000 r-xp 00000000 fd:00 15899 /lib64/libudev.so.0.4.2
329b00e000-329b20d000 ---p 0000e000 fd:00 15899 /lib64/libudev.so.0.4.2
329b20d000-329b20e000 rw-p 0000d000 fd:00 15899 /lib64/libudev.so.0.4.2
7f328f7ec000-7f329561d000 r--p 00000000 fd:00 72870 /usr/lib/locale/locale-archive
7f329561d000-7f3295639000 r-xp 00000000 fd:00 4732 /lib64/libblkid.so.1.1.0
7f3295639000-7f3295839000 ---p 0001c000 fd:00 4732 /lib64/libblkid.so.1.1.0
7f3295839000-7f329583c000 rw-p 0001c000 fd:00 4732 /lib64/libblkid.so.1.1.0
7f329583c000-7f3295878000 r-xp 00000000 fd:00 82924 /lib64/libsepol.so.1
7f3295878000-7f3295a77000 ---p 0003c000 fd:00 82924 /lib64/libsepol.so.1
7f3295a77000-7f3295a78000 rw-p 0003b000 fd:00 82924 /lib64/libsepol.so.1
7f3295a78000-7f3295a94000 r-xp 00000000 fd:00 4006 /lib64/libselinux.so.1
7f3295a94000-7f3295c93000 ---p 0001c000 fd:00 4006 /lib64/libselinux.so.1
7f3295c93000-7f3295c94000 r--p 0001b000 fd:00 4006 /lib64/libselinux.so.1
7f3295c94000-7f3295c95000 rw-p 0001c000 fd:00 4006 /lib64/libselinux.so.1
7f3295c95000-7f3295c96000 rw-p 00000000 00:00 0
7f3295c96000-7f3295cb5000 r-xp 00000000 fd:00 16742 /lib64/libdevmapper.so.1.02
7f3295cb5000-7f3295eb5000 ---p 0001f000 fd:00 16742 /lib64/libdevmapper.so.1.02
7f3295eb5000-7f3295eb7000 rw-p 0001f000 fd:00 16742 /lib64/libdevmapper.so.1.02
7f3295eb7000-7f3295eb9000 r-xp 00000000 fd:00 3459 /lib64/libdl-2.11.90.so
7f3295eb9000-7f32960b9000 ---p 00002000 fd:00 3459 /lib64/libdl-2.11.90.so
7f32960b9000-7f32960ba000 r--p 00002000 fd:00 3459 /lib64/libdl-2.11.90.so
7f32960ba000-7f32960bb000 rw-p 00003000 fd:00 3459 /lib64/libdl-2.11.90.so
7f32960bb000-7f32960bf000 r-xp 00000000 fd:00 4167 /lib64/libuuid.so.1.3.0
7f32960bf000-7f32962be000 ---p 00004000 fd:00 4167 /lib64/libuuid.so.1.3.0
7f32962be000-7f32962bf000 rw-p 00003000 fd:00 4167 /lib64/libuuid.so.1.3.0
7f32962bf000-7f3296437000 r-xp 00000000 fd:00 3453 /lib64/libc-2.11.90.so
7f3296437000-7f3296637000 ---p 00178000 fd:00 3453 /lib64/libc-2.11.90.so
7f3296637000-7f329663b000 r--p 00178000 fd:00 3453 /lib64/libc-2.11.90.so
7f329663b000-7f329663c000 rw-p 0017c000 fd:00 3453 /lib64/libc-2.11.90.so
7f329663c000-7f3296641000 rw-p 00000000 00:00 0
7f3296641000-7f32966b9000 r-xp 00000000 fd:00 5666 /lib64/libparted-1.9.so.0.0.0
7f32966b9000-7f32968b9000 ---p 00078000 fd:00 5666 /lib64/libparted-1.9.so.0.0.0
7f32968b9000-7f32968bd000 rw-p 00078000 fd:00 5666 /lib64/libparted-1.9.so.0.0.0
7f32968bd000-7f32968be000 rw-p 00000000 00:00 0
7f32968be000-7f32968de000 r-xp 00000000 fd:00 3443 /lib64/ld-2.11.90.so
7f3296ac5000-7f3296acc000 rw-p 00000000 00:00 0
7f3296ad4000-7f3296ad5000 rw-p 00000000 00:00 0
7f3296ad5000-7f3296adc000 r--s 00000000 fd:00 5416 /usr/lib64/gconv/gconv-modules.cache
7f3296adc000-7f3296add000 rw-p 00000000 00:00 0
7f3296add000-7f3296ade000 r--p 0001f000 fd:00 3443 /lib64/ld-2.11.90.so
7f3296ade000-7f3296adf000 rw-p 00020000 fd:00 3443 /lib64/ld-2.11.90.so
7f3296adf000-7f3296ae0000 rw-p 00000000 00:00 0
7fff4d0a8000-7fff4d0bd000 rw-p 00000000 00:00 0 [stack]
7fff4d134000-7fff4d135000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
--- Additional comment from email@example.com on 2010-01-08 02:47:09 EST ---
We were hoping we would get away for now with just properly supporting
physical 4k sectors (for which we have backported patches to parted-1.9.x).
I've discussed this with parted upstream and they are not sure yet parted-2.x is ready for prime time use.
"Such disks are starting to become available on the open market now" are you sure about this ? AFAIK 4k physical sector disks will be, but not logical sector
ones (physcical = on platter, logical = over the wire / as seen by the OS).
Is the /dev/sdb in question a real disk or was it created with the scsi_debug module ?
--- Additional comment from firstname.lastname@example.org on 2010-01-08 04:21:57 EST ---
I too would like to see parted-2.x in F13. The sooner we work out any bugs the better.
--- Additional comment from email@example.com on 2010-01-08 10:59:06 EST ---
Correct that 4K physical, 512 logical are available on the market now. 4k physical / 4k logical are available in sample units (yes, my /dev/sdb is one such sample) now, with widespread availablity targeting 2012, possibly sooner. Certainly within the lifetime of RHEL6, and possibly within the lifetime of F13.
I also note that kernel 2.6.33-rc1 or later is needed to pick up GPT parsing fixes for 4k logical sector disks.
--- Additional comment from firstname.lastname@example.org on 2010-01-11 14:25:41 EST ---
parted-2.1 is on its way to rawhide, so I'm closing this.
Here is an updates.img which can be used together with the *i386* Fedora-12
anaconda, can you try installing Fedora-12 on that 4k logical sector disk by
using F-12 + this updates.img ?
--- Additional comment from email@example.com on 2010-01-11 15:21:19 EST ---
unfortunately, something segfaulted shortly after choosing to initialize the 4K sector disk but before any partitioning choice screens, and the backtrace from libc scrolled long past what the screen buffer with alt-pgup could catch. :-(
--- Additional comment from firstname.lastname@example.org on 2010-01-12 03:34:07 EST ---
(In reply to comment #6)
> unfortunately, something segfaulted shortly after choosing to initialize the 4K
> sector disk but before any partitioning choice screens, and the backtrace from
> libc scrolled long past what the screen buffer with alt-pgup could catch. :-(
Can you try installing F-12 with the disk not connected, then add it, and
(ignore the broken deps for DeviceKit-Disks on parted, I did and things are still
fine for me).
And then doing some tests with parted on the drive in question ? And see
if you can get it to crash ?
--- Additional comment from email@example.com on 2010-02-09 10:47:13 EST ---
Stuart, Jordan: can you work with Hans to test and debug these anaconda/libparted failures with the 4k disk?
I installed F12 and then installed the packages under the two links in the comment dated 2010-1-12 03:34:07 EST, and I haven't been able to get it to fail. I created an MBR label and made some partitions, made filesystems on them, created files, copied files back and forth between the partitons, and then repeated the exercise with a GPT label. It all worked fine here.
Created attachment 399402 [details]
Debug dump from FC13 Alpha failed install
I have tried FC13 Alpha with a WD10-EARS Advanced Format (4K sector) drive and the default installation (anaconda) fails with an exception when creating the file systems on a blank disk.
The attached debug dump shows that Anaconda is creating the first partition on sector 63 which will be misaligned on a 4K sector drive. There seems to be some attempt to move the start of the partition from sector 63 to 2048 but verifying with fdisk for example shows that /dev/sda1 starts on sector 63.
I suspect that the issue may be at the mkfs stage where mke2fs 1.41.10 will notice the poorly aligned data and issue a yes/no question whichh the installation scripts can't cope with. I believe that mke2fs 1.41.11 will add a -F option to override the question but the real answer is to correctly align the partitions so that the drives performa at their best performance.
Please let me know if you need any more details.
Thanks for testing this!
Looking at the debuglog we never get around to creating the ext2 fs. We start
by writing an empty label to the disk and that is where we fail.
Could you please do the following:
1) start F-13 alpha installer
2) Switch to tty2 (ctrl + alt + F2)
3) Run python, and then at the python prompt type:
dev = parted.Device(path="/dev/sda")
disk = parted.freshDisk(device=dev, ty="msdos")
I think the last commit call will fail. If that is the case there are 2 possible
1) The kernel does not grok partition tables on 4k disks
2) The device is somehow busy
Either way, please copy and paste the output of the above commands here.
Also it would be great if you could also do:
dd if=/dev/zero of=/dev/sda bs=512 count=1
And see if fdisk is capable of writing an empty label ?
Could you do:
dd if=/dev/sda of=mbr.bin bs=512 count=1 after running the parted code,
and attach mbr.bin here ?
And then after the dd to fill with 0, fdisk, w attempt do:
dd if=/dev/sda of=mbr.bin bs=512 count=1 after running the parted code,
and attach this second mbr.bin here too?
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.
More information and reason for this action is here:
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: