I too suffered from this and it was hell to debug since each attempt trashed all existing initreads due to totally dumb behaviour by mkinitrd, ie rebuild all initreads not just rebuild those you say, or need it (ie vmlinuz exists but NO matching initrd). I attach a perl script to build a git tag and only its initrd. Linus is right, there are far too many idiots, in distributions and desktops eg KDE BREAKING things, and far too little TESTING and DOCUMENTING. I have just tossed Kmail 2 for its crappy, buggey behavior and am thinking about tossing KDE and SuSE for the same ... Fixate on NEW things, break old things stupidity. As a 15 year SuSE and 25 year Solaris user this will pain me but I am not up for a week in hell with each new Gold Master. MFG,brian
Am Wed, 26 Jun 2013 14:42:36 -0400, scheib Felix Miata:
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
-- Greetings (mit freundlichen Grüßen), Brian. Dr. Brian O'Mahoney Email: omb@teraflex.ch Phone: +44 (0) 7711 489965 GPG Key ID: E4A3BCF8 2009-12-11, old PGP Key Id: 0xA0481D676FBC700C