Description of problem: Using a device designation of sdaa as a device name inside the guest results in a corrupted device name ie /dev/sd{ Version-Release number of selected component (if applicable): RHEL5.1 & RHEL5.2 beta for guest and/or dom0 How reproducible: Add an additional device into the guest configuration using 'sdaa' as the device name inside the guest and list the devices available inside the guest after the guest has been booted Steps to Reproduce: 1. Add an additional device to the guest config file to use sdaa as the device name inside the guest ie "tap:aio:/dev/sdaa,sdaa,w" 2. Boot the guest 3. List the devices available inside the guest ie # fdisk -l [...] Disk /dev/sd{: 34.3 GB, 34367078400 bytes 255 heads, 63 sectors/track, 4178 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sd{ doesn't contain a valid partition table Actual results: A device such as /dev/sd{ is displayed Expected results: A usable device such as /dev/sdaa should be available Additional info: Inside the guest : [root@dhcp78-171 ~]# cat /proc/partitions major minor #blocks name 202 0 6291456 xvda 202 1 104391 xvda1 202 2 6185025 xvda2 65 160 33561600 sd{ 253 0 4128768 dm-0 253 1 2031616 dm-1 guest configuration file : [root@woodie xen]# cat rhel52x86_64 name = "rhel52x86_64" uuid = "3210e2ff-c6cb-92c9-8caa-17c76161c78a" maxmem = 1024 memory = 1024 vcpus = 2 bootloader = "/usr/bin/pygrub" kernel = "/var/lib/xen/boot_kernel.yyggf6" ramdisk = "/var/lib/xen/boot_ramdisk.tjJArL" extra = "ro root=/dev/VolGroup00/LogVol00 rhgb quiet" on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" vfb = [ "type=vnc,vncdisplay=2" ] disk = [ "tap:aio:/var/lib/xen/images/rhel52x86_64.vbd,xvda,w", "tap:aio:/dev/sdaa,sdaa,w"] vif = [ "mac=00:16:3e:1a:e4:ac,bridge=xenbr0,script=vif-bridge" ] From xenstore-ls on dom0 16800 = "" domain = "rhel52x86_64" frontend = "/local/domain/27/device/vbd/16800" dev = "sdaa" state = "4" params = "aio:/dev/sdaa" mode = "w" online = "1" frontend-id = "27" type = "tap" sectors = "67123200" sector-size = "512" info = "0" hotplug-status = "connected"
I'll assign this one to myself for now, since I'm going to fix it as part of BZ 442723. I might close it later as a dup, but that's not exactly right so I'll leave it open for the time being. Chris Lalancette
Note that this was fixed in upstream xen-unstable changeset 12314; I'll end up backporting that to RHEL-5 as part of BZ 442723. Chris Lalancette
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.
Created attachment 312448 [details] Patch to expand the printing of devices (scsi and xvd) in blkfront
in kernel-2.6.18-104.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
This bug has been marked for inclusion in the Red Hat Enterprise Linux 5.3 Release Notes. To aid in the development of relevant and accurate release notes, please fill out the "Release Notes" field above with the following 4 pieces of information: Cause: What actions or circumstances cause this bug to present. Consequence: What happens when the bug presents. Fix: What was done to fix the bug. Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When attaching a disk named sdaa to a paravirtualized guest, the name of the disk would come up as /dev/sd}, instead of the expected /dev/sdaa. This was due to a flaw in the way the paravirtualized frontend named the disk. This is now fixed so that attaching a disk /dev/sdaa shows up as /dev/sdaa in the paravirtualized guest.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1 @@ -When attaching a disk named sdaa to a paravirtualized guest, the name of the disk would come up as /dev/sd}, instead of the expected /dev/sdaa. This was due to a flaw in the way the paravirtualized frontend named the disk. +When a disk named /dev/sdaa disk was attached to the paravirtualized guest, it would be incorrectly renamed to /dev/sd. In this update, this issue has been resolved.- -This is now fixed so that attaching a disk /dev/sdaa shows up as /dev/sdaa in the paravirtualized guest.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -When a disk named /dev/sdaa disk was attached to the paravirtualized guest, it would be incorrectly renamed to /dev/sd. In this update, this issue has been resolved.+When a disk named /dev/sdaa (or bigger) was attached to a paravirtualized guest, the name would be corrupted inside the guest. In this update, this issue has been resolved.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -When a disk named /dev/sdaa (or bigger) was attached to a paravirtualized guest, the name would be corrupted inside the guest. In this update, this issue has been resolved.+Trying to attach a disk named /dev/sdaa, /dev/sdab, etc. to a paravirtualized guest would result in a corrupted /dev device inside the guest. This update resolves the issue so that attaching /dev/sdaa to a paravirtualized guest creates the proper /dev device inside the guest.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Trying to attach a disk named /dev/sdaa, /dev/sdab, etc. to a paravirtualized guest would result in a corrupted /dev device inside the guest. This update resolves the issue so that attaching /dev/sdaa to a paravirtualized guest creates the proper /dev device inside the guest.+Attaching a disk with a specific name (ie. /dev/sdaa, /dev/sdab, /dev/sdbc etc.) to a paravirtualized guest resulted in a corrupted /dev device inside the guest. This update resolves the issue so that attaching disks with these names to a paravirtualized guest creates the proper /dev device inside the guest.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Attaching a disk with a specific name (ie. /dev/sdaa, /dev/sdab, /dev/sdbc etc.) to a paravirtualized guest resulted in a corrupted /dev device inside the guest. This update resolves the issue so that attaching disks with these names to a paravirtualized guest creates the proper /dev device inside the guest.+Attaching a disk with a specific name (ie. /dev/xvdaa, /dev/xvdab, /dev/xvdbc etc.) to a paravirtualized guest resulted in a corrupted /dev device inside the guest. This update resolves the issue so that attaching disks with these names to a paravirtualized guest creates the proper /dev device inside the guest.
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 therefore 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-2009-0118.html