1.6 installation woes

1.6 installation woes

Post by Jens Schweikhard » Thu, 10 Oct 2002 03:14:42



hello, world\n

having used FreeBSD for 8 years I decided to give NetBSD a try and
downloaded the i386 iso. To be able to mount the netbsd partitions under
FreeBSD I decided to stay with a slice type of 'Old NetBSD', i.e. fdisk
on FreeBSD says

  sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)

Now I'm pulling my hair because I can't tell the NetBSD installer to
leave that sysid alone. Yes, it does ask whether I want to convert that
to the new NetBSD type. I answer "NO". Then it shows me the list of
partitions, in my case a: through f: (probably because that's what I've
configured in previous attempts). As soon as I modify the a: partition
(specify the mount point as /) and return from that menu, the installer
shows me all 16 partitions, a: through p:. When the installation is
over, and I reboot into FreeBSD, I have

  sysid 169 (0xa9),(NetBSD)

again. I went through the whole install about 5 times. ARGH. I'm willing
to be proven an idiot. Otherwise, whoever wrote that installer owes me a
schnaps. Anyone successfully installed 1.6 in a sysid 165 partition? How?

Regards,

        Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

1.6 installation woes

Post by Martin Neitz » Thu, 10 Oct 2002 10:14:28


I may be completely wrong with the following train of thought,
so please just give it just a mild consideration.

I would expect that FreeBSD does not need to be too finicky about
that 165/169 issue.  After all, this is just an informational hint
within the fdisk partition table (DOS partition sense).  I also
thought that both 16x numbers are mutually recognized since a long
time now.  But I might very well err on this.

The crucial question is whether FreeBSD will be able to grok the
NetBSD partition table (BSD sense) stored within the slice.

NetBSD's option to have slices with 16 instead of the customary 8
partitions is not that very old.  IIRC, that came with NetBSD 1.5.
I didn't check any current FreeBSD for a long time now.  Are they
able to deal with 16 partitions within a slice by now, too?

My FreeBSD-3.1 box certainly still employs the traditional
        #define MAXPARTITIONS   8
in its /usr/include/sys/disklabel.h

[Hey, at least I'm not running 2.0 anymore, OK!?]

I know that the NetBSD installation hints carried a warning that
employing disklabels with 16 partitions voided compatibility with
other BSD systems.  (Not for all Unixen, though -- there are other
systems around besides NetBSD which are using 16 partitions, too.
But a-h used to be the universal disklabel(5).)

                                                        Martin

 
 
 

1.6 installation woes

Post by Jens Schweikhard » Thu, 10 Oct 2002 15:53:31




#
# I may be completely wrong with the following train of thought,
# so please just give it just a mild consideration.
#
# I would expect that FreeBSD does not need to be too finicky about
# that 165/169 issue.  After all, this is just an informational hint
# within the fdisk partition table (DOS partition sense).  I also
# thought that both 16x numbers are mutually recognized since a long
# time now.  But I might very well err on this.

You do err :-)

# The crucial question is whether FreeBSD will be able to grok the
# NetBSD partition table (BSD sense) stored within the slice.

No it can't. It complains about a corrupt disklabel (IIRC it's
some ioctl DIOCGDINFO to read the label that fails).

# NetBSD's option to have slices with 16 instead of the customary 8
# partitions is not that very old.  IIRC, that came with NetBSD 1.5.
# I didn't check any current FreeBSD for a long time now.  Are they
# able to deal with 16 partitions within a slice by now, too?


how to mount NetBSD partitions inside a 169 slice on FreeBSD and got
zero response. Googling and checking the FAQs didn't provide any insight
either.

# My FreeBSD-3.1 box certainly still employs the traditional
#         #define MAXPARTITIONS   8
# in its /usr/include/sys/disklabel.h
#
# [Hey, at least I'm not running 2.0 anymore, OK!?]
#
# I know that the NetBSD installation hints carried a warning that
# employing disklabels with 16 partitions voided compatibility with
# other BSD systems.  (Not for all Unixen, though -- there are other
# systems around besides NetBSD which are using 16 partitions, too.
# But a-h used to be the universal disklabel(5).)

So far it seems it voids interoperability with FreeBSD. I'd like to
be proven wrong here, but so far nobody has.

Can anybody confirm that the installer has a bug because it insists
on changing from 8 to 16 partititons per slice?

Regards,

        Jens
--
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

1.6 installation woes

Post by Frederick Bruckm » Thu, 10 Oct 2002 23:51:45






> #
> # I know that the NetBSD installation hints carried a warning that
> # employing disklabels with 16 partitions voided compatibility with
> # other BSD systems.  (Not for all Unixen, though -- there are other
> # systems around besides NetBSD which are using 16 partitions, too.
> # But a-h used to be the universal disklabel(5).)

> So far it seems it voids interoperability with FreeBSD. I'd like to
> be proven wrong here, but so far nobody has.

The sensible thing would to put a NetBSD disklabel in the NetBSD
MBR partition (type 169) and a FreeBSD label in the FreeBSD MBR
partition (type 165). To accomplish this, you'll either need to
use a custom kernel built without "COMPAT_386BSD_MBRPART", or
you'll need to place the NetBSD partition in a lower numbered
slot than the FreeBSD one. It doesn't even need to be first on
the disk -- just first in the table -- so you can probably fix
the installation with "fdisk" by rearranging the partitions to
have a type 169 in the "0" slot, of the same size and type as the
existing NetBSD partition. The FreeBSD label will still be corrupted,
but it will henceforth be left alone, so you might then use FreeBSD's
sysinstall to fix it.

Quote:> Can anybody confirm that the installer has a bug because it insists
> on changing from 8 to 16 partititons per slice?

I doubt it. The type ID was changed exactly so NetBSD could safely
diverge from the FreeBSD disklabel format. If somebody figures out
how to make dual boot with FreeBSD install cleanly -- perhaps
clearing out the "0" partiton before running NetBSD's sysinstall?
-- then that would call for a mention in the installation docs.

--

Frederick

 
 
 

1.6 installation woes

Post by Jens Schweikhard » Fri, 11 Oct 2002 20:32:04




#




#> #
#> # I know that the NetBSD installation hints carried a warning that
#> # employing disklabels with 16 partitions voided compatibility with
#> # other BSD systems.  (Not for all Unixen, though -- there are other
#> # systems around besides NetBSD which are using 16 partitions, too.
#> # But a-h used to be the universal disklabel(5).)
#>
#> So far it seems it voids interoperability with FreeBSD. I'd like to
#> be proven wrong here, but so far nobody has.
#
# The sensible thing would to put a NetBSD disklabel in the NetBSD
# MBR partition (type 169) and a FreeBSD label in the FreeBSD MBR
# partition (type 165). To accomplish this, you'll either need to
# use a custom kernel built without "COMPAT_386BSD_MBRPART", or
# you'll need to place the NetBSD partition in a lower numbered
# slot than the FreeBSD one. It doesn't even need to be first on
# the disk -- just first in the table -- so you can probably fix
# the installation with "fdisk" by rearranging the partitions to
# have a type 169 in the "0" slot, of the same size and type as the
# existing NetBSD partition. The FreeBSD label will still be corrupted,
# but it will henceforth be left alone, so you might then use FreeBSD's
# sysinstall to fix it.

I'm afraid this paragraph confused me totally. :-) There can be only
one MBR per physical drive. There is one disklabel per slice (="Partition"
in DOS lingo). Slice 1 was DOS, slice 2 the one for NetBSD, slice 3 for
Linux (slice 4 unused).

#> Can anybody confirm that the installer has a bug because it insists
#> on changing from 8 to 16 partititons per slice?
#
# I doubt it.

Well, seeing is believing. The drive (sd4) was *, with only FreeBSD
fdisk being used to configure the slices. So at first I thought ok,
slice 2 doesn't have any valid disklabel at all, so the installer choses
the new NetBSD type when it needs to write the label. But even after
configuring a valid disklabel with a few file sytems under FreeBSD, and
running the NetBSD installation again, AND ANSWERING "NO" to "Do you
want to convert this disklabel to the new NetBSD label", it would change
the sysid from 165 to 169 and offer me a: though p: to configure.

Is the installer in the CVS repo? If so, can someone point me at the right
directory, I can probably spend some time chasing that bug.

Regards,

        Jens
--
Jens Schweikhardt  http://www.veryComputer.com/
SIGSIG -- signature too long (core dumped)

 
 
 

1.6 installation woes

Post by Frederick Bruckm » Sun, 13 Oct 2002 01:05:37






> #




> #> #
> #> # I know that the NetBSD installation hints carried a warning that
> #> # employing disklabels with 16 partitions voided compatibility with
> #> # other BSD systems.  (Not for all Unixen, though -- there are other
> #> # systems around besides NetBSD which are using 16 partitions, too.
> #> # But a-h used to be the universal disklabel(5).)
> #>
> #> So far it seems it voids interoperability with FreeBSD. I'd like to
> #> be proven wrong here, but so far nobody has.
> #
> # The sensible thing would to put a NetBSD disklabel in the NetBSD
> # MBR partition (type 169) and a FreeBSD label in the FreeBSD MBR
> # partition (type 165). To accomplish this, you'll either need to
> # use a custom kernel built without "COMPAT_386BSD_MBRPART", or
> # you'll need to place the NetBSD partition in a lower numbered
> # slot than the FreeBSD one. It doesn't even need to be first on
> # the disk -- just first in the table -- so you can probably fix
> # the installation with "fdisk" by rearranging the partitions to
> # have a type 169 in the "0" slot, of the same size and type as the
> # existing NetBSD partition. The FreeBSD label will still be corrupted,
> # but it will henceforth be left alone, so you might then use FreeBSD's
> # sysinstall to fix it.

> I'm afraid this paragraph confused me totally. :-) There can be only
> one MBR per physical drive. There is one disklabel per slice (="Partition"
> in DOS lingo). Slice 1 was DOS, slice 2 the one for NetBSD, slice 3 for
> Linux (slice 4 unused).

NetBSD's fdisk numbers them "0" through "3". If the kernel has
COMPAT_386BSD_MBRPART (the default), it will take the first partition
with either type 165 or type 169 as it's own (so that's where the
disklabel will go). I believe FreeBSD does something similiar, except,
of course, FreeBSD always chooses type 165. Therefore, if you need to
dual boot FreeBSD and NetBSD, the NetBSD root needs to be in a lower
slot than the FreeBSD root.

Alternatively, you could build kernels, including installation
kernels, without COMPAT_386BSD_MBRPART. From your description below,
I don't think that would serve your purpose. It sounds like you want
to use FreeBSD to configure your NetBSD disklabel???

Quote:> #> Can anybody confirm that the installer has a bug because it insists
> #> on changing from 8 to 16 partititons per slice?

This brings to mind a point which I overlooked on first reading.
It's not 16 partitions per "slice", it's 16 partitions *overall*.
Rather than deal with other OS's limited schemes, NetBSD/i386 has
a completely separate one. You can dedicate a non-booting disk to
NetBSD which has only a disklabel, and no MBR at all. I believe
linux doesn't use disklabels at all, only "slices", and I don't
know what FreeBSD does now.

Quote:> # I doubt it.

> Well, seeing is believing. The drive (sd4) was *, with only FreeBSD
> fdisk being used to configure the slices. So at first I thought ok,
> slice 2 doesn't have any valid disklabel at all, so the installer choses
> the new NetBSD type when it needs to write the label. But even after
> configuring a valid disklabel with a few file sytems under FreeBSD, and
> running the NetBSD installation again, AND ANSWERING "NO" to "Do you
> want to convert this disklabel to the new NetBSD label", it would change
> the sysid from 165 to 169 and offer me a: though p: to configure.

Well, the question is probably bogus.

There's no standard for disklabels, so there's no reason to expect them
to be interoperable. If NetBSD understands the FreeBSD label well enough
to salvage some of the information before converting it, good for NetBSD.
If FreeBSD lacks any capacity to parse NetBSD labels, then that's their
deficiency, not NetBSD's.

The objection to breaking compatibility and tradition, by changing the
disklabel format shared with FreeBSD by virtue of common origin is not
a new one -- it was fully considered in discussion, and ultimately denied,
before the release of NetBSD 1.3.2 (or therabouts), some four years ago.

What you might try, is to see if an 8 partition NetBSD label is even
still parsable by FreeBSD. Assuming you can boot into NetBSD and run
"disklabel -e", just change the "16 partitions:" to "8 partitions:".

Quote:> Is the installer in the CVS repo? If so, can someone point me at the right
> directory, I can probably spend some time chasing that bug.

"/basesrc/distrib/utils/sysinst".

--
Frederick

 
 
 

1.6 installation woes

Post by Ted Spradle » Sun, 13 Oct 2002 06:50:10


On Fri, 11 Oct 2002 16:05:37 +0000 (UTC)


> > Well, seeing is believing. The drive (sd4) was *, with only
> > FreeBSD fdisk being used to configure the slices. So at first I
> > thought ok, slice 2 doesn't have any valid disklabel at all, so the
> > installer choses the new NetBSD type when it needs to write the
> > label. But even after configuring a valid disklabel with a few file
> > sytems under FreeBSD, and running the NetBSD installation again, AND
> > ANSWERING "NO" to "Do you want to convert this disklabel to the new
> > NetBSD label", it would change the sysid from 165 to 169 and offer
> > me a: though p: to configure.

> Well, the question is probably bogus.

> There's no standard for disklabels, so there's no reason to expect
> them to be interoperable. If NetBSD understands the FreeBSD label well
> enough to salvage some of the information before converting it, good
> for NetBSD. If FreeBSD lacks any capacity to parse NetBSD labels, then
> that's their deficiency, not NetBSD's.

Uh, I can't speak for PeeCees, but on my AlphaStation Free- and Net- are
able to mount each other's filesystems just fine (at least on separate
spindles).  I posted my experiences here about three weeks ago and got
no response:

<QUOTE>
Path:
newssvr30.news.prodigy.com!newssvr05.news.prodigy.com!newsmst01.news.pr
odigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr30.news.prodig

Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc
Subject: Free- v. Net- file system compatibility

Organization: S & S Computing
X-Newsreader: Sylpheed version 0.7.2 (GTK+ 1.2.10; i386--freebsd4.5)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 17
NNTP-Posting-Host: 65.66.253.4

X-Trace: newssvr30.news.prodigy.com 1033143611 ST000 65.66.253.4 (Fri,
27 Sep 2002 12:20:11 EDT) NNTP-Posting-Date: Fri, 27 Sep 2002 12:20:11
EDT X-UserInfo1:



2002 16:20:11 GMT Xref: newsmst01.news.prodigy.com
comp.unix.bsd.netbsd.misc:18218

I converted my old DEC AlphaStation from FreeBSD back to NetBSD
yesterday.  I had an extra disk drive lying around, so I stuck it into
the box and installed NetBSD on it without clobbering FreeBSD.  Just for
curiousity I tried to mount the FreeBSD filesystems, and it Just Worked.
 I booted up FreeBSD and mounted the NetBSD filesystems, too.  Worked
even with softupdates, both ways.  (We're talking about FFS/UFS only
here, don't care about any others)

Are there any caveats to doing this?  Will it work on PeeCees as well as
Alphas?  I've been thinking about setting up dual-boot on my desktop PC,
but I wanted to be able to mount the same local /home filesystem.  I
know I can share the same swap partition, but I suppose I'd get into
trouble if I tried to share /var.
</QUOTE>

--
Remember, more computing power was thrown away last week than existed in
the world in 1982.  -- http://www.veryComputer.com/

--
Remember, more computing power was thrown away last week than existed in
the world in 1982.  -- http://www.veryComputer.com/

 
 
 

1.6 installation woes

Post by Frederick Bruckm » Sun, 13 Oct 2002 07:34:39




> On Fri, 11 Oct 2002 16:05:37 +0000 (UTC)

>> > Well, seeing is believing. The drive (sd4) was *, with only
>> > FreeBSD fdisk being used to configure the slices. So at first I
>> > thought ok, slice 2 doesn't have any valid disklabel at all, so the
>> > installer choses the new NetBSD type when it needs to write the
>> > label. But even after configuring a valid disklabel with a few file
>> > sytems under FreeBSD, and running the NetBSD installation again, AND
>> > ANSWERING "NO" to "Do you want to convert this disklabel to the new
>> > NetBSD label", it would change the sysid from 165 to 169 and offer
>> > me a: though p: to configure.

>> Well, the question is probably bogus.

>> There's no standard for disklabels, so there's no reason to expect
>> them to be interoperable. If NetBSD understands the FreeBSD label well
>> enough to salvage some of the information before converting it, good
>> for NetBSD. If FreeBSD lacks any capacity to parse NetBSD labels, then
>> that's their deficiency, not NetBSD's.

> Uh, I can't speak for PeeCees, but on my AlphaStation Free- and Net- are
> able to mount each other's filesystems just fine (at least on separate
> spindles).  I posted my experiences here about three weeks ago and got
> no response:

That's good to know. It's certainly desirable to be able to read
FreeBSD file systems. That's wasn't even the question that started
this thread, though. The OP's lament was that NetBSD/i386 disklabels
aren't parsable by FreeBSD, or at least the 16 partition ones aren't,
and the trivial work -around to *that*, is to give each OS its very
own disklabel, even though they may be functionally identically.

This is, in fact, the very reason the the NetBSD MBR type id changed,
so NetBSD wouldn't muck up the FreeBSD label, so we wouldn't be bound
by tradition regarding the number of partitions per disk (IIRC). The
change won't be complete until NetBSD drop's the compatibility mode
by default. Possibly a better plan than all or nothing would be to
use the old type's label as a fallback (in the kernel).

--
Frederick

 
 
 

1.6 installation woes

Post by Jens Schweikhard » Sun, 13 Oct 2002 18:51:20






...
#> Uh, I can't speak for PeeCees, but on my AlphaStation Free- and Net- are
#> able to mount each other's filesystems just fine (at least on separate
#> spindles).  I posted my experiences here about three weeks ago and got
#> no response:
#
# That's good to know. It's certainly desirable to be able to read
# FreeBSD file systems. That's wasn't even the question that started
# this thread, though. The OP's lament was that NetBSD/i386 disklabels
# aren't parsable by FreeBSD, or at least the 16 partition ones aren't,
# and the trivial work -around to *that*, is to give each OS its very
# own disklabel, even though they may be functionally identically.

I think there's a misunderstanding here. My lament is not that the new
style NetBSD/i386 disklabels aren't parsable by FreeBSD. Here's my
train of thought, where any of the items may be wrong, and I'd like
to be enlightened.

1. In the past, NetBSD and FreeBSD slices both used sysid 165.
   Disklabels were (more or less) identical and could hold the traditional
   8 partitions. Mounting the other system's file systems was a
   no-brainer.

2. NetBSD developed a new style disklabel with 16 partitions, and maybe
   to document the incompatibility, also changed the slice sysid to 169,
   so other systems like FreeBSD would not get confused (e.g. FreeBSD
   will never look for disklabels on slices with sysid != 165).

3. NetBSD still supports slices with sysid 165 and the 8 partition
   disklabel from 1. One can run a NetBSD 1.6 system in such a slice and
   with this old-style disklabel.

4. The installer is designed to accept sysid 165 and an old disklabel.
   It will ask "Do you want to change the type of this partition to the
   new NetBSD-only partition type?". If answered "NO" it should simply
   use what it finds without changing either the sysid nor the number
   of partitions from 8 to 16.

My lament is that the installer will happily trash the sysid EVEN IF
EXPLICITLY TOLD to refrain from doing this. Why is it asking me if it
will ignore my answer? So either my understanding of this installation
question is totally wrong or the installer has a major bug.

Regards,

        Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

1.6 installation woes

Post by Frederick Bruckm » Mon, 14 Oct 2002 12:37:56






> # That's good to know. It's certainly desirable to be able to read
> # FreeBSD file systems. That's wasn't even the question that started
> # this thread, though. The OP's lament was that NetBSD/i386 disklabels
> # aren't parsable by FreeBSD, or at least the 16 partition ones aren't,
> # and the trivial work -around to *that*, is to give each OS its very
> # own disklabel, even though they may be functionally identically.

> I think there's a misunderstanding here. My lament is not that the new
> style NetBSD/i386 disklabels aren't parsable by FreeBSD. Here's my
> train of thought, where any of the items may be wrong, and I'd like
> to be enlightened.

> 1. In the past, NetBSD and FreeBSD slices both used sysid 165.
>    Disklabels were (more or less) identical and could hold the traditional
>    8 partitions. Mounting the other system's file systems was a
>    no-brainer.

> 2. NetBSD developed a new style disklabel with 16 partitions, and maybe
>    to document the incompatibility, also changed the slice sysid to 169,
>    so other systems like FreeBSD would not get confused (e.g. FreeBSD
>    will never look for disklabels on slices with sysid != 165).

Yes, that's the way I remember it (except several years went by between
the ID change and the actual change to 16 partitions).

Quote:> 3. NetBSD still supports slices with sysid 165 and the 8 partition
>    disklabel from 1. One can run a NetBSD 1.6 system in such a slice and
>    with this old-style disklabel.

I have set number of partitons to "4", and it works fine (on NetBSD).
No idea what FreeBSD makes of those, or even if FreeBSD is still capable
of reading any NetBSD labels. Note that now NetBSD has it's own sysid,
this is a complete non-issue (except for the installer bug, below).

Quote:> 4. The installer is designed to accept sysid 165 and an old disklabel.
>    It will ask "Do you want to change the type of this partition to the
>    new NetBSD-only partition type?". If answered "NO" it should simply
>    use what it finds without changing either the sysid nor the number
>    of partitions from 8 to 16.

> My lament is that the installer will happily trash the sysid EVEN IF
> EXPLICITLY TOLD to refrain from doing this. Why is it asking me if it
> will ignore my answer? So either my understanding of this installation
> question is totally wrong or the installer has a major bug.

OK, it's a bug. That question's been in there since 1.3.2 or so, BTW,
while the 16 partitions was only introduced with 1.5. I suggest the best
thing would be to never ask, and furthermore, to drop compatability with
the old sysid, except as a fallback for the initial label (on a disk
with no NetBSD label in the sysid 169 partition). The other way,
committing to support interoperability with FreeBSD labels, doesn't look
to be maintainable, seeing as it's evidently been broken for some time
before anyone's noticed, and it doesn't seem to me to be needed. (You're
not going to be running a NetBSD kernel on FreeBSD userland, right?) So
what do you think?

--
Frederick

 
 
 

1.6 installation woes

Post by Jens Schweikhard » Mon, 14 Oct 2002 19:02:49






...
#> 4. The installer is designed to accept sysid 165 and an old disklabel.
#>    It will ask "Do you want to change the type of this partition to the
#>    new NetBSD-only partition type?". If answered "NO" it should simply
#>    use what it finds without changing either the sysid nor the number
#>    of partitions from 8 to 16.
#>
#> My lament is that the installer will happily trash the sysid EVEN IF
#> EXPLICITLY TOLD to refrain from doing this. Why is it asking me if it
#> will ignore my answer? So either my understanding of this installation
#> question is totally wrong or the installer has a major bug.
#
# OK, it's a bug.

So I wasn't trying something silly :-)

# That question's been in there since 1.3.2 or so, BTW,
# while the 16 partitions was only introduced with 1.5. I suggest the best
# thing would be to never ask, and furthermore, to drop compatability with
# the old sysid, except as a fallback for the initial label (on a disk
# with no NetBSD label in the sysid 169 partition). The other way,
# committing to support interoperability with FreeBSD labels, doesn't look
# to be maintainable, seeing as it's evidently been broken for some time
# before anyone's noticed, and it doesn't seem to me to be needed. (You're
# not going to be running a NetBSD kernel on FreeBSD userland, right?) So
# what do you think?

No, not running a NetBSD on FreeBSD userland, just mount NetBSD
partitions on FreeBSD so I can easily copy config files, dot files and
whatever's around on each system's root file system. And have a shared
partition, so changes don't even have to be copied over, think of a
/home partition with /home/schweikh/bin for sharable scripts and
/home/schweikh/bin-`uname -s` for binaries. Right now I can mount Linux
and even MSDOS and NFTS partitions, but not my brother BSD's UFS :-(
[granted, this could be viewed as a FreeBSD deficiency and as a FreeBSD
committer I probably will lobby my file system guru colleagues if they
want to spend some cycles on making NetBSD-only partitions/disklabels
accessible.]

But right now I have the impression that there's only a bug in the
installer: that it overwrites the sysid again after specifying a mount
point. The support for old style disk labels is there and just can't
be used because of this.

In mbr.c it seems to do the right thing:

                if (bsdpart == freebsdpart) {
                        msg_display(MSG_upgradeparttype);
                        process_menu(MENU_yesno);
                        if (yesno)
                                part[bsdpart].mbrp_typ = dosptyp_nbsd;
                }

This is consistent with my observation that the installer shows me a
maximum of 8 partitions to edit (while I think it's 16 when answered
yes). But after actually entering the partition edit dialog (e.g. to set
the mount point for a: to /) there must be another change of
part[bsdpart].mbrp_typ which is wrong. Is a PR reasonable? I think it
would be a shame if support for old disklabels is declared abandoned
due to an installer bug that wasn't tracked down.

Regards,

        Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

1.6 installation woes

Post by Frederick Bruckm » Wed, 16 Oct 2002 01:57:09






> # That question's been in there since 1.3.2 or so, BTW,
> # while the 16 partitions was only introduced with 1.5. I suggest the best
> # thing would be to never ask, and furthermore, to drop compatability with
> # the old sysid, except as a fallback for the initial label (on a disk
> # with no NetBSD label in the sysid 169 partition). The other way,
> # committing to support interoperability with FreeBSD labels, doesn't look
> # to be maintainable, seeing as it's evidently been broken for some time
> # before anyone's noticed, and it doesn't seem to me to be needed. (You're
> # not going to be running a NetBSD kernel on FreeBSD userland, right?) So
> # what do you think?

> No, not running a NetBSD on FreeBSD userland, just mount NetBSD
> partitions on FreeBSD so I can easily copy config files, dot files and
> whatever's around on each system's root file system. And have a shared
> partition, so changes don't even have to be copied over, think of a
> /home partition with /home/schweikh/bin for sharable scripts and
> /home/schweikh/bin-`uname -s` for binaries. Right now I can mount Linux
> and even MSDOS and NFTS partitions, but not my brother BSD's UFS :-(

I think you're missing an important point. The sysid ID is *only* used
to locate the NetBSD disklabel. Nothing else. It has nothing to do with
whether the partitions are mountable or not. The partitions that are
listed in the disklabel need have nothing to do with the MBR "slices":
you can have a single partition for every "slice", or three for every
slice, or one that crosses three slices -- it doesn't matter. As long
as you have one type 169 "slice", for the NetBSD disklabel to live in,
you have complete flexibility to make the disklabel anything you like,
including listing any and all partitions that live in the other "slices",
or not. The NetBSD "slice" doesn't even need to have a file system at
all, though typically you would make it the NetBSD root ("a"), and make
it bootable.

Why can't you mount your brother's UFS partitions? What happens?
(Report the exact command you used, the result, and the result of
"fdisk" and "disklabel", please).

--

Frederick

 
 
 

1.6 installation woes

Post by Jens Schweikhard » Sun, 20 Oct 2002 00:15:22




...
# Why can't you mount your brother's UFS partitions? What happens?

On FreeBSD 5-current as of a few days ago (from memory):

$ disklabel da4s2
ioctl(DIOCGDINFO): innapropriate ioctl for device

$ mount /dev/da4s2a /netbsd
mount: /dev/da4s2a: no such device


Poul-Henning Kamp replied with a patch to make MAXPARTITIONS = 16 and
sysid 169 work. This lets me in fact mount the netbsd partitions.
However it probably will not be committed because it makes disklabel
complain (warn) about 8 partition labels, which is a bit ugly, even if
harmless. So I'll have to reapply this patch for every make world...

Regards,

        Jens
--
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

 
 
 

1. Upgrade from 1.6 Release to 1.6 Stable (daily releng-snapshot) with binaries

Hello,

I've got some machines here with 1.6 Release running and I'd like to
update to the more current stable, which is compiled daily at
releng.netbsd.org.
Because I don't want to compile it all, I'd like to do a binary-update
with the sets/*.tgz but I couldn't find any detailed instructions
about how to do that.

Can I just put them in / and tar xfvp them in single-user mode? Or do
I have to boot via floppy and then do it?
Is it okay when I put the GENERIC-Kernel of the binaries in /netbsd
and then recompile it after I got everything running?
What about /etc /var /tmp, other config-files?

If someone could give me some step-by-step instructions I would be
very grateful.

Greetings,

Markus

2. Basic Shell Doubt

3. htdig3.1.6 solaris 8 sparc installation problem

4. lpr and "unknown printer" problems...

5. CD-RW mounting woes in Mandrake 7.0 woe oh woe oh woe!

6. No getty in RHL 4.0

7. Dual Boot Openbsd 3.1 and NetBSD 1.6

8. iptables & 2.4.0

9. LINUX and EIDE 1.6 GB drive

10. traceroute for AIX V3.1.6/3.2.x

11. Mozilla 1.6 and 1.7 copy clipboard bug

12. Problem with jdk-1.1.6 appletviewer

13. The return of the return of crunch time (2.5 merge candidate list 1.6)