Other Unable to run geli attach with disk internally

T

tOsYZYny

I moved an external drive internally as an internal drive appears to be failing. Normally, I run:

geli attach -p -k <file> da0
Click to expand...

I expect I should be able to run:

geli attach -p -k <file> ada1
Click to expand...

But, in this case, I'm getting:
geli: Cannot read metadata from ada1: Invalid argument.
geli: There was an error with at least one provider.
Click to expand...

If I move it back to the external enclosure and repeat the process for da0, it works.

What am I missing here?

I'm working with the raw device, ZFS is setup on the encrypted volume.

I didn't setup a partition as I wanted the entire drive to be encrypted and within that, I could manage that through ZFS tools. It appears that if I try to run geli attach on an internal drive externally, it doesn't work, and if I do the converse, an external drive mounted internally, that also does not work. It only works in the original configuration.

Is there some setting or default that changes behavior such as blocksize for internal versus external drives?
 
tOsYZYny said:
I didn't setup a partition as I wanted the entire drive to be encrypted and within that, I could manage that through ZFS tools. It appears that if I try to run geli attach on an internal drive externally, it doesn't work, and if I do the converse, an external drive mounted internally, that also does not work. It only works in the original configuration.
Click to expand...
I suspect that the media size of the disks are not calculated correctly.

geli(8) writes the metadata of a initialized provider in the last sector or the disk. If the media sizes differ geli(8) wont be able to read that metadata, even if automatic expansion is turned on (default).

Compare media sizes of disks when attached internal and external: geom disk list ada1 (da0)
 
I had some external SATA->USB convertors who translated access to some sectors like MBR.
Probably you have very smart external hdd case who translated some data written to the physical HDD and then you will have some differences of raw data on different interfaces like USB and SATA.
 
I think you're right. I took an external HD and removed the base which provides the power and SATA connection and use that with internal drives. That enclosure came with a 3TB drive and my internal disks are 4 TB. I suspect that it was programmed for that :).
 
You're right, using 2 different adapters, I get 2 different results. I was originally looking at another USB drive.

This one works and is the original way I setup the drive.
Geom name: da1
Providers:
1. Name: da1
Mediasize: 4000787025920 (3.6T)
Sectorsize: 4096
Mode: r0w0e0
descr: Seagate FA GoFlex Desk
lunname: Seagate FA GoFlex Desk 2
lunid: Seagate FA GoFlex Desk 2
ident: 2HC015KJ
rotationrate: unknown
fwsectors: 63
fwheads: 255
Click to expand...

This one does not work, new enclosure:
Geom name: da1
Providers:
1. Name: da1
Mediasize: 4000787030016 (3.6T)
Sectorsize: 4096
Mode: r0w0e0
descr: SABRENT
lunname: SABRENT DB9876543213F
lunid: 3042987654321430
ident: DB98765432143
rotationrate: unknown
fwsectors: 63
fwheads: 255
Click to expand...

The media size is different, so I need to figure out a way around that.
 
  • Like
Reactions: im
What could I have done to prevent this issue? Should I have partitioned my disk before just putting geli on the entire thing? I figured a partition table wasn't needed since I wanted to use the whole disk for an encrypted ZFS pool.
 
Having seen computers stop booting with a non-boot drive connected to it that had random data written all across it which required I connect it after boot to zero/partition it to avoid that, I am weary of trusting a BIOS/UEFI to be smart enough to handle corrupt/incompatible partition table structures and always partition disks given a choice. BIOS/UEFI code on many systems has been known to have plenty of bugs and be incompatible with the standards they should implement, and sometimes when clearly reported the manufacturers don't attempt to fix it with a response of "works with Windows".

If it was only a size difference of how many final bytes are on the end, that can be controlled with partitions and their sizes. Some controllers do something proprietary with a disk so it looks like a drive to the outside even though you do not have full/native access to its surface; connecting directly to another controller therefore can be like presenting a 'different' drive/data depending on what that controller was doing.

If you plan to change/move things, the best thing you can do is test the scenario to be aware of the issue that comes up. If you find controllers doing proprietary things, sharing it publicly helps others become aware and decide their use of it accordingly.
 
Ok, so how do I proceed? What is the best practice? Is a partition table required, would it have helped in this case?

If I don't format the drive, how can I specify the media size so that I can use the device as-is?
 
tOsYZYny said:
What is the best practice? Is a partition table required, would it have helped in this case?
Click to expand...
It would have helped, and it would have been best practice.

When creating a (GPT) partition for the geli(8) provider which expands over the whole disk, to make sure the partition size remains the same on different disk controller, specify a alignment value:

gpart(8)
Code: 
     add       Add a new partition to the partitioning scheme given by geom.
               ...

               The add command accepts these options:

               -a alignment  If specified, then the gpart utility tries to
                             align start offset and partition size to be
                             multiple of alignment value.

For example, the guided Root-on-ZFS installation sets a value of 1m. From a /var/log/bsdinstall_log:
Code: 
DEBUG: zfs_create_diskpart: gpart add -a 1m -l zfs0 -t freebsd-zfs "ada0"

tOsYZYny said:
If I don't format the drive, how can I specify the media size so that I can use the device as-is?
Click to expand...
I don't think it's possible to modify the media size. The disk controller determines the size. What can be done is to move the geli(8) metadata at the end of the disk.

!!! Before all following operation I would make a backup of the disk data (if not done yet) and verify if it's good. !!!

Then a backup of the geli(8) metadata.

Next I would try in following order:

1 - geli(8) attach the external disk in the Seagate enclosure and check if the "AUTORESIZE" flag is set:
Code: 
 $ geli list da1.eli | egrep 'Geom name|Flags'
If it is not set:

geli(8)
Code: 
    configure  Change configuration of the given providers.

                Additional options include:
                ...
                -r
                   Turn on automatic expansion.  For more information, see the
                   description of the init subcommand.
Move over the disk to the SABRENT enclosure, see if it has an effect.

2 - If the "AUTORESIZE" flag is set, but it has no effect on the SABRENT enclosure, next try geli(8) 'resize' when disk in SABRENT enclosure:
Code: 
 $ geli resize -s 4000787025920 da1

3 - If this doesn't work out, try geli(8) 'restore' the metadata when disk on the SABRENT enclosure. Probably you need to set the '-f' flag.
 
You must log in or register to reply here.
Back
Top