Description of problem: In the GUI based installation, when “Advanced Storage Configuration” button is pressed, we are taken to “Advanced Storage Options” and in this window we select the “Add iSCSI Target” (This is the only active tab for selection) and press the “Add Drive” Button. We are taken to “Enable Network interface” window where we select ethX & press OK. This will take a while to configure the ethX and it returns to the “Advanced Storage Configuration” window instead of “Advanced Storage Options” window. When I try the second time the same things repeat, but the second time I expect that it would skip the network configuration, since I just did it, and prompt for adding of iSCSI Target IP and Initiator Name. The code shows, def addIscsiDrive(self): if not network.hasActiveNetDev(): net = NetworkConfigurator(self.anaconda.id.network) ret = net.run() net.destroy() return ret I don't think it should be returning at this point. It should continue if the return code is OK. However, I don't understand why the second time around network.hasActiveNetDev() should be returning true, and it should skip the if statement and also the return. Version-Release number of selected component (if applicable): anaconda-11.1.2.34-2.i386.rpm How reproducible: Always reproducible. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Is the network device being brought up successfully? You should be able to check on tty2
ya, i am able to see the Network devices The logs look like this: <5>SCSI device sda:10240000 512-byte hdwr sector(5243) <5>sda: Write protect is off <7>sda: Mode Sense: 77 00 00 08 <5>SCSI device sda: drive cache: write through ...................................... ...................................... <5> Vendor: IET Model:VIRTUAL-DISK Rev: 0 <5> Type: Direct-Access ANSI SCSI revision: 04
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 229212 has been marked as a duplicate of this bug. ***
Is there a prelimenary version of the anaconda with this fixed in so that I can test it? Thanks.
yikes! The RHEL5 U1 build tree from 20070618 is in worst state than the RHEL5 GA product when it comes to installation on an iSCSI storage. The install (via PXE bootup - haven't tried via CD/DVD) cannot see the iSCSI targets. Here is what the anaconda.log has to say: 11:41:00 INFO : iSCSI initiator name iqn.2005-03.com.max:01.cc0e46 11:41:00 DEBUG : Setting up /etc/iscsi/initiatorname.iscsi 11:41:00 INFO : ISCSID is /usr/sbin/iscsid 11:41:36 DEBUG : iscsiadm -m discovery -t st -p 192.168.77.51:3260 11:41:36 WARNING : didn't get what we expected from iscsiadm 11:41:36 WARNING : unable to find portal information 11:41:36 INFO : iSCSI shutdown 11:41:36 INFO : iSCSI initiator name iqn.2005-03.com.max:01.cc0e46 11:41:36 DEBUG : Setting up /etc/iscsi/initiatorname.iscsi 11:41:36 INFO : ISCSID is /usr/sbin/iscsid But the target definitely has data: sh-3.1# iscsiadm -m discovery -t st -p 192.168.77.51:3260 192.168.77.51:3260,0 iqn.2001-05.com.equallogic:6-8a0900-1f1fe0101-08bff11243144046-store-dumps 192.168.77.51:3260,0 iqn.2001-05.com.equallogic:6-8a0900-6eafe0101-bf9ff112424436a2-test-1 192.168.77.51:3260,0 iqn.2001-05.com.equallogic:6-8a0900-725fe0101-4fbff112427436a2-test-2 192.168.77.51:3260,0 iqn.2001-05.com.equallogic:6-8a0900-746fe0101-27bff11242a436a2-test-3 192.168.77.51:3260,0 iqn.2001-05.com.equallogic:6-8a0900-769fe0101-e11ff11242d436a2-test-4 sh-3.1#
I think the 19th is when the iscsi changes appeared so I am not sure what would cause breakage in 20070618 iscsi wise. There was a bug in the iscsi update. Here is the bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244987 It is fixed in the current rpm.
Mike, The issue I am encountering is that the anaconda tool is not parsing the data from iscsiadm properly. The iscsiadm tool works just fine.
(In reply to comment #11) > ----- Additional Comments From doug_maxey.com (prefers email at > dwm.com) 2007-06-21 14:36 EDT ------- > MikeC, > any chance the current srpms for both anaconda and iscsi-initiator-utils > can be > posted somewhere? > > I was in the middle if of putting the kernel (with qlogic and iscsi bits), and iscsi rpms ups. I will throw in the anaconda bits too.
(In reply to comment #8) > yikes! > > The RHEL5 U1 build tree from 20070618 is in worst state than the RHEL5 GA > product when it comes to installation on an iSCSI storage. The install (via PXE > bootup - haven't tried via CD/DVD) cannot see the iSCSI targets. Here is what > the anaconda.log has to say: > 11:41:00 INFO : iSCSI initiator name iqn.2005-03.com.max:01.cc0e46 > 11:41:00 DEBUG : Setting up /etc/iscsi/initiatorname.iscsi > 11:41:00 INFO : ISCSID is /usr/sbin/iscsid > 11:41:36 DEBUG : iscsiadm -m discovery -t st -p 192.168.77.51:3260 > 11:41:36 WARNING : didn't get what we expected from iscsiadm > 11:41:36 WARNING : unable to find portal information > 11:41:36 INFO : iSCSI shutdown > 11:41:36 INFO : iSCSI initiator name iqn.2005-03.com.max:01.cc0e46 > 11:41:36 DEBUG : Setting up /etc/iscsi/initiatorname.iscsi > 11:41:36 INFO : ISCSID is /usr/sbin/iscsid > > But the target definitely has data: > sh-3.1# iscsiadm -m discovery -t st -p 192.168.77.51:3260 > 192.168.77.51:3260,0 > iqn.2001-05.com.equallogic:6-8a0900-1f1fe0101-08bff11243144046-store-dumps > 192.168.77.51:3260,0 > iqn.2001-05.com.equallogic:6-8a0900-6eafe0101-bf9ff112424436a2-test-1 > 192.168.77.51:3260,0 > iqn.2001-05.com.equallogic:6-8a0900-725fe0101-4fbff112427436a2-test-2 > 192.168.77.51:3260,0 > iqn.2001-05.com.equallogic:6-8a0900-746fe0101-27bff11242a436a2-test-3 > 192.168.77.51:3260,0 > iqn.2001-05.com.equallogic:6-8a0900-769fe0101-e11ff11242d436a2-test-4 > sh-3.1# > > I've been unable to recreate the problem on my laptop using an execWithCapture driver using the iscsiadm output that you sent me. The output is captured, parsed, and used correctly. So at this point I need to break in to the debugger after the iscsiadm line runs to see what is actually happening. I'm guessing the command is executing incorrectly -or- we aren't grabbing the output correctly. The parsing code works fine using the sample output you sent me. Can we do that today or tomorrow?
Try tomorrow's RHEL-5 build. I think the problem was with the iscsiadm command used for portal discovery.
Tried 20070621 RHEL5 tree. Still no go. Same error.
Konrad reports that the 6/25 nightly build works. Moving this bug to MODIFIED.
I do not think this bug is fixed yet. If you are doing a PXE boot up for install, then the network will be setup before we get to the setup screen that was being reported as broken. Konrad did you try a CD install and try to setup the network from the screen described in the opening comments.
Mike, No. Is the iSCSI storage that I've been having trouble with working now?
David, Mike, I've not actually tested that the CD install works. My first objective was to get PXE to work and I've had no luck so far with that. I did get to install RHEL5 U1 on a IET iSCSI target but the blade won't boot from that storage - it can boot from hardware iSCSI targets thought - but I can't install RHEL5 U1 on those other storage b/c I get getting media errors. So Mike, is that storage I've been trying to install too - are you encountering the same panic I've been hitting or is it OK now?
Konrad, that box works for me. I have not been able to replicate the problem here. I am accessing the box from MSP though. Are you using the box locally? The bug may only occur when we have high IO and we have IO starting and completing at the same time.
Mike, After Barry power the EqualLogic on/off I was able to install the RHEL5 U1 nightly build (20070719) on the iSCSI target succesfully. I also configured the HS-20 to use the software iSCSI initiator and mount the iSCSI target as the boot-up disk. And viola, RHEL5 U1 booted without any trouble on the HS-20 with only the software iSCSI initiator. I am also going to test the RHEL5 U1 i386 tomorrow.
RHEL5 U1 i386 - works, installs, boots. RHEL5 U1 using a kickstart files - works, installs, boots.
I should have mentioned that the RHEL5 U1 on a iSCSI target using iSCSI software initiator was using PXE. I haven't tried to do CD or DVD install yet.
I have tested a snapshot from july 25th and it still has the same problem. You cannot test with a method that starts the network before we get to the storage setup because the network is already up at that point so we skip the network screen and bypass the problem. Just installing from the CD is a easy way to replicate the problem. Where the original comment indicates the problem is seems to be right. I am not familar with the installer code though so I do not know for sure. Dropping down to a shell and running ifconfig does show that the network got setup correctly. And you can ping other hosts from the shell, so the network also works fine. Let me know if you need any more info.
Just to make sure I'm on the same page, it's installation from CD that's failing, but networking installations work?
(In reply to comment #26) > Just to make sure I'm on the same page, it's installation from CD that's > failing, but networking installations work? Yep. The problem is in the network setup screen you get when the network is not up and you hit the Advanced Storage Configuration button right before you partition a disk.
Is there any progress on this? Since intel narrowed down the problem. Are you guys waiting for a patch from them or did something go into cvs already? Intel can test whatever patches we have if you guys want.
Bug is in ON_QA status meaning we have a fix for it and QA is testing it. Slated for inclusion in RHEL 5.1. Betas and snapshots of 5.1 are available for testing.
I accidentally removed the ITs 119765, 113211, 118121. Adding them back.
(In reply to comment #29) > Bug is in ON_QA status meaning we have a fix for it and QA is testing it. > Slated for inclusion in RHEL 5.1. Betas and snapshots of 5.1 are available for > testing. Does this mean that it is fixed in RHEL5.1 Snapshot #2? We tested the GUI and it could not pass the code which we've identified. We're looking into the source to see if anything has changed around that code, but we're doubtful.
I just tested the nightly build from yesterday and it still does not work. I think this got put into on qe by accident. Konrad sort of hijack the bugzilla with some other problem. His problem got fixed but the network issue did not. So when he reported it worked, he just meant it worked for his setup which was not the same as the bug reporter. Konrad already had the network setup (he was doing a net install), but intel and others were doing the CD install so they hit the bug in the network setup screen.
A fix for this issue should have been included in the packages contained in the most recent snapshot (partners.redhat.com) for RHEL5.1. Requested action: Please verify that your issue is fixed as soon as possible to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. More assistance: If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
Shouldn't this BZ be moved to FAILS_QA since "and it still does not work."?
Changing status based on Comment 32
(In reply to comment #32) > I just tested the nightly build from yesterday and it still does not work. I > think this got put into on qe by accident. Konrad sort of hijack the bugzilla > with some other problem. His problem got fixed but the network issue did not. So > when he reported it worked, he just meant it worked for his setup which was not > the same as the bug reporter. Konrad already had the network setup (he was doing > a net install), but intel and others were doing the CD install so they hit the > bug in the network setup screen. OK, this is really bad. I am going with the assumption that network-based installs are working and I need to work on CD installs. I was under the impression that the comments were all for the same issue, sorry about that. These two issues should have had separate bugs filed and tracked. Sorry about that. I will get on the CD install/network issue and try to come to a solution.
Please fine the patch below which is a fix for this Bug. Please review it and take it if you feel its useful. I followed the following step for testing. 1. Applied this patch to the extracted files from anaconda-11.1.2.62-1.i386.rpm 2. Created a update disk (i used floppy disk for this) and copied the patched file into the update disk 3. Started Linux Installation with the option "Linux updates" 4. When Anaconda asks for "Update Disk Source", i pointed it to fd0. 5. The "Advanced Storage Configuration" took me to “Enable Network interface”, when the network configuration is done, i am able to see the "Configure iSCSI Parameter" window which i am supposed to. ============================================================================= diff -Naur a/usr/lib/anaconda/iw/autopart_type.py b/usr/lib/anaconda/iw/autopart_type.py --- a/usr/lib/anaconda/iw/autopart_type.py 2007-08-23 11:20:46.000000000 -0700 +++ b/usr/lib/anaconda/iw/autopart_type.py 2007-08-23 11:40:16.000000000 -0700 @@ -106,7 +106,6 @@ net = NetworkConfigurator(self.anaconda.id.network) ret = net.run() net.destroy() - return ret (dxml, dialog) = gui.getGladeWidget("iscsi-config.glade", "iscsiDialog") =============================================================================
Tested against RHEL5.1-Server-20070822.1/ppc 1) Boot off DVD 2) Select "Advanced storage configuration" 3) Select add iSCSI drive 4) Select appropriate NIC (dhcp, enable ipv4) Fails to enable networking ... konrad: does this match your findings?
James, My testing on a HS-20 with RHEL5.1-Server-20070822.1/x86_64 ISO image confirms the problem. I've followed the same exact steps and I do not see the menu asking me to enter the iSCSI IP. I did switch to VC-2 to check ifconfig, which shows that the IP was retrieved - it is just that anaconda is not letting me see the iSCSI menu.
The fix for this was checked in on August 27th. It will appear in anaconda-11.1.2.68-1 or greater, which should be in snapshot 4.
RHEL 5.1 Snapshot 4 has "anaconda-11.1.2.66-1.i386" and not "anaconda-11.1.2.68-1", So in which version of "RHEL 5.1 Snapshot X" will we be seeing anaconda-11.1.2.68-1 with the changes ?
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot6 on partners.redhat.com. Requested action: Please verify that your issue is fixed ASAP to confirm that it will be included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
Verification passed on RHEL5.1-Snapshot6. Anaconda Version: anaconda-11.1.2.75-1.i386.rpm. Thanks for the updation. I am unable to change the status. Please update the status to Verified. Thank you.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0644.html