maas-devel team mailing list archive

[Dann Frazier <dann.frazier@xxxxxxxxxxxxx>]

On Wed, Jul 30, 2014 at 9:06 AM, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
> On 30/07/14 15:56, Scott Moser wrote:
>> curtin probably did install to what it thought was the first disk.  2
>> things then are possible from there:
>>  a.) disks came up in a different order on reboot, but the LABEL=
>>      successfully did find the root disk, which is good.
>>  b.) disks came up in the same order, but existing LABEL of
>>      cloudimg-rootfs and *its* undefined order made root be /dev/sdb.
>>      I dont suspect this, though as it would have resulted in bad juju
>>      user-data, and probably fail to boot.
>>
>> So it surely would have seemed like 'a'.  I'm not sure exactly what we can
>> do about that.
>>
>> There are definitely ways of finding devices by a more consistent path.
>> Ie, you can use /dev/disk/by-lable or /dev/disk/by-uuid, but i don't know
>> that you can easily guarantee that a given block device (possibly by its
>> path) will be /dev/sda and another will be /dev/sdb.
>
> Is there no equivalent to /etc/udev/rules.d/70-persistent-net.rules for
> disks?

I think /dev/disk/by-{label,uuid} is a sufficient equivalent. Network
interfaces require a udev rule to do a kernel level rename because the
user needs to know the name to manipulate them. Since block devices
have nodes in the VFS, we have the option of using the by-foo symlinks
(also managed by udev rules) to reference them by properties.

 -dann

>> Certainly the charm can be made more generic to find an "empty" device
>> rather than picking /dev/sdb.
>
> Right, because in some cases the system might well have been placed on
> sdb deliberately.
>
> Mark
>
>
> --
> Mailing list: https://launchpad.net/~maas-devel
> Post to     : maas-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maas-devel
> More help   : https://help.launchpad.net/ListHelp
>