Date: Sat, 22 Apr 2017 12:02:54 -0700 From: Lee Brown <leeb@ratnaling.org> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-geom@freebsd.org Subject: Re: glabel problem Message-ID: <CAFPNf5_gcbez7f5Y7drqdpUNUWQtuhe97jXPvxLcpbJOyjEV7Q@mail.gmail.com> In-Reply-To: <58FABB3A.6040704@quip.cz> References: <CAFPNf59g=Yo9oB16nf9pAE8wHKB_29aD0AZWsi%2BecKiC_4kEJQ@mail.gmail.com> <58FABB3A.6040704@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 21, 2017 at 7:08 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote:
> Lee Brown wrote on 2017/04/22 03:26:
>
> [..]
>
> root@apron:~ # glabel label -v TEST da2
>> Metadata value stored on da2.
>> Done.
>>
>> but
>> root@apron:~ # glabel status da2
>> root@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@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@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@apron:~ # gpart create -s GPT da2
da2 created
root@apron:~ # gpart add -t freebsd-ufs -a 4k -l test da2
da2p1 added
root@apron:~ # glabel status
Name Status Components
gpt/test N/A da2p1
gptid/292e8661-2789-11e7-af35-001ec944dcb4 N/A da2p1
root@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@apron:~ # gpart show da2
=> 40 2097151920 da2 GPT (1.0T)
40 2097151912 1 freebsd-ufs (1.0T)
2097151952 8 - free - (4.0K)
root@apron:~ # usbconfig -d 3.2 power_off
root@apron:~ # usbconfig -d 3.2 power_on
root@apron:~ # gpart show da2
=> 40 2097151920 da2 GPT (1.0T) [CORRUPT]
40 2097151912 1 freebsd-ufs (1.0T)
2097151952 8 - free - (4.0K)
root@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@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@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@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@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
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPNf5_gcbez7f5Y7drqdpUNUWQtuhe97jXPvxLcpbJOyjEV7Q>