On 2021-Feb-13, at 17:38, Warner Losh <imp at bsdimp.com> wrote: > On Sat, Feb 13, 2021, 6:36 PM Mark Millard <marklmi at yahoo.com> wrote: > > On 2021-Feb-13, at 16:40, Warner Losh <imp at bsdimp.com> wrote: > > > Are you aware of gpart create? > > > > Warner > > From which I derive that I had an implicit, incorrect > assumption that gpart show would in some way list > everything available that gpart could manipulate > (including for use in creation). > > So I need to find such a drive another way, something > I was not even trying to do. > > That answers my question. Thanks. > > Nvmecontrol devlist is a good place to start. Or sysctl kern.disks > Turns out that sysctl kern.disks would not have directly helped on its own because the drive was replacing another: the set of names listed would be unchanged: # sysctl kern.disks kern.disks: da6 da5 cd0 da4 da3 da2 da1 da0 ada2 ada1 ada0 nvd5 nvd4 nvd3 nvd2 nvd1 nvd0 (I'd know it was one of the nvd*'s.) So for sysctl kern.disks use I'd need to look for a name (a nvd*) that gpart show had not listed and that would be the new one. So: use both commands. Good to know. nmvecontrol devlist does get into nvmeN/nvmeNns1 vs. the nvdN names listed in gpart show, and so for more complicated name matching. But, again, involves finding an unmatched name. In the actual context, the type and size happened to be unique and that would have made identification easy from nmvecontrol devlist output. Thanks for the notes, Mark > > >> On Sat, Feb 13, 2021, 4:41 PM Mark Millard via freebsd-current <freebsd-current_at_freebsd.org> wrote: > >> I plugged in a new Optane and booted FreeBSD on the > >> ThreadRipper 1950X system but FreeBSD did not show > >> the drive in gpart show. (It is unique by size in the > >> context and so would be hard to miss for anything > >> that listed sizes. Lack of listing a size would also > >> stand out.) > >> > >> So I did what I've done in the past: shutdown FreeBSD, > >> boot Windows 10, go to its disk management utility, > >> answer its prompt for MBR vs. GPT for the new device > >> (picking GPT), shutdown Windows 10. Then boot FreeBSD > >> again --and the new drive shows up. > >> > >> Is there a way to avoid the round trip through > >> Windows 10 (or any other such round trip going > >> outside FreeBSD)? I'm just curious if I've missed > >> something: My work around enables my activity. > >> > >> > >> FYI, FreeBSD based on main 3acea07c1873 : > >> > >> # ~/fbsd-based-on-what-freebsd-main.sh > >> merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b > >> merge-base: CommitDate: 2021-02-08 19:15:21 +0000 > >> c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. > >> 3acea07c1873 (pure-src) Restore the augmented strlen commentary > >> FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 1400004 1400004 > >> > >> But this is not a new thing, more of a "still true" > >> thing. > > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Sun Feb 14 2021 - 02:55:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC