glabel problem

[Lee Brown]

On Fri, Apr 21, 2017 at 7:08 PM, Miroslav Lachman <000.fbsd at quip.cz> wrote:

> Lee Brown wrote on 2017/04/22 03:26:
>
> [..]
>
> root at apron:~ # glabel label -v TEST da2
>> Metadata value stored on da2.
>> Done.
>>
>> but
>> root at apron:~ # glabel status da2
>> root at apron:~ #
>>
>
> Did you tried to disconnect and reconnect after "glabel label". Sometimes
> label is not visible until retaste of the device (true > /dev/da2)
>
Yes, I also tried a usb power-off/on cycle.

>
> I zero'd the first and last 1MB and re-tried the label operation, but all
>> the sectors were still zero.
>> I tried to use the usbdump utility and I can see *something* is written.
>>
>> gpart appears to do the right thing.
>> newfs on the raw device appears to do the right thing.
>> geli init complains it can't find the metadata.
>>
>
> What about partitioning by gpart GPT with gpt partition label and then use
> this label for geli instead of whole device?
>
geli complains in the same way, this is what I tried:
root at apron:~ # dd if=/dev/zero of=/dev/da2 bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.124755 secs (8405050 bytes/sec)

root at apron:~ # dd if=/dev/zero of=/dev/da2 bs=1m oseek=1023999
dd: /dev/da2: end of device
2+0 records in
1+0 records out
1048576 bytes transferred in 0.039043 secs (26856688 bytes/sec)

root at apron:~ # gpart create -s GPT da2
da2 created
root at apron:~ # gpart add -t freebsd-ufs -a 4k -l test da2
da2p1 added

root at apron:~ # glabel status
                                      Name  Status  Components
                                  gpt/test     N/A  da2p1
gptid/292e8661-2789-11e7-af35-001ec944dcb4     N/A  da2p1

root at apron:~ # geli init -a HMAC/SHA256 -J /root/empty-password -K
/root/geli.CANI-RL.key -s 4096 gpt/test
geli: Unable to read metadata from gpt/test: Invalid argument.

I tried with and without /dev prefix, with and without -s 4096 and even
da2p1 which all gave me the same message.

Other info:
ugen3.2: <product 0x1234 vendor 0x048d> at usbus3, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (100mA)

Now:
root at apron:~ # gpart show da2
=>        40  2097151920  da2  GPT  (1.0T)
          40  2097151912    1  freebsd-ufs  (1.0T)
  2097151952           8       - free -  (4.0K)
root at apron:~ # usbconfig -d 3.2 power_off
root at apron:~ # usbconfig -d 3.2 power_on

root at apron:~ # gpart show da2
=>        40  2097151920  da2  GPT  (1.0T) [CORRUPT]
          40  2097151912    1  freebsd-ufs  (1.0T)
  2097151952           8       - free -  (4.0K)

root at apron:~ # dd if=/dev/da2 iseek=1023999 bs=1m | od -ha
0000000      0000    0000    0000    0000    0000    0000    0000    0000
         nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
4000000
1+0 records in
1+0 records out
1048576 bytes transferred in 0.049774 secs (21066694 bytes/sec)

Could the device simply be faulty?  It's quite slow, it'll take 28hrs to
wipe it, so I filled the last 2mb and 1gb with random

root at apron:~ # dd if=/dev/random of=/dev/da2 bs=1m oseek=1023998
dd: /dev/da2: end of device
3+0 records in
2+0 records out
2097152 bytes transferred in 0.111204 secs (18858633 bytes/sec)
root at apron:~ # dd if=/dev/da2 iseek=1023998 bs=1m | od -ha
0000000      0000    0000    0000    0000    0000    0000    0000    0000
         nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
10000000
2+0 records in
2+0 records out
2097152 bytes transferred in 0.098105 secs (21376560 bytes/sec)

root at apron:~ # dd if=/dev/random of=/dev/da2 bs=1m oseek=1023000
dd: /dev/da2: end of device
1001+0 records in
1000+0 records out
1048576000 bytes transferred in 51.457299 secs (20377595 bytes/sec)
root at apron:~ # dd if=/dev/da2 iseek=1023000 bs=1m | od -ha
0000000      0000    0000    0000    0000    0000    0000    0000    0000
         nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 49.336478 secs (21253564 bytes/sec)
7640000000

It looks like it's just not writing beyond a certain point.

Thanks for helping, this is really strange.

>
> Miroslav Lachman
>
>
>