Bug 709615 - modprobe fatal, drops to dracut
Summary: modprobe fatal, drops to dracut
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-01 08:00 UTC by Frank Murphy
Modified: 2011-06-15 22:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-15 22:29:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Kernel 3 screencap (13.85 KB, image/png)
2011-06-01 08:00 UTC, Frank Murphy
no flags Details
Mock buildlog (7.69 KB, text/plain)
2011-06-03 08:55 UTC, Frank Murphy
no flags Details

Description Frank Murphy 2011-06-01 08:00:09 UTC
Created attachment 502189 [details]
Kernel 3 screencap

Description of problem: fatal drops to dracut


Version-Release number of selected component (if applicable):
kernel-3.0-0.rc1.git0.1.fc16.i686

How reproducible: A number of reboots


Steps to Reproduce:
1. install above kernel 
2. reboot
3.
  
Actual results: won't complete normal boot


Expected results: normal boot to 3 or 5


Additional info: Will boot to earlier installed kernels:
kernel-2.6.38.6-26.rc1.fc15.i686 
kernel-2.6.39-1.fc16.i686

This is a rawhide 32bit kvm guest on a F14 64bit host.

Comment 1 Maxine Bouffard 2011-06-02 16:34:02 UTC
Kyle McMartin replied on the mailing list to symlink the lib/modules folder from

/lib/modules/3.0.0-0.rc1.git0.1.fc16.x86_64

to:

/lib/modules/3.0-0.rc1.git0.1.fc16.x86_64

Change your arch accordingly of course. I saw that the kernel doesn't need triaging but I just thought I'd make sure that this one grabs the attention of users looking for a fix to minimize headaches.

Comment 2 Frank Murphy 2011-06-02 16:59:06 UTC
Having problems:

did 
ln -s  /lib/modules/3.0-0.rc1.git0.1.fc16.x86_64 /lib/modules/3.0.0-0.rc1.git0.1.fc16.x86_64

Is that correct?

Comment 3 Maxine Bouffard 2011-06-02 17:18:33 UTC
You're using the i686, so replace x86_64 with i686:

ln -s  /lib/modules/3.0-0.rc1.git0.1.fc16.i686 /lib/modules/3.0.0-0.rc1.git0.1.fc16.i686

Comment 4 Frank Murphy 2011-06-03 08:07:19 UTC
1: below fix doesn't work

ls -l
total 12
drwxr-xr-x. 6 root root 4096 May 25 17:43 2.6.38.6-26.rc1.fc15.i686
drwxr-xr-x. 6 root root 4096 May 25 19:43 2.6.39-1.fc16.i686
lrwxrwxrwx. 1 root root   26 Jun  2 19:06 3.0.0-0.rc1.git0.1.fc16.i686 -> 3.0-0.rc1.git0.1.fc16.i686
drwxr-xr-x. 6 root root 4096 Jun  2 19:54 3.0-0.rc1.git0.1.fc16.i686


2: below fix doesn't work

ls -l
total 12
drwxr-xr-x. 6 root root 4096 May 25 17:43 2.6.38.6-26.rc1.fc15.i686
drwxr-xr-x. 6 root root 4096 May 25 19:43 2.6.39-1.fc16.i686
lrwxrwxrwx. 1 root root   18 Jun  3 07:50 3.0.0-0.rc1.git0.1.fc16.i686 -> 2.6.39-1.fc16.i686
drwxr-xr-x. 6 root root 4096 Jun  3 07:49 3.0-0.rc1.git0.1.fc16.i686


3: below fix doesn't work

# Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2
# Source0: ftp://ftp.kernel.org/pub/linux/kernel/v3.0/linux-3.0-rc1.tar.bz2
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.0-rc1.tar.bz2


4: below fix doesn't work

mv linux-3.0-rc1.tar.bz2 linux-3.0.0-rc1.tar.bz2

Comment 5 Frank Murphy 2011-06-03 08:55:05 UTC
Created attachment 502760 [details]
Mock buildlog

Don't know if any help, but anyhow.

Both linux-3.0-rc1.tar.bz2 and linux-3.0.0-rc1.tar.bz2

exist in the src.rpm

The sun is out :)

Comment 6 Maxine Bouffard 2011-06-03 10:22:11 UTC
Ok, it needs to be the modules that were compiled with the linux image. Let's do a full sanity check as  to what's required to boot, don't paste anything in your files --

in /boot:
vmlinuz-<version>            -- the kernel
initramfs-<version>.img      -- init ram disk
System.map-<version>         is also usually installed.

---/boot/grub:
grub.conf, syntax for an installed kernel/menuitem:

[...]
# hiddenmenu
title Fedora GNU/Linux (3.0.0-rc1)
        root (hd0,0)
        kernel /vmlinuz-3.0.0-rc1 ro root=/dev/mapper/vg_phy-lv_root[..etc...]
        initrd /initramfs-3.0.0-rc1.img
[...second kernel in the list, and third, and so on below...]
Basically, compare the first kernel entry against the second, which is/was the last one that booted. It's safe to keep everything as is, just change vmlinuz, initramfs to their correct name in the new version, and of course the title.

If initramfs was missing, make a new one:
'dracut -H initramfs-<version>.img <version>'
(that will make it in your current dir), then move it to /boot


Now we have to make sure that the system doesn't whine on us like in your screenshot:

/lib/modules/3.0.0-0.rc1.git0.1.fc16.i686/modules.dep wants to be found.

Navigate to /lib/modules and there should be a folder for each of the kernels that you have installed. Find out which one was put there by the rawhide RPM package, and either symlink the folder above that wishes to be found or renaming it should work.

Double check to make sure, especially for typos. Reboot and if everything is where and what it should be, you should get to the LUKS decryption password screen.

If it fails to boot, in my opinion -- fallback to your previous kernel, remove the rawhide 3.0-rc1 packages that you installed and either try again or wait for a test/stable release.

----------------------------------------
To add: I've been using a vanilla 3.0-rc1 from kernel.org since a few days before the rawhide update, and this sneaky weasel indeed names itself "3.0.0-rc1" whilst building. Shouldn't be a huge deal, unless the specfile refers to 'linux-3.0-rc1' all along?

Comment 7 cgrim 2011-06-03 10:27:07 UTC
Frank Murphy: After creating of symlink did you rebuild initramfs image for dracut?

I did it by using:
dracut -f /boot/initramfs-3.0-0.rc1.git0.1.fc16.x86_64.img
3.0.0-0.rc1.git0.1.fc16.x86_64

... and after that F16 with kernel 3.0rc1 booted perfectly ;-) Before that I had the same problem as you had.

Comment 8 Andre Robatino 2011-06-03 19:03:23 UTC
After doing the fixes, I was still unable to complete the bootup, was in an apparent infinite loop with messages

type=1403 audit(xxxxxxxxxx.xxx:xxx): policy loaded auid=4294967295 ses=4294967295

roughly one per second. Using "enforcing=0" made no difference, but was able to bypass this and boot to the GUI with "selinux=0".

Comment 9 Andre Robatino 2011-06-08 18:59:54 UTC
With the 20110608 updates including the 3.0-0.rc2.git0.1.fc16.x86_64 kernel, the only workaround I need to boot is "selinux=0". The symlink and rebuilding initramfs aren't necessary anymore.


Note You need to log in before you can comment on or make changes to this bug.