Description of problem: Upgrade of Fedora 10 fails when ntfs partitions are present in fstab Version-Release number of selected component (if applicable): Fedora 11 DVD installation disc for 32bit How reproducible: Choose upgrade procedure from the installer and then continue to receive an error that it cannot mount the ntfs partition and then the installer exits Steps to Reproduce: 1. Boot Fedora 11 DVD installation disc 2. Select upgrade of a Fedora 10 having at least one ntfs partition in fstab 3. Press continue Actual results: The installer exits with an error indication about failing to mount the ntfs filesystem Expected results: The installer should have continued to upgrade the previous release as all the other previous installers did of previous Fedora releases on the same machine. Additional info: There were also some vfat partitions, but I don't think that those could affect the installer, as there are supported by all kernels. A workaround is to comment the ntfs entries in fstab. Then the installer proceeds without a problem. I have to also note that the installer silently ignores to provide a mount point for the ntfs partitions, when you choose "Custom disk layout" and normal clean installation. This is not the case for vfat partitions where you can assign a mount point without a problem.
I've tested 64bit version of Fedora 11 installation DVD and it worked fine. It successfully upgraded a previous Fedora 10 x86_64 installation having ntfs partitions in fstab. After the installation, the partitions where still in fstab and were automatically mounted without problems.
It would be very useful if you could retry the 32-bit upgrade and, after the failure occurs, obtain /tmp/anaconda.log, /tmp/storage.log, and /tmp/syslog and attach them to this bug report. Thanks.
I tried to reproduce the problem by upgrading a Fedora 10 having ntfs partitions in fstab, using the 32bit version of DVD to no avail. Both 32bit and 64bit tests were conducted to another desktop PC. The original problem reported for a laptop. The installation on the same laptop produced another problem already reported to bug 506277 and it is again disk related. I strongly believe that the problem might be related to the hardware of the specific laptop, since I was unable to reproduce both reported problems on a different desktop machine. I'll try to re-install a Fedora 10 installation on this laptop and then try the upgrade procedure again to retrieve the requested logs. Because the laptop is old, the whole procedure is going to take a considerable amount of time. For now, I will include the original fstab of Fedora 10 of the laptop where the problem has been observed. I'll attach the requested logs later.
Created attachment 348383 [details] fstab prior to the upgrade This is the fstab my previous Fedora 10 had, before upgrading to Fedora 11.
Minimal installation worked and the repeat of the upgrade procedure reproduced the problem: Error message popup: Title: Unable to mount filesystem Body: An error occurred mounting device /dev/sda5 as /win/programs: mount failed: (2, None). This is a fatal error and the install cannot continue. Press <Enter> to exit the installer. And only OK button exists that exits the installer. This is an upgrade procedure blocker situation. The log files that resided in /tmp during the installation will be included.
Created attachment 348548 [details] Installer /tmp logs These are the contents of tar zcf /tmp/*
Created attachment 348550 [details] This is the 2nd attempt failing fstab where the logs have been retrieved Windows partition entries have been copied from the original fstab in order to reproduce the problem.
/dev/sda5 has the following mount options, taken from your /etc/fstab: rw,nodev,nosuid,exec,auto,nouser,sync,uid=500,gid=100,umask=022,dmask=022,codepage=737,iocharset=iso8859-7,check=r In the syslog I see the following error: <3>FAT: codepage cp737 not found The simple workaround is to comment out these lines, do the upgrade, then uncomment them. In the meantime, I am looking into the feasibility of including the nls kernel modules in the installer's runtime environment so the codepage lookup succeeds.
Thank you very much for your investigation! I think codepage and NLS mount options are very popular for displaying correctly non-Latin characters in file names of windows partitions. It would be great if they can be included on installer's kernel.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.