Re: newfs_udf(8) and other OSes

[tlaronde%polynum.com@localhost]

On Sat, Jun 27, 2015 at 09:35:19PM +0000, Michael van Elst wrote:
> tlaronde%polynum.com@localhost writes:
> 
> >There are no such options for me on NetBSD 6.1.5 : size is ignored, and
> >-S is for label. Is there some update on -current?
> 
> Yes. The netbsd-6 version of newfs_udf doesn't let you specify
> a sectorsize, but it does query the (disk) driver for a value.
> 
> 
> >Then under NetBSD, gpt (gpt show -l sd0) gives:
> 
> >       start        size  index  contents
> >           0           1         PMBR
> >           1           1         Pri GPT header
> >           2          32         Pri GPT table
> >          34        2014         
> >        2048  1953454080      1  GPT part - "Basic data partition"
> >  1953456128        2015         
> >  1953458143          32         Sec GPT table
> >  1953458175           1         Sec GPT header
> 
> >The problem is now, I imagine, to create a "wedge" so that the UDF is
> >not searched at the very beginning but at block 2048.
> 
> dkctl sd0 addwedge myudfwedge 2048 1953454080 udf
> 
> myudfwedge -> just a byte string that gives the wedge a name
> udf -> the wedge type (also a string).
> 

Is the wedge name a token that can be used directly with other utilities
or is the device name assigned (/dev/dkN) the "name" to use in every
case?

> If the kernel does wedge autodiscovery (netbsd-6 GENERIC does this),
> the wedge will be created automatically when the sd0 device is attached.
> The wedge type is deduced from the GPT partition type, but since
> "Basic data partition" is unknown, no type will be set.
> However, the UDF filesystem ignores that value.
> 
> 
> >But dkctl(8) doesn't help a lot: addwedge gives systematically "invalid
> >argument", without information, and, furthermore, udf is not listed as
> >a valid ptype (is cd9660 instead OK?).
> 
> Invalid argument usually comes from duplicate wedge names or
> from overlapping wedges. With autodiscovery, the wedge might
> already be there.
> 

Yes this was indeed the case (as reported in the [SOLVED] mail).

Everything works now and I can get rid of ntfs-3g.

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C