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]]