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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
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.
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.
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 /
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.
Jim Meyering jim@meyering.net wrote:
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.
I've seen this as well. I think it may be linked with the BIOS getting confused about mashing the modifier keys to get GRUB to show up in the first place and then being "stuck" akin to Caps Lock.
--Ben