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.
- Thu Jul 28 2005 Peter Jones pjones@redhat.com - 4.1.18.1-1
- Make nash check pids returned from wait*() (#145660)
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
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.
Rather than forming a fedora-bugs triage team, how about just letting people see what bugs already exist, so we can avoid future dupes?
Damian Menscher
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
On Friday 29 July 2005 15:39, Dave Jones wrote:
To play it really safe, do them as two operations.
up2date mkinitrd first, and then up2date -fu kernel
If you want to keep any of your old kernels, don't do this, as it'll delete them. It's been a while since I tried "up2date" but you may want "-i" rather than "-u" here.
Regards, Mike Klinke
On Fri, Jul 29, 2005 at 04:41:27PM -0500, Mike Klinke wrote:
On Friday 29 July 2005 15:39, Dave Jones wrote:
To play it really safe, do them as two operations.
up2date mkinitrd first, and then up2date -fu kernel
If you want to keep any of your old kernels, don't do this, as it'll delete them. It's been a while since I tried "up2date" but you may want "-i" rather than "-u" here.
I thought up2date special cased the kernel so that it always installs rather than updates ?
Though, it's been quite a while since I've used it too..
Dave
On Friday 29 July 2005 17:14, Dave Jones wrote:
I thought up2date special cased the kernel so that it always installs rather than updates ?
Though, it's been quite a while since I've used it too..
If so, then disregard what I said as I'm just out-of-date. At one time ( when I was last using it ) you had to be careful or you'd loose the old kernels.
Regards, Mike Klinke
On Jul 29, 2005, Mike Klinke lsomike@futzin.com wrote:
On Friday 29 July 2005 17:14, Dave Jones wrote:
I thought up2date special cased the kernel so that it always installs rather than updates ?
Though, it's been quite a while since I've used it too..
If so, then disregard what I said as I'm just out-of-date. At one time ( when I was last using it ) you had to be careful or you'd loose the old kernels.
It's configurable. If you have kernel* listed as install-only (the default), then it will install even if you ask for an update. If you change that such that kernel packages no longer match, then you'll get them updated.
-
Alexandre Oliva -
Damian Menscher -
Dave Jones -
Mike Klinke