Bug 430836

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