On Wed, Jun 26, 2013 at 9:15 PM, Felix Miata
On 2013-06-26 20:09 (GMT-0300) Claudio Freire composed:
New kernel get new initrd (or not, not my point).
OLD kernel with OLD initrd goes kaboom, because the filesystem does have the new glibc.
Never in my recollected experience has that happened. Unlike most people, I'm an OFM user, and with few exceptions retune my Grub menu after each installation or update process that changes it or the content of /boot. In similar manner I commonly backup initrds before updating, and on arbitrary occasions boot using the initrd created when the particular older kernel selected to test was originally installed, not one more recently created, for the express purpose of verifying that both older kernel and initrd do still get the system up and usable.
Indeed, I didn't get the chance to say, before you bit my head off
(this said in all coolness ;-) - no hurt feelings), that it surely
would be less common than the breakage the OP mentions, and reverting
to no clobbering would thus be an improvement.
But I did want to bring the possibility up, because it would be nice
to find an all-encompassing solution.
On Thu, Jun 27, 2013 at 3:55 AM, Andreas Schwab
Claudio Freire
writes: because the filesystem does have the new glibc.
Which doesn't matter at all, since the initrd comes with its own, proven working glibc.
It does matter, because, you'd boot, but you wouldn't get init going after leaving the initrd. So it's a half-boot. Ok, yes, this is a far out possibility. But I can imagine more twisted cases that could also collude against an old initrd. Everytime there's userspace libs or tools that require intimate knowledge of the kernel, and there's plenty of those, usually the most basic, there's this kind of possibility. I wouldn't put dbus past this either. I hate to say this, but here we should take a lesson from Windows. Known-good state anyone? Multiversion initrds should only be updated when the system is at a known-good state. They're backups. They should serve as backups until updating is known to be a good idea. Perhaps user intervention would be wise, or perhaps some automated rule, like updating them late during next boot. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org