7:49 p.m.
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
8:28 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
8:39 p.m.
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 "scsi disk" but instead a "xen virtual (block) device"
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________
cloud mailing list
cloud(a)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
2:28 a.m.
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(a)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(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
>
_______________________________________________
cloud mailing list
cloud(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
12:50 p.m.
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(a)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(a)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(a)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(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>
>>
> _______________________________________________
> cloud mailing list
> cloud(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
4845
days inactive
4845
days old
4 comments
3 participants
participants (3)
-
Brian LaMere -
David HM Spector -
Raphaël De GIUSTI