I’m going through the checklist for migration from CORE → Scale and am running across a thing I’d like to double check regarding SED drives. Specifically:
Global self-encrypting drive (SED) Password - Unlock these drives in CORE before you clean install SCALE. Write down the SED password configured in CORE to use in SCALE.
I honestly didn’t know if I had such a thing, but found this page and ran this command sedutil-cli --scan and discovered I have two disks listed as “E” which apparently corresponds to “Enterprise”.
I don’t think I’ve ever set these up, but how can I ensure these aren’t currently using any encryption and disable or unlock for the purpose of safely upgrading the system?
I don’t either, but want to make sure. The two “E” drives are part of the same pool (and they’re the only disks). I’m not sure how to use the “check SED” because it requires a password in the cli command that I don’t think I ever set up. I’m trying to see if these drives have active encryption working/running on them at present. Not sure how do to that.
try sedutil-cli --isValidSED and see what it reports back. You showed the drives support Enterprise but this may tell if it is on. Hoping for a 0 or 1, yes or no type response. If 0 or no, I wouldn’t expect it to be used.
@HoneyBadger Do you know of a way to check for active SED before migration?
You could also try searching for something like “check for active self encrypting drive” and see if anything comes up. FreeBSD forums may have answers also.
freenas# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/ada0 No WDC [disk-id] 80.00A80
/dev/ada1 No [disk-id] 0001
/dev/ada2 E WDC [disk-id] 85.00A85
/dev/ada3 E WDC [disk-id] 85.00A85
/dev/ada4 No WDC [disk-id] 19.01H19
The “is valid” reports back, individually, what the above also returns. They’re “valid” SED disks, I just can’t tell if they have active encryption on them.
You can try to see if you can find other threads with the SED issue. I know it has come up before but finding the info would be a bit harder on here. Otherwise, hoping other member more familiar with SED and Core post.
Unless you’ve set the UNLOCK password your drives shouldn’t be locking. sedutil-cli --query /dev/sdX might tell you the different - note that UNLOCKED is “enabled but access open” and NOT LOCKED should be “was never locked.”
I don’t have any SEDs at the moment to poke with but I can try to rev some up if we need to confirm this.
I’m assuming that this section gives me the anwser that the disk is not locked (and thus, I should be safe to proceed with the upgrade from CORE → SCALE). Does that seem correct?
Locking function (0x0002)
Locked = N, LockingEnabled = N, LockingSupported = Y,
Here’s the full output:
freenas# sedutil-cli --query /dev/ada2
/dev/ada2 ATA WDC [disk-id] 85.00A85 [disk-id]
TPer function (0x0001)
ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
Locked = N, LockingEnabled = N, LockingSupported = Y, MBRDone = N, MBREnabled = N, MBRAbsent = N, MediaEncrypt = Y
Geometry function (0x0003)
Align = Y, Alignment Granularity = 8 (4096), Logical Block size = 512, Lowest Aligned LBA = 0
Enterprise function (0x0100)
Range crossing = N, Base comID = 0x07fe, comIDs = 2
Block SID Authentication function (0x0402)
SID Blocked State = N, SID Value State = N, Hardware Reset = N
TPer Properties:
MaxPacketSize = 16364 MaxComPacketSize = 16384
MaxResponseComPacketSize = 16384 MaxIndTokenSize = 16328 MaxMethods = 1
MaxPackets = 1 MaxSubpackets = 1 MaxSessions = 1
MaxAuthentications = 0 MaxTransactionLimit = 1 DefSessionTimeout = 0
MinSessionTimeout = 0 MaxSessionTimeout = 0
Host Properties:
MaxPacketSize = 2028 MaxComPacketSize = 2048
MaxResponseComPacketSize = 2048 MaxIndTokenSize = 1992 MaxMethods = 1
MaxPackets = 1 MaxSubpackets = 1
That would imply to me that your drives are “capable but not using” encryption. If you don’t have anything configured under System > Advanced > SED Password then I’d feel fairly confident.
You can/should also definitely take a configuration backup - and potentially you could even use a separate boot device, such that reverting back would just mean “unplug SCALE, plug in CORE”