Fedora Core 3 Update: mkinitrd-4.1.18.1-1

[Dave Jones]

On Fri, Jul 29, 2005 at 03:31:33PM -0500, Damian Menscher wrote:
 > On Fri, 29 Jul 2005, Dave Jones wrote:
 > 
 > >This update should fix the issue a number of people saw
 > >after the recent kernel update where various modules would
 > >fail to load during boot, making systems unbootable.
 > >
 > >After updating this package, remove, and reinstall the
 > >recent kernel update, and the initrd will be recreated
 > >correctly.
 > 
 > For those of us who recognized the dangers of the new kernel and never 
 > installed it, what is the recommended course of action?  Will a simple 
 > "up2date" that installs the new mkinitrd and the new kernel 
 > simultaneously work?  I'm guessing I should up2date the mkinitrd in one 
 > pass, then up2date the kernel in a second pass?  Some confirmation would 
 > be nice.

To play it really safe, do them as two operations.

up2date mkinitrd first, and then up2date -fu kernel

 > I would like to know exactly what bug was fixed here, and am assuming 
 > that 145660 is a bugzilla number.  But I'm "not authorized to access" 
 > that bug:
 >    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145660

The bug for this issue should have been 163407, that's a screwup in the
mkinitrd changelog entry.

 > Since when are bug reports so secretive?  I can understand making them 
 > restricted in the case of embargoed security fixes, but that does not 
 > apply here (or in the several other cases I've seen of unreadable 
 > bugzilla entries.

The 'sekrit' bug is a RHEL4 bug. There can be many reasons for them
being non-visible other than security embargoes. Confidential information
from partners, NDA'd info, bug reports from preproduction hardware etc etc.

 > Rather than forming a fedora-bugs triage team, how about just letting 
 > people see what bugs already exist, so we can avoid future dupes?

This wasn't intentional, just a good old fashioned screwup.

		Dave