RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 821101 - Documentation inconsistencies in RHEL6
Summary: Documentation inconsistencies in RHEL6
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Installation_Guide
Version: 6.2
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Jack Reed
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-11 21:54 UTC by David Hill
Modified: 2013-06-17 05:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-25 23:44:13 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Hill 2012-05-11 21:54:01 UTC 
Description of problem:
When Reading the migration guide about kickstart drive partitionning, it says (and I quote) "
Traditionally, disks have been referred to throughout Kickstart by a device node name (such as sda). The Linux kernel has moved to a more dynamic method where device names are not guaranteed to be consistent across reboots, so this can complicate usage in Kickstart scripts. To accomodate stable device naming, you can use any item from /dev/disk in place of a device node name. For example, instead of:
part / --fstype=ext4 --onpart=sda1

You could use an entry similar to one of the following:
part / --fstype=ext4 --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1
part / --fstype=ext4 --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1

This provides a consistent way to refer to disks that are more meaningful than just sda. This is especially useful in large storage environments.
"

But in the Installation guide, all the samples are using hda or sda... Would it be possible to also adress that issue in the Installation guide?

http://www.linuxtopia.org/online_books/rhel6/rhel_6_installation/rhel_6_installation_s1-kickstart2-options.html

http://www.linuxtopia.org/online_books/rhel6/rhel_6_migration_guide/rhel_6_migration_ch02s02s02.html

Also, in the kickstart phase, is there a way to figure out which disk will always be the first SCSI device?     I've been trying to have sda show as sdb in the kickstart and haven't succeeded yet.   How can we reproduce this issue?  It was a MUST in rhel5 because we could re-kickstart an old server with multipathed devices without having to disable the paths to the SAN... 

Version-Release number of selected component (if applicable):
All RHEL 6 docs

How reproducible:
It's in the doc


Steps to Reproduce:
1.Read the doc
2.
3.
  
Actual results:
Migration guide says one thing and Installation guide says some other things.


Expected results:
They should mutually agree... 

Additional info:
Well, contact me if you need more info.
Comment 2 David Hill 2012-05-11 23:16:49 UTC 
I know that on older hardware, sda would show as a cciss/c0d0 instead of sda... is the doc only meaning that?  Or a DVDROM could also be called sda?  Or even a multipath device? 

Thank you very much, 


Dave
Comment 3 Jack Reed 2012-05-15 01:48:41 UTC 
Hi David,

Thanks for reporting this inconsistency. We are wrapping up work on documentation for 6.3 though, so I'll have to defer work on this until 6.4.

Cheers,

Jack
Comment 4 Jack Reed 2012-06-07 06:30:42 UTC 
(In reply to comment #0)
> Also, in the kickstart phase, is there a way to figure out which disk will
> always be the first SCSI device?     I've been trying to have sda show as
> sdb in the kickstart and haven't succeeded yet.   How can we reproduce this
> issue?  It was a MUST in rhel5 because we could re-kickstart an old server
> with multipathed devices without having to disable the paths to the SAN... 

David, are you able to provide any insight on this? I can't find anything pertinent in the existing kickstart documentation in the Installation Guide.
Comment 5 David Hill 2012-06-07 14:39:33 UTC 
(In reply to comment #4)
> (In reply to comment #0)
> Also, in the kickstart phase, is there a way to
> figure out which disk will
> always be the first SCSI device?     I've been
> trying to have sda show as
> sdb in the kickstart and haven't succeeded yet.
> How can we reproduce this
> issue?  It was a MUST in rhel5 because we could
> re-kickstart an old server
> with multipathed devices without having to
> disable the paths to the SAN... 

David, are you able to provide any insight
> on this? I can't find anything pertinent in the existing kickstart
> documentation in the Installation Guide.

Traditionally, disks have been referred to throughout Kickstart by a device node name (such as sda). The Linux kernel has moved to a more dynamic method where device names are not guaranteed to be consistent across reboots, so this can complicate usage in Kickstart scripts. To accommodate stable device naming, you can use any item from /dev/disk in place of a device node name. For example, instead of: 
part / --fstype=ext4 --onpart=sda1
You could use an entry similar to one of the following: 
part / --fstype=ext4 --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1
part / --fstype=ext4 --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1
This provides a consistent way to refer to disks that is more meaningful than just sda. This is especially useful in large storage environments. 


But you can ignore my comment, I'm doing it with /dev/disk/ as mentionned in the documentation and it seems to work very well... :)  Just have to ignore the device if it's a CD ...
Comment 6 David Lehman 2012-06-07 16:40:12 UTC 
(In reply to comment #0)
> Also, in the kickstart phase, is there a way to figure out which disk will
> always be the first SCSI device?     I've been trying to have sda show as

If you always want the "first" disk, stick with "sda". If you use CCISS or other hardware that uses non-standard names, you'll need to write a %pre script to get a list of the disks, determine the first one (sda, cciss/c0d0, whatever else), and the dynamically generate your partitioning and include it via %include. For administrators with varying hardware and a requirement to identify the "first" disk, this is the only sure way to go.

> sdb in the kickstart and haven't succeeded yet.   How can we reproduce this

I don't follow. What do you mean by "have sda show as sdb in the kickstart"?
Comment 7 Jack Reed 2012-07-27 01:20:47 UTC 
Thanks, David. This should indeed be acknowledged in the kickstart options listing. Because the device node format appears in several places and has not been deprecated, explaining the /dev/disk alternative in each instance would be too cumbersome. Instead, I've done so in an Important admonition at the beginning of the Kickstart Options section, which adapts the explanation you've quoted in the Migration Guide. This will appear in the 6.4 edition of the guide.
Comment 11 Jack Reed 2013-02-25 23:44:13 UTC 
This bug has been verified and implemented for 6.4, so I am changing the status to CLOSED CURRENTRELEASE.
Note You need to log in before you can comment on or make changes to this bug.