[Maas-devel] Which disk is the root disk (Juju + MAAS)
Dann Frazier
dann.frazier at canonical.com
Wed Jul 30 18:26:53 UTC 2014
On Wed, Jul 30, 2014 at 9:06 AM, Mark Shuttleworth <mark at ubuntu.com> 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maas-devel
> More help : https://help.launchpad.net/ListHelp
>
More information about the Maas-devel
mailing list