search

OSInside / kiwi

KIWI - Appliance Builder Next Generation
https://osinside.github.io/kiwi
GNU General Public License v3.0
303 stars 152 forks source link

EDIT: Source Install Disk Detection always evaluates to False - Bootable Drive from OEM ISO can deploy to itself in some cases #1983

Closed TheMisanthropicHumanist closed 2 years ago

TheMisanthropicHumanist commented 2 years ago

Problem description

An issue with Source Install Disk Detection in kiwi-dump-image.sh:get_disk_list() means that if the Target Disk is an NVMe, and the Install Media is a Flash Drive, the first disk detected by lsblk is the Flash Drive, and the install writes overtop of the Install Media instead of the Target Disk. The Source Install Disk Detection depends on Disks getting lsblk-viewable Labels, NOT Partitions.

Partitions get Labels, NOT disks.

We need to detect the Install Disk Partition and ignore the Disk that contains that Partition so that variations in Disk Type between Install Media and Target Disk Media can be supported.

Expected behaviour

Source Install Disk is ignored and install is performed on Target Disk.

Steps to reproduce the behaviour

  1. Build an Expandable OEM Disk ISO for any Distribution and select Dracut for the initrd type and oem_unattended=true
  2. Burn the ISO to a Flash Drive using either dd mode or ISO Mode
  3. Deploy the Image to a machine with a Primary Drive that is of Type NVMe
  4. Flash Drive is overwritten with Target Image and corrupted
  5. Target Disk is untouched

OS and Software information

TheMisanthropicHumanist commented 2 years ago

This can be linked to Pull Request https://github.com/OSInside/kiwi/pull/1982

TheMisanthropicHumanist commented 2 years ago

This Problem Description isn't clear enough/jumps around topics chaotically. Apologies, I was in a hurry as this was a work project.

The problem is two-fold:

The Source Install Disk Detection in get_disk_list() checks the Label (Retrieved from blkid) of each Disk returned from lsblk against the kiwi_install_volid. This check is not valid because the Install Partition is what gets Labeled with kiwi_install_volid, NOT the Disk. This means the check will always evaluate to false, which is okay for likely 99% of cases.

However, this means we're left to the mercy of the order of Disks/Partitions returned from lsblk to determine which Disk is chosen for the Target Install (When oem_unattended is true). lsblk, at least in our scenario, groups disks by Disk Type (SCSI, NVMe, etc.). It also prints SCSI disks first, even if the primary Drive in the machine is an NVMe. This means the Deployment Flash Drive will be returned first, and will NOT be detected as the Source Install Disk because blkid can't return the Label field associated with a Disk - Just Partitions.

Therefore, this evaluation of the Disk List is only accurate in cases where the Target Media and Install Media are both SCSI Disks, or both NVMes, at least in the scenarios we've run into. Of course, lsblk might return the Disks in different groupings/orders for other distributions or versions, skipping this problem altogether. But we can easily account for all of these problem scenarios by ensuring the check against the kiwi_install_volid is properly handled. Pull Request #1982 should guarantee this.

Also, just wanted to say, I'm a HUGE fan of this tool, and the work you all have done and are doing here. I hope to contribute more in the future as our clients start cutting over to this new tool for their Appliances.

schaefi commented 2 years ago

Fixed with #1982