NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Break with - bad reloc address 0x0 in section .pdata
> On Tue, Mar 11, 2014 at 09:55:02PM +1300, Mark Davies wrote:
> > On Tuesday 11 March 2014 21:26:48 Robert Elz wrote:
> > > Attachment order can't be controlled, but numbering can, but I agree,
> > > there's no really good reason to do that unless you plan on moving
> > > around devices (or adding some more) perhaps - and then you'd be better
> > > to use GPT and wedges and wedge names to keep things constant, rather
> > > than relying on wd numbering.
>
> > Indeed its constant disk names in the face of sometimes adding and
> > removing some that I want so an example of how to do that with GPT and
> > wedges would be instructive. I've read the manual pages a few times but
> > haven't really ever got my head around wedges.
> I had never thought of using wedge names to keep things consistent in this
> sort
> of situation, that's really clever.
> Wedges can be difficult to understand precisely because they are so abstract,
> I
> agree... they're like an abstraction of making partitions in general. Pretty
> academic stuff, but super useful (it's why I keep coming back to NetBSD).
> Just throwing it out there: an alternative approach is to use DragonFly, which
> allows you to access disks by their serial number, which theoretically never
> change. The disadvantage is DragonFly is not portable at all (i386 or x86_64
> only).
> -Christian
DragonFly can see my hard-disk partitions but can't mount any, for whatever
reason.
Also, DragonFly gives me no Internet access on my hardware.
DragonFly file systems seem to be unmountable/unreadable from FreeBSD and
NetBSD.
Accessing GPT partitions is easier in Linux and even better in FreeBSD.
Partitions can be labeled, nothing sneaky about partition/wedge numbering, and
device nodes are created dynamically instead of having to be preallocated.
Tom
Home |
Main Index |
Thread Index |
Old Index