Esteemed Colleagues:

Although it is unsupported, I have successfully installed OpenBSD on a
logical slice within the extended slice of an MBR-partitioned disk.
It took days.  I may post, to this mailing list, a description of how
I figured out how to do it; but the write-up would take hours, so it
may not appear right away.

Here is the edited output from "disklabel sd0" and from "fdisk -v sd0":

  m5# fdisk -v sd0  
  Primary GPT:
  Not Found

  Secondary GPT:
  Not Found

  MBR:
  Disk: sd0     geometry: 58369/255/63 [937703088 Sectors]
  Offset: 0     Signature: 0xAA55
              Starting         Ending         LBA Info:
   #: id      C   H   S -      C   H   S [       start:        size ]
  
-------------------------------------------------------------------------------
  *0: 0C  57389 130  22 -  58369  80  30 [   921962496:    15740559 ] Win95 
FAT32L
   1: 07     13   0  52 -  19594  64  54 [      208896:   314572800 ] NTFS
   2: 07      0  32  33 -     13   0  51 [        2048:      206848 ] NTFS
   3: 05  19594  64  55 -  57389 130  21 [   314781696:   607180800 ] Extended 
DOS
  Disk: sd0     geometry: 58369/255/63 [937703088 Sectors]
  Offset: 314781696     Signature: 0xAA55
              Starting         Ending         LBA Info:
   #: id      C   H   S -      C   H   S [       start:        size ]
  
-------------------------------------------------------------------------------
   0: 8E  19594  97  24 -  26121 118  45 [   314783744:   104857600 ] Linux LVM
   1: 05  26121 118  47 -  30037 215   2 [   419641345:    62916607 ] Extended 
DOS
   2: 00      0   0   0 -      0   0   0 [   314781696:           0 ] unused
   3: 00      0   0   0 -      0   0   0 [   314781696:           0 ] unused
  Disk: sd0     geometry: 58369/255/63 [937703088 Sectors]
  Offset: 419641345     Signature: 0xAA55
              Starting         Ending         LBA Info:
   #: id      C   H   S -      C   H   S [       start:        size ]
  
-------------------------------------------------------------------------------
   0: A6  26121 151  16 -  30037 215   2 [   419643393:    62914559 ] OpenBSD
   1: 05  30037 215   5 -  31212 215  43 [   482557954:    18876414 ] Extended 
DOS
   2: 00      0   0   0 -      0   0   0 [   419641345:           0 ] unused
   3: 00      0   0   0 -      0   0   0 [   419641345:           0 ] unused
     [ omitted lines ]
  m5# disklabel sd0 
  # /dev/rsd0c:
     [ omitted lines ]
  16 partitions:
  #                size           offset  fstype [fsize bsize   cpg]
    a:         57358559        419643393  4.2BSD   2048 16384 12960 # /
    b:          5556000        477001952    swap                    # none
    c:        937703088                0  unused                    
    d:           860160        627273728   MSDOS                    # /mnt/boot
    i:           206848             2048    NTFS                    # 
/Windows-Boot
    j:        314572800           208896    NTFS                    # /Windows
    k:         15740592        921962496   MSDOS                    # /FreeDOS
    l:        104857600        314783744 unknown                    
  m5#

(If anyone is wondering about /dev/sd0l, it is the LVM volume group
containing Linux logical volumes, on which my collection of Linux
operating systems resides.  These are visible on FreeBSD.  If anyone
on this mailing list knows how to make Linux logical volumes visible
on OpenBSD as they are on FreeBSD, I would welcome seeing the
information on this mailing list.)

There is still, however, one problem (which may be related to the
fact that installation on a logical slice is unsupported, although I
don't see how it is): the bootloader does not work.  This is not
fatal, because I can get GRUB to boot the kernel directly, with
"kopenbsd /bsd -r sd0a" (more on that later).  But it is troubling.

I have two operating systems on my computer that can install GRUB:
Solaris and Linux.  Both of them ought to be able to boot OpenBSD by
chainloading to the OpenBSD bootloader, thus:

   set root=(hd0,6)
   chainloader +1

Here is the output of "installboot -nv sd0":

  m5# installboot -v sd0  
  Using / as root
  installing bootstrap on /dev/rsd0c
  using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
  copying /usr/mdec/boot to //boot
  looking for superblock at 65536
  found valid ffs2 superblock
  //boot is 6 blocks x 16384 bytes
  fs block shift 2; part offset 419643393; inode block 56, offset 2928
  expecting 64-bit fs blocks (incr 4)
  master boot record (MBR) at sector 0
        partition 0: type 0x0C offset 921962496 size 15740559
        partition 1: type 0x07 offset 208896 size 314572800
        partition 2: type 0x07 offset 2048 size 206848
        partition 3: type 0x05 offset 314781696 size 607180800
  extended boot record (EBR) at sector 314781696
        partition 0: type 0x8E offset 2048 size 104857600
        partition 1: type 0x05 offset 104859649 size 62916607
  extended boot record (EBR) at sector 419641345
        partition 0: type 0xA6 offset 2048 size 62914559
  /usr/mdec/biosboot will be written at sector 419643393
  installboot: /usr/mdec/biosboot extends beyond sector 268435455. OpenBSD 
might not boot.
  m5# 

So we see that installboot correctly determines that OpenBSD is on a
logical slice, it correctly determines the beginning of that logical
slice, and it correctly writes the bootloader to sector 419643393, which
is exactly where GRUB should find it, upon executing "chainloader +1".
And, indeed, GRUB does not complain about an invalid signature.  It
definitely does find a bootloader there.  But this is what happens
when it boots (there may be typographical errors, I am copying
manually from the screen):

  Loading......
  probing: pc0 mem[629K 511M 510M 2175M 7M 7M 22M 19M 2M 64K 13030M a20=on]
  disk: hd0+*
  >> OpenBSD/amd64 BOOT 3.55
  open(hd0a:/etc/boot.conf): Invalid argument
  boot>
  cannot open hd0a:/etc/random.seed: Invalid argument
  booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
   failed(22). will try /bsd
  boot>
  cannot open hd0a:/etc/random.seed: Invalid argument
  booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
   failed(22). will try /bsd
  Turning timeout off.
  boot> ls
  stat(hd0a:/.): Invalid argument
  boot> ls /
  stat(hd0a:/): Invalid argument
  boot> machine diskinfo
  Disk    BIOS#   Type    Cyls    Heads   Secs    Flags   Checksum
  hd0     0x80    label   1023    255     83      0x0     0xe61ca3fc

Clearly the bootloader that was installed from /usr/mdec/biosboot was
successfully executed, and it successfully executed /boot.  The
secondary bootloader, however, does not see the filesystem.  That it
cannot find /etc/boot.conf does not trouble me, because there is no
/etc/boot.conf because I did not create one, and the /etc/boot.conf
file is, if I am not mistaken, optional.  But it cannot find /bsd.
When I typed the ls command it was clear that it cannot even find the
current or the root directory (which, parenthetically, ought to be the
same).  It does find the hd0 disk.  And when I repeat the procedure
when USB flash drives are connected, it finds the hd1 disk and the hd2
disk also.  It finds disks.  But it does not find files.  I even,
grasping at straws, linked /dev/sd0a to /dev/hd0a (and did the same,
mutantis mutandis, with b and c).  It made no difference.  I recently
saw a posting on another mailing list that presented the belief (the
author of the posting was not sure that it was true) that the
bootsector of a logical slice contains relative rather than absolute
positioning information.  If this belief were true, and if /boot could
not be made aware of that fact, it might, maybe, explain the inability
of /boot to find the filesystem on which it resides.  But that belief
is contradicted by the output of fdisk, shown above.  Moreover, the
primary bootloader is able to find the secondary bootloader; so,
unless it does so by means of blocklists, the secondary bootloader
should surely be able to find /bsd.  It does not. How do I get the
OpenBSD bootloader to boot OpenBSD?

That this is not a fatal error is only because GRUB was able to boot
the OpenBSD kernel directly thru kopenbsd:

   grub> insmod ufs2
   grub> set root=(hd0,6)
   grub> kopenbsd /bsd -r sd0a
   grub> boot

But this is only true of the GRUB that is installed by Linux.  The
GRUB that is installed by Solaris is, apparently, an older version
that cannot boot the kernel directly.  Behold:

   grub> insmod ufs2
   grub> set root=(hd0,6)
   grub> kopenbsd /bsd -r sd0a
   error: only device specifications of form wd<number><lowercase letter> are 
supported.   

So this is a bootloader that checks the arguments and options of
kopenbsd, which I did not ask it to do, and which thinks that an
OpenBSD root disk has to have a name beginning with wd.  I got around
that.  I linked /dev/sd0a to /dev/wd0a.  Now I get this:

   grub> insmod ufs2
   grub> set root=(hd0,6)
   grub> kopenbsd /bsd -r wd0a
   grub> boot
   error: overlap detected.

A "grep -r" (this is a rhetorical figure, there is no "grep -r" on
Solaris) informs me that the error message comes from relocator.mod.
Apparently relocator.mod is detecting a condition that would be
nonfatal if ignored, and treating it as a fatal error; and apparently
this bug was fixed on Linux, but Oracle never updated the GRUB on
Solaris.  Still, there was some condition that was detected.  What was
the condition?  And how do I fix it?

So far my efforts to boot OpenBSD from the Solaris GRUB have all
failed.  I tried to get around the problem by doing "kopenbsd /boot",
by doing "legacy_kernel /bsd /bsd -r sd0a", and even by doing "knetbsd
/bsd -r sd0a".  None of these elicits an error message.  But they all
fail, booting into the blank screen of death.  The last two should
fail, so I am not complaining that they do.  But "kopenbsd /bsd -r
sd0a" should succeed.  And, what is more important to the readers of
this mailing list, "chainloader +1" should succeed -- the OpenBSD
bootloader should be able to boot OpenBSD.  Why can't it?

Unrelated to the above, I see from the output of "ifconfig -a" that my
newly-installed OpenBSD system did not configure my wireless device,
which, according to the outpout of "pcidump -v", is a Broadcom BCM4313.
I assume that the failure to configure this device is due to my not
having yet invoked the fw_update command.  I am puzzled, though: I
thought that fw_update is now invoked automatically within the install
procedure.

As always, thank you in advance for any and all replies.

        Jay F. Shachter
        6424 North Whipple Street
        Chicago IL  60645-4111
                (1-773)7613784   landline
                (1-410)9964737   GoogleVoice
                http://m5.chicago.il.us
                j...@m5.chicago.il.us

        "But when she traced the killer's IP address ... it was in the 
192.168/16 block!"

Reply via email to