I just installed fc11 beta and everything worked great. Then I did a "yum update". The system was working OK afterwards, but as soon as I did a reboot the system went into a mode where as soon as it tried to load grub the system would reboot. grub-install /dev/sda fixed the problem. I am running a /dev/md0 partition as my /
I actually do find that this has been an issue with several updates. I am not sure why, but it has been. It seems to relate to the configuration of a md drive (which is a raid 1) as the root, and then a separate boot drive. For a long time this was what you had to do to use a md drive as the root.
Comment from Bug Zapper ====================== Thank you for taking the time to report this bug. Unfortunately, we do not understand the problem you are having. If you have time and can still reproduce the bug, please read http://fedoraproject.org/wiki/BugsAndFeatureRequests and add a description along those lines to this bug report so we can diagnose the problem. In particular we are interested to know, the components that "yum update" had installed, so that we could get to isolate the issue further. Also if you could gather some log messages of the installed components, and attach it as a seperate file it would aid the developer. Please also mention the kernel version that you are using. Thank you. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Well this is a bit hard to define, but I will try. I am pretty sure that the problem was the installation of a new kernel package. I have seen this problem a whole bunch of times like maybe 10. Each time a new kernel was installed, and one time only a new kernel (and related packages) was installed. You will have to research the original kernel, as I know I don't have that information. Basically it was what every installs as a part of fc11 beta off the network install iso. I am including my upgrade log and yum log. The apr 2 update was the one that triggered the problem.
Created attachment 338628 [details] my yum log
Created attachment 338629 [details] my upgrade log
By the way the last time I really looked at this the problem appeared to be that the boot loader was loaded with really dumb information. I can remember once when the grub list was empty. That is the menu contained absolutely no entries. Or at least in my very amateur investigation with limited tools that was what it looked like. Another time there were several entries, but none of them appeared to be complete.
Comment from Bug Zapper ====================== Thank you for taking the time to report this bug. But from the information, you just provided., we still cannot isolate the issue. Without isolating the issue., we cannot assign to a particular developer, as different people would have developed various components. Some suggestions from my side. Could you please try to install a debug version of your current kernel(you can find it in yum, by searching for debug kernel, and then selecting your current kernel version but with 'debug' as suffix. Installing this debug version of the kernel, would provide more valuable information(if you suspect it to be a kernel issue) Alternatively, as a first level of debugging, please enable dmesg, and see if you could get any related information from it. Meanwhile, i shall send these logs, and follow up on this bug with the test team and if required the development team(you could also do that by subscribing to the respective mailing lists). Until we have sufficient information, i need to set the "NEED INFO" flag "ON", so that we could continue follow up with this issue. Setting "NEED INFO" flag ON. Thank you -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think a point is being missed here. The problem doesn't seem to be in the kernel, but in the boot loader configuration that seems to be loaded as a part of the kernel update. The system never gets to the point of starting to load the kernel.
There have been a few fixes recently for boot-on-raid. Can you try with a newer snapshot?
I am not sure how to get a newer snapshot????? As a matter of suggestion, how about a faq specifically for how to get testing updates and the like when they are referenced by you redhat types on the bug reports here. As far as testing this. The problem is fixed. a. As I said this is a frequent problem with kernel updates. So I am pretty good at fixing it. All you have to do is do a rescue boot, and the do a reinstall of the grub boot loader. b. I could get it to do the same thing over and over again by reinstalling the previous kernel. But when I install the current kernel this problem doesn't occur. I am wondering if the problem is some kind of a dependency issue in the kernel rpm construction dependencies. I am wondering if the kernel package is doing a grub boot loader install, and in some cases is doing it before the right packages and software are loaded prior to executing this. At least twice in doing a dump of the data that I think makes up the boot loader I have found that outside of the menu the numbers for the old kernel seem to exist in the boot sector in a place where when I run the manual grub install the numbers for the new kernel exist. However for the time being this seems to be fixed. I am wondering if the solution is to close this one as fixed with the current rawhide, but then when I have the problem again open a new bug but reference this one. That might give you a better set of common denominators.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The problem still exists in production fc11. It appears to only happen on machines that use the /dev/md0 system with RAID1. I am finding that very little seems to work in fc11 with this configuration.
From what I can tell, grub doesn't like the partition table anaconda sets up. I wanted sda1 sdb1 RAID1(md0) -> /boot sda2 sdb2 SWAP partitions sda3 sdb3 RAID1(md1) -> LVM Phys -> /, /usr ..... sda4 sdb4 RAID1(md2) -> LVM Phys -> extra partitions When I did that using anaconda, grub wouldn't even get as far as loading the grub.conf menu, as far as I could tell. My solution was to use the rescue CD, use fdisk to create the partitions on sda, use sfdisk to copy the partition table to sdb, and then tell anacanda "custom layout." I was able to use the above partitions, get anaconda to assemble the raid partitions and the LVM paritions, and when I was done, the system booted fine. I don't know whether the bug should be with anaconda or grub, but somehow they need to agree such that whatever anaconda writes as a partition table must be usable by grub. Thanks!
I just got hit by this again about two days ago. Once again this is a /dev/md0 running RAID 1 as the root and no separate boot volume. I installed FC11 (production) and all was good. Then did yum update and it went into this reboot mode. Booted with a rescue CD and did a grub-install and all is fine again. This seems to have something to do with grub install failing during the install of the updated kernels.
This is still a problem, although I have not seen it come from an update recently it certainly still comes from updates and new installs. The problem appears to be that there is a problem with the way the boot loader is installed for RAID1 drive arrays. U have several bugs open for various versions of this.
This is a mass edit of all mkinitrd bugs. Thanks for taking the time to file this bug report (and/or commenting on it). As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on certain libraries it provides, but mkinitrd itself is no longer used. In Fedora 13 mkinitrd will be removed completely. This means that all work on initrd has stopped. Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.