Bug 1008697 - dracut-network not installed, although SAN is used for root
dracut-network not installed, although SAN is used for root
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-16 17:40 EDT by Dwayne McGarty
Modified: 2013-10-22 07:25 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-22 07:25:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of dracut --debug -f (280.59 KB, application/x-tgz)
2013-09-17 11:29 EDT, 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 10:04 EDT, Dwayne McGarty
no flags Details

  None (edit)
Description Dwayne McGarty 2013-09-16 17:40:23 EDT
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 17:47:43 EDT
Can you attach the output of:

# dracut --debug -f

before doing step 4?
Comment 2 Dwayne McGarty 2013-09-17 11:29:58 EDT
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 11:51:44 EDT
So, what is the bug again?
Comment 4 Dwayne McGarty 2013-09-17 18:36:47 EDT
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 10:04:52 EDT
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 02:45:57 EDT
Is dracut-network installed?
Comment 7 Dwayne McGarty 2013-10-20 20:05:05 EDT
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 08:43:50 EDT
(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 11:07:01 EDT
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 07:25:28 EDT
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.