On 2013-06-26 13:46 (GMT-0400) Claudio Freire composed:
The way initrds get clobbered now, what point is there to enabling multiversion for kernels?
Is it better to have binaries match in a clobbering initrd that won't boot the system? I think not.
And how do you know forehand if the new binaries break or fix the system?
Again, this is about behavior when multiversion is enabled for kernels.
What ain't broke don't need fixin.
It may need fixing. Think new glibc that needs new kernel.
Exactly: NEW KERNEL needs new this or that or vice versa!!! New kernel is not the subject of the thread. The thread asks why unconditionally clobber old kernel's initrd installed with last updates and older kernel's initrd installed with updates before that, etc, etc: IOW, why clobber initrds that worked for not new kernels, so that when something bad happens in newest kernel and/or initrd and/or mkinitrd that kernel and matching initrd that worked in the past stands a good chance of getting a successful boot so that whatever broke can be fixed without need for a rescue boot from some other media. Again, what purpose does multiversion for kernel serve with this current practice of clobbering *all* initrds *every* time *anything* affecting initrd makeup gets changed??? What?
Now you update the kernel, but not the initrd's libc, kaboom.
Why is everyone responding to this thread ignoring the keywords?: RE-build Existing Multiversion Multiple Every
I'm not that knowledgeable about libc, so maybe this particular case isn't an issue. But the idea is that binaries and kernel may need to match,
Maybe they do, maybe they don't. I've plenty of times saved kernel, initrd and modules at version upgrade time and found they continue to be functional and highly preferable to rescue booting after several subsequent iterations of kernel version upgrades.
and if you don't update the initrd, the system could also break.
As original thread starter wrote, updating broke the system, and presumably since multiversion for kernels is enabled by default, in the process broke the previously installed kernel/initrd pair(s) that worked in the past, and had they not been, would have been able to be used to correct the new failure that was also applied to destroy what had been working. Again, what is the point of by default enabling of multiversion for kernel if not to function as a better-than-nothing proven fallback kernel/initrd to be used in the event that the newest kernel/initrd pair does not work? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org