MAAS is discovering USB drives - results on wiping the superblock on install
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Expired
|
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: 600605b00de0194
type: disk
wipe: superblock
- grub_device: true
id: sdb
model: LITEON CV3-8D128
name: sdb
ptable: gpt
serial: SD0L20505L2TH74
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-
wipe: superblock
- device: sdb
id: sdb-part1
name: sdb-part1
number: 1
offset: 4194304B
size: 511705088B
type: partition
uuid: 158568cb-
wipe: superblock
- device: sdb
id: sdb-part2
name: sdb-part2
number: 2
size: 127515230208B
type: partition
uuid: 380412c2-
wipe: superblock
- fstype: ext4
id: sda-part1_format
label: ''
type: format
uuid: eb7b6a14-
volume: sda-part1
- fstype: fat32
id: sdb-part1_format
label: ''
type: format
uuid: 74d4446b-
volume: sdb-part1
- fstype: ext4
id: sdb-part2_format
label: ''
type: format
uuid: aff06aca-
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_
Then I released the node and edited storage. Rather than completely removing the partition for /database_
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: 600605b00de0194
type: disk
wipe: superblock
- grub_device: true
id: sdb
model: LITEON CV3-8D128
name: sdb
ptable: gpt
serial: SD0L20505L2TH74
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-
wipe: superblock
- device: sdb
flag: boot
id: sdb-part1
name: sdb-part1
number: 1
offset: 4194304B
size: 536870912B
type: partition
uuid: 4d8f0082-
wipe: superblock
- device: sdb
id: sdb-part2
name: sdb-part2
number: 2
size: 127490064384B
type: partition
uuid: 1a518fdf-
wipe: superblock
- fstype: xfs
id: sda-part1_format
label: ''
type: format
uuid: a7d5a1c6-
volume: sda-part1
- fstype: fat32
id: sdb-part1_format
label: efi
type: format
uuid: 628eb728-
volume: sdb-part1
- fstype: ext4
id: sdb-part2_format
label: root
type: format
uuid: 4e5c4cb9-
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.
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 |
Changed in maas: | |
milestone: | 2.5.4 → none |
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?