Description of problem: Installation abruptly exits when partition mount point selection is finished and the PATA HD has partitions >15. Version-Release number of selected component (if applicable): Anaconda 11.4.0.27 and prior How reproducible: Going back to F8, I've tried about 20 times on 6 different systems over the past several weeks. My only direct success was on the only system that had fewer than 15 partitions on any HD. Indirect successes came from installing earlier versions first, then doing Yum upgrades. Steps to Reproduce: 1.fully partition and mkfs primary master target HD according to needs 2.install various other operating systems, such as DOS, OS/2, WinXP, SUSE Factory and/or Mandriva Cooker 3.start Rawhide HTTP installation from public mirror 4.continue when Anaconda complains about >15 partitions 5."create custom layout" (only choice for using selected existing partitions) 6.select edit on various partitions up through #15 per HD, specifying nothing except mount points, and nothing to be formatted 7.select "next" 8.select "write changes to disk" (when the only other option is "go back") Actual results: 1-Anaconda immediately exits 2-system reboots without prompting or opportunity to save logs Expected results: 1-Anaconda either provides error message, or proceeds to package selection Additional info: A-partitions selected for mounting: 5-83 /disks/hda/boot 204M 8-82 swap 1G 9-83 /disks/hda/cooker 4.8G 10-83 /disks/hda/factory 4.8G 11-83 / 4.8G 12-83 /home 1.6G 13-83 /pub 7G 14-83 /srv 235M 15-83 /usr/local 1.1G partitions not selected for mounting 1-17 "hidden" HPFS 2-0A IBM BM 3-06 FAT16 6-0B FAT32 7-06 FAT16 16-83 EXT3 17-83 EXT3 18-83 EXT3 19-83 EXT3 20-07 HPFS B-Dell GX260 (P4 2GHz on i845G); 1G RAM; e100 NIC; empty ZIP250 on primary slave; empty CD on secondary master; nothing on USB; empty fd0 C-other systems attempted used: Sempron/NForce2 (total failure); Celeron/i845G (total failure); PIII/i815 (failure even though target #2 HD has only 11 partitions); AthlonXP/KT266A (success due to only 11 partitions)
Created attachment 293358 [details] anaconda.log
What are the last messages on tty1 when it exits?
Running anaconda 11.4.0.27, the Fedora system installer - please wait... Probing for video card: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device Attempting to start native X server Waiting for X server to start...log located in /tmp/X.log 1...2...3...4...5... X server started successfully. 19:29:01 Starting graphical installation... the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None the target size for None is None sending termination signals...done sending kill signals...done disabling swap /dev/sda8 unmounting filesystems /mnt/runtime done disabling /dev/loop0 /proc done /sys done /selinux done Rebooting system
Problem continues with 18 March vmlinuz and initrd.img from development/i386/os/isolinux. Sure is hard to test test when you can't get an installation started.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have the same problem. Is exist temporary solution? ps: sorry for my english
(In reply to comment #6) > I have the same problem. > Is exist temporary solution? Two possibilities I know of: 1-Install F6, then upgrade with Yum 2-Use a partitioning program capable of non-destructive deletes to "delete" partitions >15, install F9, then recreate the "deleted" partitions >15. The tool I use for the purpose is non-free DFSee.
> 1-Install F6, then upgrade with Yum I'm install FC6 to /dev/hda20 and upgrade without problem. But I can't boot with new kernel. initrd can't mount root. I boot with: root (hd0,19) kernel /boot/vmlinuz-2.6.25.3-18.fc9.i586 ro root=LABEL=/1234 initrd /boot/initrd-2.6.25.3-18.fc9.i586.img /dev/hda20 have "/1234" label hda20 Logical Linux ext3 [/1234] 6292,34 using /dev/sda20 or /dev/hda20 as root in boot menu don't resolve problem
Boris, anything to do with upgrading with Yum is off-topic for this bug. This bug is exclusively about the Anaconda installer crashing if it finds partitions above 15. If you actually want to install to a partition above 15, your best bet is probably to install SUSE or Mandriva instead of Fedora. Both Mandriva and SUSE offer the option to use legacy IDE drivers instead of libata drivers. If you really need to run Fedora 9 from hda20, maybe you can use another machine to compile a fedora kernel that includes legacy IDE drivers.
I recall trying to create 15+ partitions for an Oracle database server. I found out back in, say, 2000, that this limitation was not a Linux limitation but a DOS limitation. So I wonder if this is really a bug. I am sure the reporter would like to use his "physical" partition scheme. However, based on this link http://publib.boulder.ibm.com/infocenter/systems/topic/com.ibm.aix.baseadmn/doc/baseadmndita/physpartlimit.htm "The design of LVM limits the number of physical partitions that LVM can track per disk to 1016." Wouldn't converting to LVM solve this problem. As per comment #9, it looks like the reporter is using a tool to work around the 15 physical partition limit. Is this even possible?
There is no physical partition limit. The only limits are imposed by tools and operating systems that use partitioned devices. Libata imposes a low and anachronistic limit inherited from SCSI. For those of us multi-booters and others who predate LVM, LVM is simply not an option in many cases, particularly with regard to systems being updated from pre-libata versions of Fedora installed on systems that had no such limitation but did have >15 partitions. The system from which I write this comment has 2 ATA disks totalling 320G with a combined total of 67 partitions and 125G of unpartitioned space. The machine sitting next to it, used as a file & web server, and beta test software platform, has a single 250G ATA disk with 23 partitions and 110G in unpartitioned space. I have another 20+ working systems, none of which possess ATA disks of 40G or more that have fewer than 16 partitions. I have LVM partitions on exactly one system. The only reason I have any LVM partitions was that I cobbled together a system out of spare parts for the two purposes of investigating suitability of LVM, proving it actually possible to install Rawhide and/or Fedora 9 under the roof of this building. There is no possibility of "converting" to LVM by people whose backup and configuration systems depend on cross-platform tools that backup and restore partitions rather than files, and do not depend on any partiticular OS being booted to use those tools. Access to LVM requires booting an OS that understands LVM. DOS, OS/2 & Windows don't understand Linux LVM. Nothing but OS/2 understands OS/2 LVM. To restore from backup in these cases presupposes the possibitility to recreate circumstances similar to or exactly the same as those from which they were made. This is incompatible with converting to LVM. Unlike Fedora, SUSE & Mandriva continue to include the option to use legacy IDE drivers. AFAIK, they will continue to include them pending suitability of a libata rewrite that does not depend on the legacy SCSI partition count limitation, or a user-comprehensible system of using kpartx and device mapper to maintain access to to all partitions legal under legacy installations. The least Fedora should do is not crash just because partitions lacking device assignments are found by Anaconda. That's what this bug is about, not whether LVM is or is not better, or X number of partitions under some non-Linux OS is or is not possible.
I don't know if this is related, but I am experiencing spontanious reboots during the install for fc9 fc9a1 hangs at the part about seeing if it is initrd. fc9 prod just spontaniously reboots at that same place. This is true of both using a boot cd and using the preupgrade install package. This is well before trying to do any real installation, but I have tried a rescue reboot with the same result. The machine will boot to fc8 and will take an fc8 boot disk just fine.
Can you give any information about your system or installer configuration that I can use to test this? Since it's happening with more than one disc, I'm assuming it's probably not a media problem, but have you verified the media just to be sure?
I am not sure exactly what you would need to know about the machine. It presently is running fc8 fine. If there is some inventory program that I could run under fc8 that might help this would be cool. I have verified the media. I was able to run the memory test. Also the original attempt to upgrade was done using the preupgrade program, which actually does even use a cd.
AFAICT from my attempts on multiple systems, nothing special is required other than the presence prior to booting a Fedora installation kernel of more legacy partitions per HD than libata drivers can find sd* device names to assign to. This has happened on too many systems for any possibility for media to be other than an orthagonal problem. Besides, I mkfs.ext3 (normally with -b1024 because they are smallish, usually under 5G) and apply labels with tune2fs and mkswap to target partitions prior to booting any Fedora installation kernel. As additional confirmation that media is not a problem, I did precisely as I described in option 2 in comment 7. Following that procedure I have F9 running on a partition accessed as /dev/hda11 when that (comment 0) system is booted to an OpenSUSE Factory 11.0rc1 installation on /dev/hda10 on a PATA disk whose last mounted logical partition is /dev/hda23. In all my cases, because all partitions and filesystems are created in advance, there shouldn't be anything for the installation system to write to any partition tables. My installations normally get started by Grub loading previously downloaded installation kernels and initrds and using HTTP for installation media. IIRC, I did try using a boot.iso CD instead just to see if anything different happened. This happened identically with AMD, Intel and VIA PATA controllers providing the access to the installation target devices.
I see where this one went to "assigned" If you need more information let me know. Right now the machine that this is a problem for is a production machine, and so doing things with it during the day is a problem. But give me a couple of evenings and I can run about any tests you need run.
I will be moving the machine that is the primary example of this problem Thursday night. If there any tests we need done, this would be a great time for it.
There's not much we can do for this situation in Fedora. The kernel uses libata, we are bound by those limits. There are certain cases where we can detect more than 15 partitions and warn the user, but if you are trying to use partitions beyond the 15th, it'll just fail.
That does not appear to be my problem. I have never had that many partitions. What do we need to do to define the problem other than with over 15 partitions.
(In reply to comment #19) > That does not appear to be my problem. I have never had that many partitions. > What do we need to do to define the problem other than with over 15 > partitions. Please open a new bug for a new problem. It helps us keep track of bugs. When one bug suddenly starts to contain a trail of problems, it's hard to remember what the issue is. So, one bug per problem, please. Thanks.
(In reply to comment #18) > There's not much we can do for this situation in Fedora. The kernel uses > libata, we are bound by those limits. There are certain cases where we can > detect more than 15 partitions and warn the user, but if you are trying to use > partitions beyond the 15th, it'll just fail. It shouldn't matter how many partitions are on the device. Anaconda should just recognize whatever it is capable of recognizing based on whatever limitations its kernel has, then proceed on that basis. Partitions owned and usable by more competent operating systems installed on a multiboot system are no excuse for an installer crash. It can be fixed, because crashing on finding more than it can support does not happen with other distros' installation kernels that use libata. F9 works just fine on a system with more than 15 partitions if you simply clone it from outside a Fedora boot to a partition @ 15 or lower, or create more than 15 partitions after installing F9. Thus, can't fix is a pure unadulterated limitation of Anaconda, not any limitation of the Fedora kernel.
I'm not a developer, but I do know much about partitioning and multiboot. What I suspect is happening is that Anaconda thinks it needs to write changes to partition tables, then verify the partitioning by reading what it is incapable of reading. In the case where the partitions already exist, and no partitioning is needed, there is nothing Anaconda should be writing to any partition table. There could be, like in Mandriva, an installation kernel option that forces readonly on the partition tables, thus allowing any crash resulting from attempted writes or verifications to be avoided.
Felix, Do any messages appear on tty4 when the crash happens? In particular, any kernel oopses?
How about we meet in the middle on this one. Make this a RFE: Maybe the comment about the partition table is on target. But one really important question, why does the fedora install INSIST that it HAS to create a new partition structure. Anaconda should have an option to use an existing partition table and just assign a purpose to each partition. That is one of the options should be to use whatever partition editor you want to, and setup partitions with the proper partition types, and then one of the options when running the installer is to chose from these partitions for the root and automatically just find the partition marked as swap. This would help with so many problems. I have regularly had to do work arounds where the installer insisted upon setting up a partition structure that would not work for what I was doing. I would have to do weird things to the partition table pre install to force the system to do what I needed it to do. Then undo these and go on with the system setup. Instead of trying to make anaconda do everything which seems to be a legitimate common complaint of the developers, just have it have the hooks to let others setup what they need to and use the setup designed.
Scott, your comments are all off-topic for this bug about crashing when there are more than 15 partitions. David, the behavior seems changed, and the new error possibly unrelated. I get one more screen before Anaconda stops. Now after unhandled exception notification comes from Anaconda after "writing changes to disk" succeeds, the bootloader selection screen fails (custom partitioning, specifying no more than sda11 to mount as /), and tty4 tail shows: <6>Adding 1052216k swap on /dev/sda8. Priority:-1 extents:1 across:1052216k <6>kjournald starting. Commit interval 5 seconds <6>EXT3 FS on sda11, internal journal <6>EXT3-fs: mounted filesystem with ordered data mode. <7>SELinux: initialized (dev sda11, type ext3), uses xattr <6>SELinux: Context unconfigned_u:object_r:rpm_var_lib_t:s0 is not valid (left unmapped). tty3 tail shows: 12:34:56 INFO : moving (1) to step reposetup 12:34:57 CRITICAL: anaconda 11.4.1.24 exception report Traceback (most recent call first): File "/usr/lib/python2.5/site-packages/yum/config.py", line 802, in _getsysver idx = ts.dfMatch('provides', distroverpkg) File "/usr/lib/python2.5/site-packages/yum/config.py", line 732, in readMainConfig yumvars['releasever']=_getsysver(startupconf.installroot, startupconf.distroverpkg) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 182 in _getConfig self._conf=conf.readMainConfig(startupconf) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 134, in doConfigSetup errorlevel=errorlevel) File "/usr/lib/anaconda/yuminstall.py", line 711, in doConfigSetup YumSorter.doConfigSetup(self, fn=fn, root=root) File "/usr/lib/anaconda/yuminstall.py", line 386, in __init__ self.doConfigSetup(root=anaconda.rootPath) File "/usr/lib/anaconda/yuminstall.py", line 1095 in doInitialSetup self.ayum=AnacondaYum(anaconda) File "/usr/lib/anaconda/backend.py", line 193, in doRepoSetup if anaconda.backend.doInitialSetup(anaconda)==DISPATCH_BACK: File "/usr/lib/anaconda/dispatch.py", line 206, in moveStep rc=stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 129, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1323, in nextClicked self.anaconda.dispatch.gotoNext() TypeError: rpmdb open failed 12:34:57 WARNING: /usr/lib/anaconda/gui.py:1028: GtkWarning: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed textbuf.insert(iter, line)
I have started a new bug report for those of us experiencing errors without large numbers of partitions. bug 458152
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.
FWIW in F12 installation with a partition # 26 target / I'm not able to even reach the step where partitioning should be saved. See https://bugzilla.redhat.com/show_bug.cgi?id=520058#c9