Bug 493724 - upgrade causes system to go into reboot mode
upgrade causes system to go into reboot mode
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-02 16:12 EDT by Ray Todd Stevens
Modified: 2010-01-12 10:32 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-12 10:32:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my yum log (57.07 KB, text/plain)
2009-04-07 20:02 EDT, Ray Todd Stevens
no flags Details
my upgrade log (66.13 KB, text/plain)
2009-04-07 20:02 EDT, Ray Todd Stevens
no flags Details

  None (edit)
Description Ray Todd Stevens 2009-04-02 16:12:33 EDT
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 /
Comment 1 Ray Todd Stevens 2009-04-03 12:39:46 EDT
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 2 Balaji Ravindran 2009-04-07 18:37:03 EDT
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
Comment 3 Ray Todd Stevens 2009-04-07 20:01:41 EDT
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.
Comment 4 Ray Todd Stevens 2009-04-07 20:02:30 EDT
Created attachment 338628 [details]
my yum log
Comment 5 Ray Todd Stevens 2009-04-07 20:02:57 EDT
Created attachment 338629 [details]
my upgrade log
Comment 6 Ray Todd Stevens 2009-04-07 20:20:24 EDT
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 7 Balaji Ravindran 2009-04-08 01:03:43 EDT
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
Comment 8 Ray Todd Stevens 2009-04-08 08:47:22 EDT
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.
Comment 9 Jeremy Katz 2009-05-06 12:52:42 EDT
There have been a few fixes recently for boot-on-raid.  Can you try with a newer snapshot?
Comment 10 Ray Todd Stevens 2009-05-07 12:19:17 EDT
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.
Comment 11 Bug Zapper 2009-06-09 09:08:31 EDT
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
Comment 12 Ray Todd Stevens 2009-07-06 17:16:04 EDT
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.
Comment 13 Mike Polek 2009-08-06 22:53:19 EDT
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!
Comment 14 Ray Todd Stevens 2009-08-25 11:14:25 EDT
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.
Comment 15 Ray Todd Stevens 2010-01-10 18:24:32 EST
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.
Comment 16 Hans de Goede 2010-01-12 10:32:49 EST
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.

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