On Sat, 2004-08-14 at 04:16, David Woodhouse wrote: [snip] > It happens with stable releases too. > > It happened for me with RHL9 -- the shipped kernel didn't boot and I was > left with none. As a general rule I have *never* trusted upgrades from any OS vendor. And that's not a judgment of any vendors' competence, just a statement of what I believe about upgrades. Ask Red Hat what they advise their RHEL customers do when moving from one release to the next and I'll bet you will find that they recommend full installs on new hardware and then migrating applications and data over. In fact, one Red Hat representative did in fact say that during their visit to Boston for their world tour back in March. That said, I don't think that upgrading (as opposed to installing) a kernel is at all a bad thing to do during an OS upgrade for the simple fact that the installer is not upgrading a kernel that is currently running. The real problem with upgrading a kernel when just doing an up2date or yum is that you are upgrading a kernel that is currently running along with all its modules. This causes much breakage during *shutdown* which in turn could potentially wreak havoc on you're filesystem (lessened these days thanks to journaling filesystems). IMO, OS upgrades should be viewed with the same wary eyes as complete installs: if it doesn't work, you may end up with an unbootable system. Every effort is made to make sure that doesn't happen on the developers end, but the end result is the same as if you did a full install. That's what testing is for. I have upgraded many systems, some all the way from Red Hat 6.2 to Fedora Core 2 and at various points have wound up with unbootable systems. I have *also* cursed the installer for doing such a thing. It's happened enough that I've been able to recover the system to be bootable again every time. Most of my problems have stemmed from using Linux raid 1 for my boot disk and the grub update failing on it during upgrade, however I *have* had kernels that absolutely wouldn't run on these systems without a patch (stock FC1...he no like Intel 440GX chipset ;-)). But after I calm down I remember my basic belief that all OS upgrades, though they often work, are hacks -- so to speak. I don't consider errata the same kind of process. Those should never break anything that worked in the previous version of that component. And that includes the upgrade procedure itself -- don't remove things that are currently in use. I often install the latest errata kernels (or really, "updates" when speaking of Fedora Core) on production systems at planned downtimes. But I'll always test (okay, okay, sometimes I flip a coin) these kernels on identical or at least *nearly* identical hardware. I do this mostly because I feel its important to keep my production systems secure. But it would be a bad thing, and I think we all agree on at least this part, to *upgrade* that kernel. But an OS upgrade isn't something I do as part of a routine maintenance window. All of the above is, yes, just IMO. But I just wanted to voice my opinion that I think the current practice of upgrading kernels during an OS upgrade, but installing them during up2date/yum runs is in fact the best practice and not something I'd want to see changed. I wouldn't be *entirely* opposed keeping an old kernel around. But I suspect that ensuring that firstboot doesn't run with the older kernel and other potential problems that may arise from having a kernel from an older release running on the current version of the OS may end up in more NOTABUG-closed bugs in bugzilla than Red Hat is willing to deal with. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets
