Date: Tue, 31 Oct 1995 11:42:00 +0100 (MET) From: "Georg-W. Koltermann" <gwk@racer.dkrz.de> To: freebsd-bugs@freebsd.org Cc: jhk@time.cdrom.com Subject: 951026-SNAP: second FBSD slice on a disk Message-ID: <199510311042.LAA22886@racer.dkrz.de>
next in thread | raw e-mail | index | archive | help
Last night I wanted to check out the latest (by yesterday) snap on my
machine at home. At home I have to install from floppies, by the way.
Since I didn't want to erase my working/production 2.0.5 system I
decided that maybe I could reuse the space previously dedicated to
Linux. I haven't booted Linux in about three months anyway :-)
That meant creating a second FBSD slice on the disk.
>From the help page in the disk editor I learned that the current boot
code will only mount a root from the 'a' partition of the first BSD
slice on a disk. Also I found out by experimentation that the disk
editor does not allow me to specify a mount point of "/" for the 'a'
partition in the second slice on the disk.
Here is a bug:
If you type 'A' in the disk editor to get default partitions
set up, then a root can still be created in the second slice.
Now, what is the "first" FBSD slice? Do you just count the entries in
the slice table in the MBR, or do you mean the slice which is first in
the data blocks on the disk? I didn't look at the code, but I
strongly believe "first" means the first FBSD entry in the slice
table, not the slice which has space allocated lower on the disk.
I allocated a fresh FBSD slice with the slice editor, using the space
taken up by Linux previously. That space is *after* my existing 2.0.5
FBSD slice. In order to be able to install to this slice I then
rearranged the slice entries in the MBR with MS-DOG debug. Now the
newly created FBSD slice was the first one in the slice table. Still
the space on disk was after the the old FBSD slice, of course:
sd0s1 new FBSD slice data located higher on disk
sd0s2 old FBSD slice data located first on disk
I booted the install floppy again, went into the disk editor and...
WHOOPS. The fresh slice was sd0s1 as it should be, but it was
listed SECOND, and I could NOT create a root partition in it.
Apparently the disk editor **sorted** the slice entries in
ascending order of data block allocation. Do you think this
is right?
I went into MS-DOG debug again an changed the type field of the old
FBSD slice to something else. Now back in the FBSD install menu my
new FBSD slice was the only one with type BSD and I could install the
snap. After installation it booted up o. k..
Again I went into MS-DOG debug and changed the type field of my old
(production) FBSD slice back to the correct value for BSD. I left the
slice ordering untouched, new slice first, then old slice.
Now I could still boot the snap that I installed on sd0s1, and I could
also mount my production filesystems from sd0s2*.
This pretty much proves that the "compatibility" partition which gets
mounted by the boot code ist the 'a' partition in the FBSD slice which
OCCURS FIRST in the slice table in the MBR. This slice does not need
to be located first in the data area. Do you agree?
Which brings me to a suggestion:
It would be real handy to automate what I have done in order to get
FBSD installed on a second slice. What about a new command in the
slice editor which allows you to DESIGNATE which slice should be the
compatibility slice? The program would only need to move that slice
to the first slot in the slice table, as I did manually with debug.
You would also need to keep the diskeditor from sorting the slices in
disk block order, of course.
Regards,
Georg-W. Koltermann, gwk@cray.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510311042.LAA22886>