1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
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]]
|
