Bug 430836 - exit and immediate reboot on saving changes to disk
exit and immediate reboot on saving changes to disk
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-01-29 20:22 EST by Felix Miata
Modified: 2009-11-25 19:52 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 13:54:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (17.23 KB, text/plain)
2008-01-29 20:22 EST, Felix Miata
no flags Details

  None (edit)
Description Felix Miata 2008-01-29 20:22:56 EST
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 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
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)
Comment 1 Felix Miata 2008-01-29 20:22:56 EST
Created attachment 293358 [details]
Comment 2 Jeremy Katz 2008-01-30 12:07:05 EST
What are the last messages on tty1 when it exits?
Comment 3 Felix Miata 2008-01-30 20:13:15 EST
Running anaconda, 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
unmounting filesystems
/mnt/runtime done
disabling /dev/loop0
/proc done
/sys done
/selinux done
Rebooting system
Comment 4 Felix Miata 2008-03-18 21:35:23 EDT
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.
Comment 5 Bug Zapper 2008-05-14 00:55:40 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 6 Boris Savelev 2008-05-15 11:12:58 EDT
I have the same problem.
Is exist temporary solution?

ps: sorry for my english
Comment 7 Felix Miata 2008-05-15 17:49:47 EDT
(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.
Comment 8 Boris Savelev 2008-05-19 11:20:49 EDT
> 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- ro root=LABEL=/1234
initrd /boot/initrd-

/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
Comment 9 Felix Miata 2008-05-19 12:22:09 EDT
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.
Comment 10 Greg Morgan 2008-05-25 18:47:37 EDT
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
"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?
Comment 11 Felix Miata 2008-05-25 19:42:38 EDT
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.
Comment 12 Ray Todd Stevens 2008-06-01 14:13:14 EDT
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.

Comment 13 Andy Lindeberg 2008-06-03 09:56:54 EDT
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?
Comment 14 Ray Todd Stevens 2008-06-03 10:07:37 EDT
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.
Comment 15 Felix Miata 2008-06-03 15:10:34 EDT
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.
Comment 16 Ray Todd Stevens 2008-06-18 11:29:30 EDT
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.
Comment 17 Ray Todd Stevens 2008-07-01 14:45:30 EDT
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.
Comment 18 David Cantrell 2008-08-05 16:54:00 EDT
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.
Comment 19 Ray Todd Stevens 2008-08-05 17:13:52 EDT
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.
Comment 20 David Cantrell 2008-08-05 17:22:23 EDT
(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.

Comment 21 Felix Miata 2008-08-05 19:01:12 EDT
(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.
Comment 22 Felix Miata 2008-08-05 19:09:55 EDT
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.
Comment 23 David Cantrell 2008-08-05 19:25:56 EDT

Do any messages appear on tty4 when the crash happens?  In particular, any kernel oopses?
Comment 24 Ray Todd Stevens 2008-08-05 19:34:00 EDT
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.
Comment 25 Felix Miata 2008-08-06 13:25:17 EDT
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 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
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 134, in doConfigSetup
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__
File "/usr/lib/anaconda/yuminstall.py", line 1095 in doInitialSetup
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
File "/usr/lib/anaconda/dispatch.py", line 129, in gotoNext
File "/usr/lib/anaconda/gui.py", line 1323, in nextClicked
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)
Comment 26 Ray Todd Stevens 2008-08-06 14:29:37 EDT
I have started a new bug report for those of us experiencing errors without large numbers of partitions.

bug 458152
Comment 27 Bug Zapper 2009-06-09 19:27:20 EDT
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: 
Comment 28 Bug Zapper 2009-07-14 13:54:00 EDT
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.
Comment 29 Felix Miata 2009-11-25 19:52:53 EST
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

Note You need to log in before you can comment on or make changes to this bug.