blockdev: use 'kpartx' for reading/clearing partition table of dm-devices

[nikita-dubrovskii]

When installing CoreOS on DM device, such as '/dev/mapper/mpatha' or '/dev/dm-0',
regular 'ioctl(fd, BLKRRPART)' call always fails with EINVAL. This also means,
that our check for device being mounted, which on regular devices fails with EBUSY,
is not valid anymore, that's why now /proc/mounts is used.

Signed-off-by: Nikita Dubrovskii [email protected]

[bgilbert]

Related: #91

We generally try to minimize dependencies on external programs, so coreos-installer intentionally doesn't do this. The current situation could use improvement though. I guess we could avoid the external dependency by parsing the partition table and issuing the ioctls ourselves, but that seems a bit painful.

[bgilbert]

I realized I was thinking of partprobe, not kpartx. So, a few things:

1. If the device is actually a /dev/mapper device (e.g. created with echo "0 16777216 linear /dev/loop0 0" | dmsetup create loopdev then this patch works fine. After kpartx -u runs, lsblk correctly returns e.g. loopdev1 as the name of the first partition.

   If the device is not a DM device, this doesn't work, because kpartx doesn't actually create partitions; it creates DM devices which map each partition read from the partition table. I tried using this patch to install onto a non-partitionable loop device and got:

$ sudo target/debug/coreos-installer install -f ~/tmp/web/fedora-coreos-30.20191014.0-metal.x86_64.raw.xz /dev/loop0 -i ~/fcos/live-var.ign
Copying image from /home/bgilbert/tmp/web/fedora-coreos-30.20191014.0-metal.x86_64.raw.xz
Reading signature from /home/bgilbert/tmp/web/fedora-coreos-30.20191014.0-metal.x86_64.raw.xz.sig
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
gpg: Signature made Mon 14 Oct 2019 11:59:16 PM EDT
gpg:                using RSA key EF3C111FCFC659B9
gpg: Good signature from "Fedora (30) <[email protected]>" [ultimate]
> Read disk 416.2 MiB/416.2 MiB (100%)   
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
Error: mounting device /dev/loop0p1 on /tmp/coreos-installer-dIA7ra
Caused by: ENOENT: No such file or directory
Clearing partition table
Error: install failed

Which makes sense, because we're still looking for the partitions in the usual place:

$ sudo lsblk --pairs --output NAME,LABEL,FSTYPE /dev/loop0
NAME="loop0" LABEL="" FSTYPE=""
NAME="loop0p1" LABEL="boot" FSTYPE="ext4"
NAME="loop0p2" LABEL="EFI-SYSTEM" FSTYPE="vfat"
NAME="loop0p3" LABEL="" FSTYPE=""
NAME="loop0p4" LABEL="root" FSTYPE="xfs"

So we should probably only run the kpartx path on DM devices. Or we could go the other direction and use kpartx in all cases, and update our expectation of where to find device nodes.

2. kpartx -u creates the partition mappings, but there's nothing in the code that deletes them after we're done.

3. This code uses BLKRRPART as a safety check to make sure no filesystems on the disk are mounted before overwriting them. kpartx -u will succeed even if an existing partition is mounted, so we'd need another way to perform that check.

4. The "invalid GPT" errors are benign and we might want to filter them out to avoid confusing the user.

5. Minor: the Dockerfile currently does not install kpartx in the container.

[nikita-dubrovskii]

Btw, i guess this PR could help closing #91

[bgilbert]

Alternative implementation in #285.