Report busy partitions; disable MD and LVM auto-activation

[bgilbert]

Ensure leftover MD and LVM partitions on the target disk are not automatically activated if install kargs are used, so they don't prevent the installer from gaining exclusive access to the disk.

Also extend the installer to report a list of busy partitions as a debugging aid. Example output:

Installing Fedora CoreOS 32.20200601.3.0 x86_64 (512-byte sectors)
Partitions in use on /dev/sda:
    /dev/sda1 mounted on /var/mnt
    /dev/sda4 is swap device
    /dev/sda6 in use by /dev/dm-0
    /dev/sda8 in use by /dev/md127
Error: checking for exclusive access to /dev/sda
Caused by: couldn't reread partition table: device is in use
Caused by: EBUSY: Device or resource busy

Fixes #261.

[cgwalters]

This will only work for users that install via the kernel arguments...which is probably OK but we also want to support (if not emphasize) running coreos-installer via custom systemd units instead (possibly wrapped with other units before/after etc.) right?

Clearly an admin could inject those config fragments via Ignition...so maybe they'd end up in our documentation?

Can LVM be suppressed by systemd units instead? That's probably simpler if so.

I'd assume MD can be suppressed by a kernel argument too?

[bgilbert]

You're right that this doesn't work for custom coreos-installer units. Would it make sense to supply a custom target (coreos-installer-pre.target) that the custom unit could Require+After?

There's no karg to suppress MD assembly in the real root. For LVM, it might be sufficient to mask or override [email protected], but I'm not sure that's cleaner.

[cgwalters]

Probably the cleanest but also the hardest fix would be to have coreos-installer install --auto-teardown or so which would look for any LVM/MD/etc devices which have have the target disk as a member.

Wait actually, wouldn't it work to just wipefs -a the target disk and then wait for a udevadm settle cycle? (I assume this would work for kernel MD, LVM less sure)

[jlebon]

Hmm, I'm wary of trying to make coreos-installer that smart. At best, I agree with #276 (comment) that this should probably be a switch. And then we should be more targeted about it, e.g.: if the user provides the switch, then de-activate all the layers which are directly in the mount hierarchy for the target device. This is harder to do though.

I think the new "Partitions in use" error message is a great improvement and might even be enough to guide users on what they need to do.

[bgilbert]

Probably the cleanest but also the hardest fix would be to have coreos-installer install --auto-teardown or so which would look for any LVM/MD/etc devices which have have the target disk as a member.

That feels odd to me. If run from the command line, I think it's the user's job to give us a disk that's not currently in use, and if it is, they're in the best position to correct that. And if run automatically by the operating system, it's the OS' job to not automatically start using parts of the target disk. That view might be controversial though.

Wait actually, wouldn't it work to just wipefs -a the target disk and then wait for a udevadm settle cycle? (I assume this would work for kernel MD, LVM less sure)

We can't wipe any data we're not actually going to overwrite; see #172.

I think the new "Partitions in use" error message is a great improvement and might even be enough to guide users on what they need to do.

Yeah, I'm in favor of making the incremental improvement and seeing where that gets us.

[bgilbert]

Updated. I've added coreos-installer-pre.target, and we can document that custom installer units should Require/After it.

[jlebon]

Makes sense to me! One comment, LGTM otherwise.

[blueskyjunkie]

The problem this fixes seems to still exist?

#261 (comment)