From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 Description of problem: It hangs while trying to load second stage loader. Version-Release number of selected component (if applicable): FC3 RC5 How reproducible: Sometimes Steps to Reproduce: 1. Install FC3 RC5 2. Instruct Installer to install grub in a boot record rather than MBR by selecting "advance boot loader configuration" option. 3. Complete the installation. Actual Results: Observe that the newly installed FC does not boot. Expected Results: System to boot after a successful installation. Additional info: This I have observed on FC3 RC5. I have seen this problem on 3 different computers (two P4 and one Athlon) across 2 different boot loaders (two through FC2 Grub and one through Windows 2000 boot loader). Two things that were common in all these configurations: 1. I instructed the installer to install the grub in a boot sector of a partition rather than MBR. 2. Upon booting through rescue mode (from Install CD4) and reinstalling grub (/sbin/grub-install <device_name>) solved the problem and made the system to boot fine. It is as if Installer forgot to run the above command in case of a non-MBR based installation. (Maybe this problem is present in MBR configuration too; however, I did not check it on an MBR configuration. Sorry.) Thank you.
Did you already have an active partition on the box? What does fdisk -l show?
Yes, there were active partitions in all those machines. (In both the P4 machines there were Windows 2000 active partitions, while on the Athlon an FC2.) Fdisk -l, I did not take that. Neither did I copy the entire /boot/grub directory structure nor did I compare that directory structure before and after fixing the problem manually. Sorry. (The first and second time I thought I was doing something stupid and wrong, but then when it repeated itself on the third computer I knew the installer was doing something wrong.) I will try to simulate and see if I can reproduce the problem. Thank you. (My bad I had to discover these problems in the final RCs :(; I should have done the testing during earlier test stages. But then I was busy at the Uni.)
If there's already an active partition set, then we leave it active. Otherwise, we break the use of third-party boot managers. Installing to the partition instead of the MBR is really only useful for cases where you have a third-party boot manager. In all other cases, you probably want to install to the MBR.
I am afraid I do not understand you completely. Are you saying that if you ask the installer to install the grub bootloader at the first sector of a partition (rather that at MBR) then it may not install grub there? (or only install it partially) This is my setup: 1. Windows on /dev/hda1 2. FC2's /boot on /dev/hda2 (and there are other partitions for FC2 for /, /usr, /tmp, /var etc..) 3. FC2's grub on MBR 4. Grub is the very first boot loader to be loaded by the BIOS (to load both FC2's kernel, to chain load Windows boot loader and to load any other boot loaders) 5. FC3 (RC5) is in /dev/hda12 (there is only one parition ie, /; everything else such as /boot, /usr, /tmp, /var etc. are just directories) 6. FC3 installer was instructed to install grub on /dev/hda12 (so that it could be chain loaded from FC2's grub (pls refer to point 3) 7. FC2's grub, when instructed to load FC3's grub, loaded the first stage, but while loading second stage completely hangs. Are you saying this is an unsupported arragement? Thank you. Hari. PS: I appreciate your help. And I am unable to reproduce this problem on my laptop, but I shall try and reproduce this problem on other machines today.
(I have used the vanilla FC3 x86_64 DVD installation media.) I have reproduced this bug on my AMD64. In this computer FC2's grub on MBR (/dev/hda) is the primary boot loader for the entire system. I selected "Advanced boot loader" option during installation, and chose to install the boot loader on the first sector of one and only partition (root) of the FC3 (/dev/hda17). Then I added the following section in my primary grub: title FC3 rootnoverify hd(0,16) chainloader +1 When I select that it just hangs. (Though ctrl+alt+del works fine.) I have not tried to fix anything up this time around, although I know I can fix this by using the Rescue mode and using /sbin/grub-install. Upon request I can provide files/directories etc.. (It is as if Anaconda installer 'forgot' to install the boot loader.) Thank you Hari
I think I understand the problem: I observe that the FC3 - Anaconda - Disk Druid created partitions are not visible when I use "fdisk -l /dev/hda". But OTOH they are there and accounted for when I use "parted /dev/hda print". (I tried this upon completion of the installation and just before rebooting.) What are the odds Anaconda (grub installation procedure) was upset about that? (Even after a reboot it is still the case, ie, parted shows the Disk Druid created partitions while fdisk does not.) Thank you. Hari.
And Oh BTW, kernel accounts for those 'hidden' (partially :) partitions: hda: max request size: 1024KiB hda: Host Protected Area detected. current capacity is 234435439 sectors (120030 MB) native capacity is 234441648 sectors (120034 MB) hda: 234435439 sectors (120030 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 hda14 hda15 hda16 hda17 hda18 > And so does /proc/partitions file. Yes; hda17 and hda18 are the two FC3 installation created partitions. And both are the one and only partitions for two FC3 installations obviously. Yes; I have installed FC3 multiple times on this computer :). Interestingly when I installed the second FC3 (on /dev/hda18), the previously installed FC's partition (/dev/hda17) was visible in the Disk Druid screen. IOW, Anaconda does the right thing while "reading" the partitions, but not while "writing". Maybe it uses two kinds of procedures/tools: one for partition "reading", which obviously does the right thing, but not the partition "writing", which might be at fault. Just a guess. Summary: fdisk does not display Anaconda - Disk Druid created partitions (/dev/hda17 and hda18) in my case (before and after the reboot); OTOH, parted, kernel and /proc/partitions are just fine with those partitions. And that just might be the root cause of my problem. Thank you. Hari.
fdisk won't display any partitions over /dev/hdaX16. As for your original question, we install GRUB, but changing the active partition is usually the exact opposite of what the user expects. If they expected GRUB to be activated by default, then you install to the MBR.