I want to be able to temporarily plug in the root drive of another host to my laptop and run propellor to re-image the drive with the properties of the host it belongs to. This is especially useful when the drive is too large to make a DiskImage on my laptop.

Open design questions:

  • How to uniquely identify which removable drive belongs to which Host? Could use partition uuids for updating an already imaged drive, but not for the initial build.

    /dev/disk/by-id/ seems a good way to go. Eg for a USB drive I have, "/dev/disk/by-id/usb-LaCie_iamaKey_37637172f536ba-0:0" probably uniquely identifies it, at least as long as the manufacturer is not reusing serial numbers.

    One problem with /dev/disk/by-id/ is, if a removable drive is attached on a different bus (ie, a SATA drive might be connected via SATA or a USB dock), it won't appear the same there.

    Could instead use eg udevadm info --query=all -n /dev/sdb, which breaks out ID_SERIAL. However, this would be harder for the user to look up. Or, could parse the /dev/disk/by-id/ name, excluding the bus part of it.

    Question: When using microsd card adapter, does the serial number pass through so different microsds can be distinguished?

    Checked this, and two microsd card adapters from different manufacturers with different microsd cards have the same by-id. Those must have no serial number..

    Also, a USB SD/microSD reader had the same by-id for multiple cards.

    For disks with a MBR, there's a disk identifier / volume id, which should uniquely identify that disk, as long as propellor does not overwrite the MBR when imaging it. And, GPT has a similar disk GUID.

    /dev/disk/by-partuuid exposes this. Some documentation suggests it's GPT-only, but my laptop is not GPT and its MBR disk identifier shows up there. Oddly, that points to /dev/sda1 and not /dev/sda.

    blkid can also display it, as the PTUUID, which works for both GPT and MBT. --Joey

    root@darkstar:/home/joey>blkid /dev/sda /dev/sda: PTUUID="d0497bc6" PTTYPE="dos"

  • Should an already imaged drive be updated incrementally or re-imaged? Seems both cases would be useful, the former especially for incrementally configuring it, the latter to bring it up from a clean state. If it defaults to updating, the user could force a re-image by deleting the partitions from the drive manually.

secret-project has some code for /target which might be reusable here.

--Joey