MAAS sometimes attempts to install to USB flash drive

[Rod Smith]

On occasion, MAAS will attempt to install to a USB flash drive if one is inserted in a server prior to Starting it. This happens if the USB drive happens to be enumerated before the internal hard disk or RAID array. This attempt is likely to fail and the result is that the server will reboot and fail to start or start up in a previously-installed OS. The obvious solution, of course, is to remove the USB flash drive from the computer; but this may not be possible if the computer is remote. More "smarts" on the part of the installer to prevent this problem is desirable.

[Gavin Panella (allenap)]

Embedding heuristics like this into MAAS is problematic, and will be difficult to maintain as time goes on.

For example, installing to a USB drive instead of a fixed HD sounds like it might be desirable to some people. On the other hand it might also be be a bug in the installer. Then the installer maintainer might argue that it's not a bug, or that it's actually a bug in how the kernel enumerates hardware.

There are probably a thousand other heuristics we _could_ add to MAAS, all in the name of making it Just Work. However, one person's preferred choice is another's bad choice, and in adding an extra layer of behaviour we're also making it harder for users and maintainers alike to reason about how MAAS will behave in a given situation.

For MAAS, my instinct here is to guide users to fix their own problems. Low tech, like having a process which includes removing USB drives before use with MAAS, or higher tech like customising the installer scripts to avoid installing to USB drives. The latter is, I suspect, possible today; documentation or a recipe to work from would be ways to improve the situation.

My other instinct would be to do as hinted at above: report the issue for the installer. MAAS uses d-i and curtin, the latter for fast installs.

[Rod Smith (rodsmith)]

I understand the difficulty of determining what's best, but some cases are pretty obvious. An attempt to install to a 2GB USB drive when a 1TB hard disk is available, for instance, is doomed to failure.

[Jeff Lane  (bladernr)]

I'd be more inclined to call this an installer bug, however, MAAS should not be doing FPI to the wrong place as well.

But in general, d-i has issues installing to the correct drive, by default, all ubuntu installs go to "/dev/sda" and /dev/sda is not always the onboard HDD, it really depends on what is presented to the OS as a disk first.

We saw this a LOT when doing automated SRU testing on laptops where the desktop installer and d-i would both, on some machines, install to the USB stick rather than the onboard HDD.

In fact, I did this just the other day with a 4GB USB STick and my own maas setup.

So there really should still be a d-i bug for this as well, but we do think it would be good to ensure that MAAS is a little smarter, or at least a little more configurable about where it installs.

MAAS knows what disks are present, it should be getting that data during commissioning. So really it could be a matter of editing the node and choosing:

[ ] /dev/sda ADATA Flash Drive 8GB
[*] /dev/sdb Western Digital ST01428927 500GB

which would tell MAAS either where to lay down the fast path image, or edit d-i preseed accordingly for partitioning

[Scott Moser (smoser)]

Roderick,
 fwiw, its not terribly obvious that the 2GB disk is "wrong".
  Why would you want your root disk of your OS to be the big one?
  instead, use the small one that is sufficient, and put all your data on the big one.

[Rod Smith (rodsmith)]

The official Ubuntu system requirements include 5GB of disk space (https://help.ubuntu.com/community/Installation/SystemRequirements), so installing to a 2GB disk is just plain wrong.

This bug report was just bumped in priority because it's similar to problems being experienced with other configurations with more exotic storage devices. Others should be posting their comments about that, or perhaps filing new bug reports.

[Scott Moser (smoser)]

Roderick,
  To quote the page you referenced:

| Ubuntu Server (CLI) Installation
| 300 MHz x86 processor
| 192 MiB of system memory (RAM)
| 1 GB of disk space
| Graphics card and monitor capable of 640x480
| CD drive

1GB for server. so 2GB is *twice* the *recommended* (not required) amount.

The point is that determining which disk is "right" is more about how the system will be used than anything else. Curtin allows the user via config to specify the drives (by device name) that are considered for installation. Admittedly, its not very dynamic, and requires knowledge of the how the system you're installing on, but simply:
partitioning_commands:
  builtin: curtin block-meta --device=/dev/sdb simple

That overrides the 'builtin' partitioning command (which is 'block-meta simple'). You can accomplish that through maas vi editing the configs that it sends to curtin.

My argument boils down to this:
 The user is who knows what "the right" configuration is. Curtin did automatically choose a valid configuration. Coding a long list of hueristics to determine what the user wants is not ever going to satisfy all use case.

[Gavin Panella (allenap)]

Something we want to add to MAAS is the idea of recommissioning, i.e. when a node is released back to MAAS, it runs a cycle that does a bunch of things to get the machine ready to go out the door again. For example, reset BIOS settings, erase disks. Like commissioning, a MAAS admin would be able to configure their own scripts to run.

With the existing commissioning stage and a new commissioning stage, we'd have an opportunity to run a site-specific "find me the disk on which to put the OS" script. This could set a pre-agreed disk label, e.g. "OS" or "ROOT", that curtin could be modified to take notice of.

More flexible than that is for curtin to grow the capability to run a site-specific "fine me the disk" script directly, but that would entail more work in MAAS to support it.

[Scott Moser (smoser)]

The feature that I would like in maas to address this is the ability for the user to provide "installer config" (in addition to user-data). This installer config would be passed wholesale through maas to curtin (or d-i). .

This would allow either
a.) the user to provide curtin-config without modifying maas templates (since they can't change those unles they're admin)
b.) juju to provide curtin-config to set a certain layout of disks for its known use case.