[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora] IBM Netfinity 5000 - SOLVED

On Monday 28 December 2009 00:50:00 Ashley M. Kirchner wrote:
> Jussi Lehtola wrote:
> > You just should have added the SOLVED keyword to the subject a few days
> > ago :)
>     Actually, not quite.  While the system is up and running just fine,
> with all updates and all, that doesn't solve the issue of those warnings
> received during the update process.  That's why I didn't 'SOLVED' the
> subject.  Those warnings don't seem to have any ill effect (to me),
> however I don't think it's ok either.  So that why I was asking, is it
> something that needs to be addressed?  Is it something I'm missing?  Is
> it something with the update process?  Is it something that's genuinely
> missing from the kernel?  I don't know.

As far as I recall, this is the artifact of the change in the policy of 
updating initramfs.img file while installing a new kernel.

I forgot the actual bugzilla link (you can probably use google to find it), but 
the story goes more or less like this (I'm writing this from remaining memory 
of reading the bugzilla, might be way incorrect):

The file initramfs.img is being generated on the fly by the kernel on boot, and 
is only declared to exist in the kernel's .rpm archive. Up to now, rpm would 
just create a dummy file of zero size and let the kernel fill it up later on 

But then, in some setups with a rather small /boot partition, it could happen 
that rpm checks for free space on /boot, finds it is big enough, installs the 
kernel, and when the time comes to grow the initramfs.img to its actual size, 
/boot runs out of space, and the update/upgrade fails *after* rpm finished and 
reported that all is ok. This has led to a lot of "my /boot is big enough but 
upgrade still fails" problems.

So the maintainers decided to change the policy, and have rpm create a dummy 
file of some non-trivial default size in order to circumvent the issue above. 
But now the kernel rewrites it (and changes it's size appropriately) as usual, 
and when installing a new kernel rpm checks against its database and sees that 
someone has been tampering with the file. It issues a warning, deletes it and 
creates a new dummy. But then the running kernel sees that the file has been 
overwritten, and issues a warning that some modules might not be available 
anymore (those modules reside in the file, I guess...). That is, until the new 
kernel generates the contents of the file again on next boot.

I am probably wrong about the details of this story, but what happens is 
something along those lines --- kernel and rpm confusing each other over that 
file during the update process. But the whole thing is completely benign, as 
the file itself is a dummy, and the kernel does not actually miss anything from 
it. That's how I understood the whole affair.

IOW, you are probably safe to ignore those messages. They scared me too when I 
saw them during an ordinary yum update some time ago, so I googled out the 
bugzilla describing the above story, and essentially understood that those 
warnings are harmless.

HTH, :-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]