MAAS is discovering USB drives - results on wiping the superblock on install

Bug #1807459 reported by Jeff Lane on 2018-12-07
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Undecided
Unassigned

Bug Description

We have a machine connected to a MAAS server that has two USB drives attached to it. When the machine was recommissioned, MAAS picked up those two USB drives. That was OK. We did not tell MAAS to do ANYTHING with those drives, they just needed to be there for testing purposes, but they could be there for any reason. They could be data storage volumes, for instance.

The curtin config being passed to the machine on deployment is telling the installer to wipe the superblocks of those drives despite the fact we did NOT tell MAAS to wipe every disk. This destroys the disk and forces us to manually re-partition and format those USB drives. This is what is being provided via curtin to the installer:

storage:
  config:
  - id: sda
    model: RAID 530-8i
    name: sda
    ptable: gpt
    serial: 600605b00de01940239895626ec41d96
    type: disk
    wipe: superblock
  - grub_device: true
    id: sdb
    model: LITEON CV3-8D128
    name: sdb
    ptable: gpt
    serial: SD0L20505L2TH741002W
    type: disk
    wipe: superblock
  - id: sdc
    model: USB Flash Drive
    name: sdc
    serial: 15109234401100DF
    type: disk
    wipe: superblock
  - id: sdd
    model: MKNUFDPR2GB
    name: sdd
    serial: 07C104030AB7071F
    type: disk
    wipe: superblock
  - device: sda
    id: sda-part1
    name: sda-part1
    number: 1
    offset: 4194304B
    size: 597990309888B
    type: partition
    uuid: 4cea3b5d-f95b-451d-97d7-58901c79e06c
    wipe: superblock
  - device: sdb
    id: sdb-part1
    name: sdb-part1
    number: 1
    offset: 4194304B
    size: 511705088B
    type: partition
    uuid: 158568cb-6227-47a8-a803-303e4bacef4f
    wipe: superblock
  - device: sdb
    id: sdb-part2
    name: sdb-part2
    number: 2
    size: 127515230208B
    type: partition
    uuid: 380412c2-dead-4246-9b5e-86c342459a44
    wipe: superblock
  - fstype: ext4
    id: sda-part1_format
    label: ''
    type: format
    uuid: eb7b6a14-f3c1-4575-9599-412908d3cf83
    volume: sda-part1
  - fstype: fat32
    id: sdb-part1_format
    label: ''
    type: format
    uuid: 74d4446b-1b8e-4fde-b9b4-a47bab0a2237
    volume: sdb-part1
  - fstype: ext4
    id: sdb-part2_format
    label: ''
    type: format
    uuid: aff06aca-bb36-4d18-b306-9246d1834d72
    volume: sdb-part2
  - device: sdb-part2_format
    id: sdb-part2_mount
    options: ''
    path: /
    type: mount
  - device: sdb-part1_format
    id: sdb-part1_mount
    options: ''
    path: /boot/efi
    type: mount
  - device: sda-part1_format
    id: sda-part1_mount
    options: ''
    path: /data1
    type: mount
  version: 1

When deploying via MAAS, deployments should not be wiping superblocks or any data without being explicitly told to, either by using the Erase Disk feature on releasing a deployed node, or when MAAS is told explicitly to partition and mount a given disk. IMO, it should never touch a disk it has not been directly told to act on.

Alternatively, perhaps there needs to be a "These aren't the drives you're looking for" flag for each storage device that tells MAAS/curtin to completely ignore that disk. Don't touch it, don't wipe it, don't mount it.

I tried this with a RAID volume as well. Deployed with a RAID volume mounted as "/database_do_not_delete_me". and created a 10GB file called "im_a_database"

Then I released the node and edited storage. Rather than completely removing the partition for /database_do_not_delete_me, I simply "unmounted" it, leaving an XFS formatted partition.

At this point, my database partition now appears in the "available disks section":
Available disks and partitions

sda-part1 598.0 GB Partition xfs
sdc 15.5 GB Physical rotary removable Unknown
sdd 2.0 GB Physical rotary removable Unknown

Next, I chose to re-deploy, with only this for telling MAAS how to deploy my node:

Filesystems
Name Size Filesystem Mount point Mount options
sdb-part1 536.9 MB fat32 /boot/efi
sdb-part2 127.5 GB ext4 /

Because I exepect to be able to remount my data partition manually and resume normal operation now that I have wiped and replaced my operating system.

when I checked what curtin was telling the node to do for storage,
storage:
  config:
  - id: sda
    model: RAID 530-8i
    name: sda
    ptable: gpt
    serial: 600605b00de01940239895626ec41d96
    type: disk
    wipe: superblock
  - grub_device: true
    id: sdb
    model: LITEON CV3-8D128
    name: sdb
    ptable: gpt
    serial: SD0L20505L2TH741002W
    type: disk
    wipe: superblock
  - id: sdc
    model: USB Flash Drive
    name: sdc
    serial: 15109234401100DF
    type: disk
    wipe: superblock
  - id: sdd
    model: MKNUFDPR2GB
    name: sdd
    serial: 07C104030AB7071F
    type: disk
    wipe: superblock
  - device: sda
    id: sda-part1
    name: sda-part1
    number: 1
    offset: 4194304B
    size: 597990309888B
    type: partition
    uuid: aca447c5-968a-409c-826c-f6fc2eead2c9
    wipe: superblock
  - device: sdb
    flag: boot
    id: sdb-part1
    name: sdb-part1
    number: 1
    offset: 4194304B
    size: 536870912B
    type: partition
    uuid: 4d8f0082-6ba7-433a-b7da-cba12b0e2dbe
    wipe: superblock
  - device: sdb
    id: sdb-part2
    name: sdb-part2
    number: 2
    size: 127490064384B
    type: partition
    uuid: 1a518fdf-4fbd-4395-a372-7634de8f51e2
    wipe: superblock
  - fstype: xfs
    id: sda-part1_format
    label: ''
    type: format
    uuid: a7d5a1c6-999a-4daa-b80b-ca3c27d16067
    volume: sda-part1
  - fstype: fat32
    id: sdb-part1_format
    label: efi
    type: format
    uuid: 628eb728-b58c-4b31-850d-98de891f997e
    volume: sdb-part1
  - fstype: ext4
    id: sdb-part2_format
    label: root
    type: format
    uuid: 4e5c4cb9-db7f-467c-9024-165e74b56d6f
    volume: sdb-part2
  - device: sdb-part2_format
    id: sdb-part2_mount
    path: /
    type: mount
  - device: sdb-part1_format
    id: sdb-part1_mount
    path: /boot/efi
    type: mount

so despite me simply "unmounting" this partition and MAAS clearly showing me that it's an available XFS partition in the "Available Disks and Partitions" section, MAAS actually re-formats the partition I explicitly did NOT include in the section of "used" partitions, because I wanted to retain that partition and it's data to remount later.

Point is, if I simply "unmount" a partition, then that is exactly what should happen, it should NOT be wiped and reformatted. Now, if I completely remove the partition, then by all means, wipe it. Or if I click the "erase disk" option when releasing the machine. But otherwise, my unused partitions should not be touched, leaving their filesystems and data intact. And of course if I have deleted the partition and then recreated it, I'd expect it to be completely wiped and created anew.

Andres Rodriguez (andreserl) wrote :

MAAS will continue to wipe the superblock of all available disk. That won’t vhange. That’s fine by design and to ensure MAAS can always deploy a machine. Otherwise, you could have grub installed on other devices and prevent machines from successfully deploying or booting in other installations on other disks.

Remember than the point of Maas is to reuse machines as a cloud and as such, it won’t give you a machine with data from someone else in a different disk. You escenario is not supported and there is no business case for it.

That said, what I’m not certain about is usb sticks. IIRC we deliberality started ignoring usb sticks and sd cards during commissioning to not be mistaken with machine storage.

Can you provide your commissioning output for storage?

Changed in maas:
status: New → Incomplete
Andres Rodriguez (andreserl) wrote :

Also, you haven't specified the MAAS version, nor the version used for commissioning.

summary: - maas automatically wiping usb dries without us telling it to
+ MAAS is discovering USB drives - results on wiping the superblock on
+ install
Jeff Lane (bladernr) wrote :

That's fair enough. In reality, I was a bit too general in the summary, when I said "disk" in relation to not touching them, what I meant was "usb or removable" disks, not onboard devices. I completely understand why we'd want to wipe onboard disks. And from your comments, it appears that this may actually be unintended behaviour in wiping my USB sticks.

Here's the log from the storage step of commissioning. Note sdc and sdd are the USB sticks and definitely appear on the USB bus. IN the MAAS storage tab on the machine page, however, they're being tagged as "rotary" and "removable", I thought there was a different tag for USB storage.

Additionally, this is currently at 2.4.2 (7034-g2f5deb8b8-0ubuntu1), this is a production machine so we're only using stable on this server. Commissioning is set to use 18.04 with no minimum kernel specified.

[

 {

  "NAME": "sda",

  "RO": "0",

  "RM": "0",

  "MODEL": "RAID 530-8i",

  "ROTA": "1",

  "MAJ:MIN": "8:0",

  "PATH": "/dev/sda",

  "DEVPATH": "/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/host2/target2:2:0/2:2:0:0/block/sda",

  "FIRMWARE_VERSION": "5.02",

  "SERIAL": "600605b00de01940239895626ec41d96",

  "ID_PATH": "/dev/disk/by-id/wwn-0x600605b00de01940239895626ec41d96",

  "SIZE": "597998698496",

  "BLOCK_SIZE": "4096"

 },

 {

  "NAME": "sdb",

  "RO": "0",

  "RM": "0",

  "MODEL": "LITEON CV3-8D128",

  "ROTA": "0",

  "MAJ:MIN": "8:16",

  "PATH": "/dev/sdb",

  "DEVPATH": "/devices/pci0000:00/0000:00:1c.6/0000:03:00.0/ata9/host11/target11:0:0/11:0:0:0/block/sdb",

  "RPM": "0",

  "SATA": "1",

  "FIRMWARE_VERSION": "T87RA33",

  "SERIAL": "SD0L20505L2TH741002W",

  "ID_PATH": "/dev/disk/by-id/ata-LITEON_CV3-8D128_00LF428_0L20505LEN_SD0L20505L2TH741002W",

  "SIZE": "128035676160",

  "BLOCK_SIZE": "4096"

 },

 {

  "NAME": "sdc",

  "RO": "0",

  "RM": "1",

  "MODEL": "USB Flash Drive",

  "ROTA": "1",

  "MAJ:MIN": "8:32",

  "PATH": "/dev/sdc",

  "DEVPATH": "/devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/host0/target0:0:0/0:0:0:0/block/sdc",

  "FIRMWARE_VERSION": "0.00",

  "SERIAL": "15109234401100DF",

  "ID_PATH": "/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_15109234401100DF-0:0",

  "SIZE": "15536226304",

  "BLOCK_SIZE": "4096"

 },

 {

  "NAME": "sdd",

  "RO": "0",

  "RM": "1",

  "MODEL": "MKNUFDPR2GB",

  "ROTA": "1",

  "MAJ:MIN": "8:48",

  "PATH": "/dev/sdd",

  "DEVPATH": "/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/host1/target1:0:0/1:0:0:0/block/sdd",

  "FIRMWARE_VERSION": "PMAP",

  "SERIAL": "07C104030AB7071F",

  "ID_PATH": "/dev/disk/by-id/usb-MUSHKIN_MKNUFDPR2GB_07C104030AB7071F-0:0",

  "SIZE": "2002780160",

  "BLOCK_SIZE": "4096"

 }

]

Changed in maas:
milestone: none → 2.5.1
Changed in maas:
milestone: 2.5.1 → 2.5.2
tags: added: storage
Changed in maas:
milestone: 2.5.2 → 2.5.3
Changed in maas:
milestone: 2.5.3 → 2.5.4
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers