Bug 839362 - dracut doesn't generate a working initramfs after F16 -> F17 upgrade ... it's dropping me to the debug shell
Summary: dracut doesn't generate a working initramfs after F16 -> F17 upgrade ... it's...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 17
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-11 18:01 UTC by Jaromír Cápík
Modified: 2016-02-01 01:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-29 13:47:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot ... sorry for the low quality (832.12 KB, image/jpeg)
2012-07-11 18:18 UTC, Jaromír Cápík
no flags Details
lsinitrd 3.3.8-1 (41.41 KB, text/plain)
2012-07-11 18:21 UTC, Jaromír Cápík
no flags Details
lsinitrd 3.4.4-5 (112.14 KB, text/plain)
2012-07-11 18:21 UTC, Jaromír Cápík
no flags Details

Description Jaromír Cápík 2012-07-11 18:01:26 UTC
Description of problem:
I just upgraded my workstation from F16 to F17 using the following yum howto:

http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17

Everything went well until the final reboot. There was no initramfs generated for the newly installed kernel 3.4.4-5. I started the system using the previous kernel/initramfs pair (3.3.8-1) and tried to generate the initramfs for 3.4.4-5 manually, but the result initramfs doesn't work. It's dropping me to the debug shell. It seems my md-raid array is not assembled well. I guess you would need more info. Please, ask what info could help you to identify the issue.

Version-Release number of selected component (if applicable):
dracut-018-78.git20120622.fc17

How reproducible:
always

Comment 1 Jaromír Cápík 2012-07-11 18:03:46 UTC
sorry ... ask -> tell me

Comment 2 Jaromír Cápík 2012-07-11 18:18:45 UTC
Created attachment 597644 [details]
screenshot ... sorry for the low quality

Comment 3 Jaromír Cápík 2012-07-11 18:21:07 UTC
Created attachment 597645 [details]
lsinitrd 3.3.8-1

Comment 4 Jaromír Cápík 2012-07-11 18:21:35 UTC
Created attachment 597647 [details]
lsinitrd 3.4.4-5

Comment 5 Harald Hoyer 2012-07-12 08:18:43 UTC
there are no modules in the 3.4.4-5 initrd.

I would guess depmod was not run or you have a broken kmod.

please run:

# yum update kmod

# depmod -ae -F /boot/System.map-3.4.4-5.fc17.x86_64 3.4.4-5.fc17.x86_64 \
  && echo OK

# dracut --force '' 3.4.4-5.fc17.x86_64

and check that the kernel modules are in the initramfs.

# lsinitrd /boot/initramfs-3.4.4-5.fc17.x86_64.img | grep lib/modules

Comment 6 Jaromír Cápík 2012-07-24 14:59:20 UTC
Hello Harald.

Thanks, that helped.
I don't know if it's a good idea to switch the component and search for the root cause or if we should rather update the F16->F17 update section on the Wiki ...

What do you think?

Regards,
Jaromir.

Comment 7 Harald Hoyer 2012-07-25 10:08:52 UTC
(In reply to comment #6)
> Hello Harald.
> 
> Thanks, that helped.
> I don't know if it's a good idea to switch the component and search for the
> root cause or if we should rather update the F16->F17 update section on the
> Wiki ...
> 
> What do you think?
> 
> Regards,
> Jaromir.

Well, in theory the "yum update" in the wiki should have pulled in the updated kmod. And in theory "depmod" should have been run by grubby's new-kernel-pkg after the whole yum update transaction. But the devil is in the details.

What you can do, is to add a note to the wiki describing on how to check, that depmod was run properly and what to do if not.


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