Bug 563218
| Summary: | anaconda failure with 4K logical sector disk | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Domsch <matt_domsch> | ||||
| Component: | anaconda | Assignee: | Hans de Goede <hdegoede> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 14 | CC: | jbrier, jonathan, jordan_hargrave, linux-bugs, meyering, stuart_hayes, vanmeeuwen+fedora | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | 553518 | ||||||
| : | 573628 (view as bug list) | Environment: | |||||
| Last Closed: | 2012-08-16 21:54:36 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 553518 | ||||||
| Bug Blocks: | 507684 | ||||||
| Attachments: |
|
||||||
|
Description
Matt Domsch
2010-02-09 15:48:35 UTC
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.
Steve
Hi Steve, 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: import parted dev = parted.Device(path="/dev/sda") disk = parted.freshDisk(device=dev, ty="msdos") print disk disk.commitToDevice() disk.commitToOS() exit() ### I think the last commit call will fail. If that is the case there are 2 possible causes: 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 fdisk /dev/sda w And see if fdisk is capable of writing an empty label ? p.s. 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? Thanks! 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |