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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Am 08.04.2011 12:38, schrieb Jim Meyering:
> 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.


Then again... "just don't do that" ... root-gun-foot ...

# rm -fr /
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Harald Hoyer wrote:
> Am 08.04.2011 12:38, schrieb Jim Meyering:
>> 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.
>
> Then again... "just don't do that" ... root-gun-foot ...

Hi Harald,

That's one way to see it.
However, what are the odds that the offending code ignores
all write failures, and not just AVC-induced ones?

And what if you're unlucky enough to run out of space in /tmp
at just the wrong moment -- or what if someone malicious knows
about this? Some script kiddies might think it's cool to make
the sysadmin install a broken kernel. I hope you have
convenient and reliable console access to that server.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel