Can't use new dname on trusty deployed systems following renaming on maas UI

Bug #1591364 reported by Larry Michel
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
New
Undecided
Unassigned
curtin
Invalid
Undecided
Unassigned

Bug Description

I renamed sdi, sdj disks to sda and sdaa, and renamed sda disk to sdi in maas, but since curtin does not create a dname device that I can use, I am relying on /dev/sd<> name which won't work for our tests. They will be accessing disks sdb till the last available disk. So, the boot disk sdi will end up as designated storage.

From maas UI:
------------------------------------------------------------------------
Storage
Storage configuration cannot be modified unless the node is Ready or Allocated.
File systems

NameSizeMountpointFile system
sda-part1120.0 GB/ext4
Available disks and partitions

Name Model Serial BootSizeDevice TypeFile systemTags

sdaa
 120.0 GB Physical ssd sata

sdb
 500.1 GB Physical rotary removable

sdc
 500.1 GB Physical rotary removable

sdd
 500.1 GB Physical rotary removable

sde
 500.1 GB Physical rotary removable

sdf
 500.1 GB Physical rotary removable

sdg
 500.1 GB Physical rotary removable

sdh
 500.1 GB Physical rotary removable

sdi
 500.1 GB Physical rotary removable
------------------------------------------------------------------------

From system:

------------------------------------------------------------------------

ubuntu@janney:~$ ls /dev/sd*
/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdi1 /dev/sdj
ubuntu@janney:~$ sudo bash
root@janney:~# mount
/dev/sdi1 on / type ext4 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset,nsroot=/)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
ubuntu@janney:/dev/disk$ ls -l
total 0
drwxr-xr-x 2 root root 480 Jun 10 20:10 by-id
drwxr-xr-x 2 root root 200 Jun 10 20:10 by-path
drwxr-xr-x 2 root root 60 Jun 10 20:10 by-uuid
ubuntu@janney:/dev/disk$

------------------------------------------------------------------------

ubuntu@maas-integration-september:~$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-================================-================================-============-===============================================================================
ii maas 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server all-in-one metapackage
ii maas-cli 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS command line API tool
ii maas-cluster-controller 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server cluster controller
ii maas-common 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server common files
ii maas-dhcp 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS DHCP server
ii maas-dns 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS DNS server
ii maas-proxy 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS Caching Proxy
ii maas-region-controller 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server complete region controller
ii maas-region-controller-min 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS Server minimum region controller
ii python-django-maas 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server Django web framework
ii python-maas-client 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS python API client
ii python-maas-provisioningserver 1.9.3+bzr4577-0ubuntu1~trusty1 all MAAS server provisioning libraries
ubuntu@maas-integration-september:~$ dpkg -l '*curtin*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-================================-================================-============-===============================================================================
ii curtin 0.1.0~bzr385-0ubuntu1 all Library and tools for the curtin installer
ii curtin-common 0.1.0~bzr385-0ubuntu1 all Library and tools for curtin installer
ii python-curtin 0.1.0~bzr385-0ubuntu1 all Library and tools for curtin installer
ii python3-curtin 0.1.0~bzr385-0ubuntu1 all Library and tools for curtin installer
ubuntu@maas-integration-september:~$

Tags: oil
Revision history for this message
Ryan Harper (raharper) wrote :

There's no such thing as "rename" a block device in curtin.

Changed in curtin:
status: New → Invalid
Larry Michel (lmic)
summary: - disks not renamed on deployed systems following renaming on maas UI
+ Can't use new dname on deployed systems following renaming on maas UI
summary: - Can't use new dname on deployed systems following renaming on maas UI
+ Can't use new dname on trusty deployed systems following renaming on
+ maas UI
Revision history for this message
Larry Michel (lmic) wrote :

Updating description to clarify real issue and duping this to 1523037 per conversation with Ryan.

description: updated
Revision history for this message
Blake Rouse (blake-rouse) wrote :

Larry check the API for the path of these disks. In MAAS no where does it say changing the disk name with rename it under dev. Changing the name changes it at /dev/disk/by-dname/... Check that path those disks should be there. You should use that path if you want to refer to a disk by its name in MAAS. The kernel does not allow you to rename disk names.

Revision history for this message
Larry Michel (lmic) wrote :

Blake, Thanks for clarifying further. I agree.. I was looking at the wrong path initially. Our code is actually using /dev/disk/by-dname and will look at /dev/sdX only when that fails. Unfortunately, trusty is currently not setting /dev/disk/by-dname which is why I duped the bug after consulting with Ryan.

On the system in question that directory was not there:

ubuntu@janney:/dev/disk$ ls -l
total 0
drwxr-xr-x 2 root root 480 Jun 10 20:10 by-id
drwxr-xr-x 2 root root 200 Jun 10 20:10 by-path
drwxr-xr-x 2 root root 60 Jun 10 20:10 by-uuid

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.