sd devices on FC14 AMI not valid?

[Brian LaMere]

Yeah, I don't think I'd do symlinks, as you could potentially run in to
issues; one could also just use mknod to make another block device pointer
as Raphaël is suggesting.  I'm sure there's a place somewhere to do that
cleaner than mknod, too - maybe xen_blkfront even already understands
changing the naming?  I don't see such in the older xen_blkfront.c code, but
hey...who knows.

If I recall correctly, rightscale used to assume you were using their AMIs -
maybe those AMIs saw the devices incorrectly, as /dev/sd*? So if you're not
using their AMI, then something they aren't expecting is happening.  But
yes, they most certainly should understand devices other than just sd* - so
a patch is the best bet :)

2011/2/10 Raphaël De GIUSTI <raphael.degiusti at guardis.com>

> As far as I know, the device name could be anything, as long as the device
> is associated with the right minor and major number. The symlink is
> not necessarily ugly, but the patch solution is better imo.
>
>
> On Thu, Feb 10, 2011 at 3:39 AM, David HM Spector <spector at zeitgeist.com>wrote:
>
>> Iiinteresting.   Seems like the rightscale AWS gem (which I am using in my
>> scripts to actually do the attach of the EBS volume) doesn't like xvd device
>> entries.. however symlinking the sd device name to the real xen one allows
>> it to work (ugly, yes... but it works)...   will have to look into that and
>> submit a patch if its really broken.
>>
>> thanks much for your help - it got me where I needed to be
>>
>> cheers,
>>    David
>>
>> On Feb 9, 2011, at 6:28 PM, Brian LaMere wrote:
>>
>> replace "sd" with "xvd" and you'll be set.  It's not a "*s*csi *d*isk"
>> but instead a "*x*en *v*irtual (block) *d*evice"
>>
>> On older AKIs, sometimes one would see drives presented to the OS as
>> /dev/sd* still, but it seems like since pvgrub this is no longer the case.
>>  It's more "honest" this way regardless; the kernel is seeing it (or at
>> least, presenting it) more accurately for what it is.  It never should have
>> listed those drives as /dev/sd*
>>
>> So...point is...it's not supposed to be /dev/sd* - just like it wasn't
>> /dev/sd* when you used old IDE drives (those were /dev/hd*).  Almost all
>> kernels have built-in support for IDE and SCSI, but not for Xen; that's
>> loaded as a module, instead.  If you do an "lsmod" you should see a loaded
>> module named xen_blkfront - note also that it has a "used by" value that is
>> the same as the number of (valid...) /dev/xvd* block devices.
>>
>> See http://lxr.free-electrons.com/source/drivers/block/xen-blkfront.c for
>> info about that module...
>>
>> Does that answer the question?  Disregard what Amazon says you should see
>> the device reporting as - it should be xvd*, not sd*.  It's not using the
>> scsi driver.
>>
>> Brian
>>
>> On Wed, Feb 9, 2011 at 5:49 PM, David HM Spector <spector at zeitgeist.com>wrote:
>>
>>> I am trying to get an attached EBS volume to mount on a customized (ots
>>> of php and rails packages) version of the FC14 AMI.
>>> It seems the sd devices aren't made by default; but even once they're
>>> made, mount refuses to mount the volume
>>> saying " /dev/sdf is not a valid block device"   Its a an ext3 filesystem
>>> so nothing novel there.
>>>
>>> Everything works fine on my older instances with the same scripts; I can
>>> get he EBS volume to attach to the instance (I have
>>> some custom ruby scripts that work at startup to attach vol ids passed as
>>> user data) and the perms/maj/min device numbers
>>> look OK too (as one would expect from MAKEDEV).
>>>
>>>  Anything obvious I am missing?
>>>
>>>
>>> tnx,
>>>   David
>>>
>>> ----------------------------------------------------------------------------------------------
>>>                                            David HM Spector
>>> spector at zeitgeist dot com
>>> http://www.zeitgeist.com
>>>                                                     ~ ~ ~
>>> "New and stirring things are belittled because if they are not belittled,
>>> the
>>> humiliating question arises, 'Why then are you not taking part in them?'"
>>>
>>>               --H. G. Wells
>>>
>>>
>>> _______________________________________________
>>> cloud mailing list
>>> cloud at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>
>>>
>> _______________________________________________
>> cloud mailing list
>> cloud at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>
>>
>>
>> ----------------------------------------------------------------------------------------------
>>
>>                                           David HM Spector
>>
>> spector at zeitgeist dot com
>> http://www.zeitgeist.com
>>
>>                                                     ~ ~ ~
>>
>> "New and stirring things are belittled because if they are not belittled,
>> the
>>
>> humiliating question arises, 'Why then are you not taking part in them?'"
>>
>>
>>             --H. G. Wells
>>
>>
>> _______________________________________________
>> cloud mailing list
>> cloud at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>
>>
>
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20110210/04ba0c24/attachment.html>