Bug 713348 - RHEL6.1 installation failed on the machine ibm-ls22-01.rhts.eng.brq.redhat.com
Summary: RHEL6.1 installation failed on the machine ibm-ls22-01.rhts.eng.brq.redhat.com
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Ales Kozumplik
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-15 03:26 UTC by Dayong Tian
Modified: 2014-09-30 23:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-16 13:19:05 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dayong Tian 2011-06-15 03:26:53 UTC
Description of problem:
I could reserve the machine and the distro was also OK. The job was in running status for several hours then aborted in the /distribution/install process:
---------------------
 RecipeID: 197035 Arch: x86_64 System:
 ibm-ls22-01.rhts.eng.brq.redhat.com Distro: RHEL6-6.1 OSVersion:
 RedHatEnterpriseLinux6.1 Status: Aborted Result: Warn
                          TaskID: 2128487 TaskName: /distribution/install
 StartTime: 2011-06-13 08:41:40 Duration: 3:03:39.562731 Status: Aborted
 Result: Warn
---------------------

Version-Release number of selected component (if applicable):
kernel 2.6.32-131.4.1.el6

How reproducible:
always

Steps to Reproduce:
1. install RHEL6.1 with the machine
  
Actual results:
Aborted the first time:
https://beaker.engineering.redhat.com/recipes/196601
Aborted the second time:
https://beaker.engineering.redhat.com/jobs/96665

looking at the console.log that was uploaded anaconda is barfing here:
Examining storage devices
The following error was found while parsing the kickstart configuration file:
The following problem occurred on line 39 of the kickstart file:
Specified unpartitioned disk sda in partition command

Line 39 of the ks.cfg is:
part /boot --fstype ext3 --size 200 --recommended --ondisk=sda

Expected results:

Additional info:
Filed tickets to eng-ops, they said "This looks like an anaconda bug to me and a bz should probably be opened.":
https://engineering.redhat.com/rt3/Ticket/Display.html?id=113222
https://engineering.redhat.com/rt3/Ticket/Display.html?id=113240

Comment 2 Ales Kozumplik 2011-06-15 10:08:36 UTC
this looks like a multipath issue, assigning the bug to myself.

Comment 3 Ales Kozumplik 2011-06-16 13:19:05 UTC
Looking at the logs there seems to be a problem with the partitioning specified in the kickstart:

the machine has three disks: sda, sdb and sdc, sda and sdb forming a multipath. The kickstart attempts to create partitions on sda which we do not allow. If you want to partition the multipath device you have to use 'mpatha' instead of 'sda' (incidentally this functionality is broken at the moment, see bug 696876), or just install the system on sdc (but then the boot order probably needs to be tweaked as well). Alternatively the 'autopart' kickstart command can be used.

Either way, the kickstart from job 696876 is not valid for this machine, closing as not a bug.

Comment 4 Vadim Grinco 2011-06-17 09:48:25 UTC
Ales, is there any reason why in 6.0 the internal disk was detected as sda, and multipath as sdb and sdc which has changed in 6.1 and later? I can not anticipate changes like that in the future, and if this will happen in the future, other installs will also break. That is the main reason I insisted on opening a bugzilla rather than working around the problem in beaker. Currently I excluded rhel 6.1 and 6.2 from those machines.

Comment 5 Ales Kozumplik 2011-06-17 10:20:02 UTC
(In reply to comment #4)
> Ales, is there any reason why in 6.0 the internal disk was detected as sda, and
> multipath as sdb and sdc which has changed in 6.1 and later? I can not
> anticipate changes like that in the future, and if this will happen in the
> future, other installs will also break. That is the main reason I insisted on
> opening a bugzilla rather than working around the problem in beaker. Currently
> I excluded rhel 6.1 and 6.2 from those machines.

If there's a reason it is in on the kernel side, that is the device naming became less deterministic with the kernel in 6.1. I have to say I am seeing this too.

However you should be able to call the disks by their scsi id if they have one, for instance:

part / --fstype=ext3 --grow --asprimary --size=100 --ondisk=disk/by-id/scsi-3600a0b800067fabc000067694d23fe6e

Ales


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