Bug 1008697 - dracut-network not installed, although SAN is used for root
Summary: dracut-network not installed, although SAN is used for root
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-16 21:40 UTC by Dwayne McGarty
Modified: 2013-10-22 11:25 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-22 11:25:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output of dracut --debug -f (280.59 KB, application/x-tgz)
2013-09-17 15:29 UTC, Dwayne McGarty
no flags Details
Ouput of three commands directly after installation complete. No manual firmware copy. (305.45 KB, application/x-tgz)
2013-09-20 14:04 UTC, Dwayne McGarty
no flags Details

Description Dwayne McGarty 2013-09-16 21:40:23 UTC
Description of problem:
After installation, the Brocade HBA no longer sees SAN storage.

Version-Release number of selected component (if applicable):
19

How reproducible:
Install Fedora 19 from DVD iso image to SAN attached storage.

Steps to Reproduce:
1. Boot system from Fedora 19 DVD image.
2. Install OS to multipathed SAN storage .  SAN storage attached with Brocade 1007 CNA HBAs.
3. Reboot system.  System begins to boot but fails part way through and drops to the dracut prompt.  Logs show that the system can't locate the root or any lvm volumes.


Actual results:
System won't boot from SAN after initial installation.

Expected results:
Successful boot from SAN.

Additional info:
Found that the firmware required when bfa kernel modules load was not installed.  The firmware in question exists on the installation iso image but was not included in the final configuration.  My work around was:
1. Wait until the OS was installed and flip to the back console prompt before rebooting.
2. Copy firmware files /usr/lib/firmware/ctfw and ct2fw* to /mnt/sysimage/usr/lib/firmware directory.
3. chroot /mnt/sysimage.
4. Create /etc/dracut.conf.d/99firmware file with the contents:
   fw_dir+=":/usr/lib/firmware"

   (I never tested to see if this step was really necessary)
5. Moved existing initramfs file initramfs-3.9.5-301.fc19.x86_64.img to initramfs-3.9.5-301.fc19.x86_64.img.dist under /boot
6. Re-generated initramfs file.
   mkinitrd /boot/initramfs-`uname -r`.img `uname -r`
7. Verfied firmware was now included in initramfs file using lsinitrd.
   (lsinitrd | grep firmware).
8. Exited chroot environment, flipped back to installation gui and rebooted system as normal.  System successfully boots from SAN storage.

Comment 1 Harald Hoyer 2013-09-16 21:47:43 UTC
Can you attach the output of:

# dracut --debug -f

before doing step 4?

Comment 2 Dwayne McGarty 2013-09-17 15:29:58 UTC
Created attachment 798869 [details]
Output of dracut --debug -f

As requested, the output of dracut --debug -f.  This command was issued after copying firmware files to /mnt/sysimage/usr/lib/firmware and doing a chroot /mnt/sysimage.  This appears to include the missing firmware files properly in the resulting initramfs file so my work around is unnecessarily complex.

Comment 3 Harald Hoyer 2013-09-17 15:51:44 UTC
So, what is the bug again?

Comment 4 Dwayne McGarty 2013-09-17 22:36:47 UTC
If I just install the operating system as normal to a SAN disk and do the initial, fedora starts to boot, gets somewhere in the area of "Reached target Basic System" and falls to the dracut prompt.  At the dracut prompt I looked at the logs and it looked as though the system could not see any of the volumes on the SAN storage.  Running lvm commands returns nothingness.  I also see in the logs that there were messages about firmware files ctfw and ct2fw not being found.  If I do an lsinitrd | grep firmware, I don't see the firmware files being included in the initramfs.  If I install the operating system and go through the steps 1-8 I provided above to include the missing firmware files, the system boots fine.  

The firmware files required for the Brocade CNA 1007 HBAs I have are missing after installation in a nutshell.

Comment 5 Dwayne McGarty 2013-09-20 14:04:52 UTC
Created attachment 800512 [details]
Ouput of three commands directly after installation complete.  No manual firmware copy.

I am attaching a tar ball containing three files for comparison.  These are all output of lsinitrd and dracut -f --debug taken directly after the install is completed but before the initial reboot.  In this case, no manual copy of firmware files ctfw*, ct2fw* or cbfw* has taken place.  ie directly after step 1 in my previous work-around steps.

1.  lsinitrd-output-after-install-complete.txt.  This file contains the output of lsinitrd taken after the install is complete.  As you can see, the firmware files ctfw*, ct2fw* and cbfw* that will be need to boot from SAN are missing.
2.  dracut-debug-output.log.  This file is the output of dracut -f --debug that was run after I did the lsinitrd.
3.  lsinitrd-output-after-manual-dracut.  Again the output of lsinitrd taken after running dracut -f --debug.

Comment 6 Harald Hoyer 2013-10-14 06:45:57 UTC
Is dracut-network installed?

Comment 7 Dwayne McGarty 2013-10-21 00:05:05 UTC
I did a chroot /mnt/sysimage followed by rpm -qa | grep dracut.  I don't see dracut-network installed.

Comment 8 Harald Hoyer 2013-10-21 12:43:50 UTC
(In reply to Dwayne McGarty from comment #7)
> I did a chroot /mnt/sysimage followed by rpm -qa | grep dracut.  I don't see
> dracut-network installed.

well, it has to be for a SAN

Comment 9 Radek Vykydal 2013-10-21 15:07:01 UTC
I've checked that in F20 Alpha the dracut-network is installed, I'll do some more testing as boot from SAN does not seem to work for me.

Comment 10 Radek Vykydal 2013-10-22 11:25:28 UTC
I can confirm that install with boot on iSCSI works for me with F20Alpha so I am closing the BZ. If you hit the issue with F20 feel free to reopen the bug.


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