Port-amd64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Installing two versions in parallel
>> I do note you said that it's the boot device that is RF level 1,
>> whereas the previous paragraph is talking about the root. But if
>> you're booting from level 1 RAID, I would guess you presumably want
>> root to be a RF set too.
> I don't know whether there's any sensible distinguishment between
> root and boot device in NetBSD.
There is, at least for NetBSD as I know it (which doesn't really
include anything past 5.2, though based on my work experience with 8.0
and 9.1 I think this stuff is basically the same).
The boot device is the place the bootblocks and kernel are loaded from.
The root device is the place / is mounted from. They do not have to be
the same; I have a few machines on which the ROM code can't access more
than the beginning of the disk (eg, on some SPARCs, some ROM revs can't
use 10-byte CDBs even though the hardware, and the NetBSD kernel once
it's running, can). On those, I sometimes find it useful to create a
small (eg, 64M) partition to hold kernels and bootblocks, then have no
particular restrictions on /. (On such machines I will typically set
up a mount point /kernels that mounts the small partition.)
> As far as I understand, technically, the system boots from a
> component of the level 1 set (knowing to skip the RAIDframe header)
> up to the point the kernel is running and (auto)configures the RAID
> set.
That matches my understanding. I don't think I've ever set a machine
up to boot from a RF mirror, but I have occasionally put root on
(autoconfigured-as-root) RF.
> But I don't get what
>> It was just a matter of pointing the MBR partitions at the pieces of
>> the disk where I had the four OSes installed
> and
>> The NetBSD partitions involved were all set up with the same
>> disklabel and used kernels configured with root on the appropriate
>> partitions.
> mean.
> Does that mean you started with the usual setup of one MBR partition
> with a disclabel and then artificially pointed the other MBR entries
> to the disclabel partitions containing the root file systems of the
> other OSes?
That sounds close to what I did. I do not have easy access to that
particular machine at the moment (it was for a work project I'm no
longer the principal worker on, so I don't have the machine at home any
longer). I do find some backups at hand, though. Based on those:
fdisk (MBR partitioning) looks like
Disk: /dev/rwd0d
NetBSD disklabel disk geometry:
cylinders: 969021, heads: 16, sectors/track: 63 (1008 sectors/cylinder)
total sectors: 976773168
BIOS disk geometry:
cylinders: 1023, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 976773168
Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
bootmenu: DOS
start 63, size 8388608 (4096 MB, Cyls 0-522/43/32)
1: NetBSD (sysid 169)
bootmenu: 5.2
start 8388671, size 33554432 (16384 MB, Cyls 522/43/33-2610/213/34), Active
2: NetBSD (sysid 169)
bootmenu: 8.0
start 41943103, size 67108864 (32768 MB, Cyls 2610/213/35-6788/43/38)
3: NetBSD (sysid 169)
bootmenu: 9.1
start 109051967, size 67108864 (32768 MB, Cyls 6788/43/39-10965/128/42)
Bootselector enabled, timeout 10 seconds.
First active partition: 1
wd0's NetBSD disklabel, in sector 8388672, looks like
# /dev/rwd0d:
type: ESDI
disk: ST500DM002-1BD14
label: fictitious
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 969021
total sectors: 976773168
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 33554432 8388671 4.2BSD 0 0 0 # (Cyl. 8322*- 41610*)
c: 33554432 8388671 unused 0 0 # (Cyl. 8322*- 41610*)
d: 976773168 0 unused 0 0 # (Cyl. 0 - 969020)
e: 8388608 63 MSDOS # (Cyl. 0*- 8322*)
f: 67108864 41943103 4.2BSD 0 0 0 # (Cyl. 41610*- 108186*)
g: 67108864 109051967 4.2BSD 0 0 0 # (Cyl. 108186*- 174762*)
h: 419430400 557342768 4.2BSD 0 0 0 # (Cyl. 552919*- 969020)
/etc/fstab from partitions a, f, and g contain
a:
/dev/wd0a / ffs rw 1 1
/dev/wd0e /dos msdos rw 1 2
/dev/wd0f /8.0 ffs rw 1 2
/dev/wd0g /9.1 ffs rw 1 2
/dev/wd0h /big ffs rw 1 2
kernfs /kern kernfs rw
ptyfs /dev/pts ptyfs rw
procfs /proc procfs rw
f:
/dev/wd0f / ffs rw 1 1
/dev/wd0h /big ffs rw 1 2
/dev/wd0a /5.2 ffs rw 1 2
kernfs /kern kernfs rw
ptyfs /dev/pts ptyfs rw
procfs /proc procfs rw
tmpfs /var/shm tmpfs rw,-m1777,-sram%25
g:
/dev/wd0g / ffs rw 1 1
/dev/wd0h /big ffs rw 1 2
/dev/wd0a /5.2 ffs rw 1 2
/dev/wd0f /8.0 ffs rw 1 2
tmpfs /tmp tmpfs rw,-m=1777,-s=ram%25
kernfs /kern kernfs rw
ptyfs /dev/pts ptyfs rw
procfs /proc procfs rw
tmpfs /var/shm tmpfs rw,-m1777,-sram%25
(I'm not sure why the 8.0 install doesn't mount the 9.1 filesystem.)
I looked at sector 1 of the wd0f and wd0g backups. wd0f has a valid
label, but it looks nothing like the above. It contains
start size end type [fsize bsize cpg] |
a: 63 67108864 67108927 4.2BSD 0 0 0 | 32 GB
c: 63 67108864 67108927 unused 0 0 | 32 GB
d: 0 312581808 312581808 unused 0 0 | 149.051 GB
e: 67108927 67108864 134217791 4.2BSD 0 0 0 | 32 GB
f: 134217791 178364017 312581808 4.2BSD 0 0 0 | 85.0506 GB
wd0g does not have a valid label in sector 1.
I conclude from these that something like my guess below about where
the disklabel comes from is correct.
> But how would you be able to boot from an MBR partition containing no
> disclabel?
I'm not certain, but I *think* the bootblocks and the kernel find the
disklabel in sector 1 of the first NetBSD MBR partition, regardless of
which partition it's booting from (in this case that means the
disklabel is the one in disk sector 8388672, even when booting from MBR
partition 2 (wd0f) or 3 (wd0g).
The piece I'm unsure of is how the installs in partitions f and g find
their boot partitions, to load the correct kernel. (The kernels, of
course, are configured "root on wd0f" and "root on wd0g".) I see two
possibilities; I don't know which if either is correct. One is that
the MBR code passes enough info to the PBR for the PBR to find its
partition. The other is that that info got hardwired into the PBR at
installboot time.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index