resolved [Re: heads up: new rawhide kernel doesn't boot for me

[Jim Meyering]

Jim Meyering wrote:
> Daniel J Walsh wrote:
>> On 04/07/2011 07:46 AM, Jim Meyering wrote:
>>> I updated my rawhide VM today (on F15 host), but it failed to reboot
>>> using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
>>> I got a failure (VFS diagnostic complaining that the UUID-specified
>>> root partition was not available), then panic.
>>>
>>> Two subsequent attempts to reboot failed because even though I got
>>> to the grub kernel-selection menu, I was unable to get a response
>>> out of the interface, so couldn't select any other kernel or even
>>> edit a grub stanza.  Luckily for me, on the third attempt, grub's
>>> UI did respond to down-arrow and "ENTER", so I could select
>>> the preceding kernel, and that one did manage to boot.
>>>
>>> If necessary (i.e., if it's not already fixed), I'll file a BZ.
>>
>> kernel-2.6.39-0.rc2.git0.0.fc16 Works for me.
>
> Good to know.  Thanks, Dan.

That one failed for me, too, in the same way.
I've just noticed that the grub.conf stanzas for the two losing kernels
lack an "initrd initramfs-..." line, so reinstalled the latest kernel:

    # yum reinstall -y kernel
    ...
    Downloading Packages:
    kernel-2.6.39-0.rc2.git0.0.fc16.x86_64.rpm                |  23 MB     01:38
    Running Transaction Check
    Running Transaction Test
    Transaction Test Succeeded
    Running Transaction
    etckeeper: pre transaction commit
      Installing : kernel-2.6.39-0.rc2.git0.0.fc16.x86_64                    1/1
    Non-fatal POSTTRANS scriptlet failure in rpm package kernel-2.6.39-0.rc2.git0.0.fc16.x86_64
    etckeeper: post transaction commit

    Installed:
      kernel.x86_64 0:2.6.39-0.rc2.git0.0.fc16

    Complete!

Still no initramfs.  That's definitely a problem.
I ran it one more time, this time while tailing /var/log/audit/audit.log,
which led me to the culprit: me.

I'm using a separate, memory-backed, private TMPDIR, e.g., /t/jt-3k07S5,
and had indeed set perms of /t, -- and its context via this,
  semanage fcontext -a -t tmp_t '/t(/.*)?
but had forgotten to set its context:
  chcon --ref /tmp /t

Once I fixed that, reinstalling the kernel did create the initramfs.

So maybe there *is* a bug to report after all:

    With TMPDIR pointing to a directory with context not like /tmp,
    the kernel's initramfs-building code fails and gives a diagnostic
    (calling it Non-fatal), but lets the installation of a losing
    kernel succeed.