Comment 11 for bug 1676991

Ryan,

Thanks, I've commented on it with the information I dug up.

We need a reliable way to identify a given bcache device even without a
file system or GPT present on it. I think this will require either kernel
modifications or very clever udev rules to make sure Juju storage usable
(or, in other words that MAAS tags will refer to bcache device names
actually used on a target system).

On 30 Oct 2017 7:01 pm, "Ryan Harper" <email address hidden> wrote:

@dmitriis

It appears that we have an addition bug in the dname of bcache devices.

I've filed a bug:

https://bugs.launchpad.net/curtin/+bug/1728742

To track fixing dname links for bcache devices.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1676991

Title:
  bcache mounts inconsistent after node reboots

Status in OpenStack Charm Test Infra:
  Fix Released
Status in curtin:
  Fix Released
Status in MAAS:
  Invalid

Bug description:
  On MAAS-deployed nodes with bcache-fronted disks, the bcache device
  names and mount points can move about after reboots, causing systems
  to not boot, and/or cause system outage and/or risk of data loss.

  Perhaps a disk ID or label should be used to ensure the intended
  device is brought up on the intended mount point?

  ubuntu@mutus:/var/lib/lxd⟫ cat /etc/fstab
  # The following two lines are the original values as-deployed by maas
  #/dev/bcache1 / ext4 defaults 0 0
  #/dev/bcache0 /srv ext4 defaults 0 0
  #
  # After a reboot, the root and srv partitions inverted. I had to edit
  # fstab for things to work again. The following two lines became
necessary:
  /dev/bcache0 / ext4 defaults 0 0
  /dev/bcache1 /srv ext4 defaults 0 0
  #
  UUID=3793a969-b311-4e8b-8332-06513407aeed /boot ext4 defaults 0 0
  UUID=186E-7F1F /boot/efi vfat defaults 0 0
  /swap.img none swap sw 0 0

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-test-infra/+bug/1676991/+subscriptions