warning : long wandering post that leads to a panic.

Here comes an oldie but a goodie. I am sure others have run into boot
issues and the process of debugging them. I wonder if I am missing a
gap in my understanding of how Solaris/OpenSolaris ( on x86 ) boots
up. I was under the impression that the computer will pass POST and
then go looking for an executable on the boot disk in sector 0 of
track 0 or some other location as may be hardwired into the BIOS of
the machine.  Most PC technology, and even x86/AMD64 servers, do not
have boot firmware list the Sparc/Alpha/PowerPC servers do. So we are
at the whims of a few hard coded locations I think.

However a bootloader *should* be found. Like GRUB or ye old DCA.
Somewhere in the process GRUB gets loaded and that can only happen if
the first executable can support the bootable filesystem type (
ufs/zfs/ext3fs etc ) and knows where to look for the bootloader.

But wait .. it gets fuzzy now .. at least for me.

Old old Solaris x86 had some funky boot-loader type thing called the
DCA. Device Configuration Assistant and even Solaris 10 had that back
in GA days. Where things get fuzzy for me is the solaris bootenv.rc
file

[EMAIL PROTECTED]:~$ uname -a
SunOS aequitas 5.11 snv_93 i86pc i386 i86pc

[EMAIL PROTECTED]:~$ ls -lap /boot/solaris
total 223
drwxr-xr-x   4 root     sys            8 Jul 15 03:08 ./
drwxr-xr-x   5 root     sys            6 Jun 16 07:53 ../
drwxr-xr-x   2 root     sys            9 Jul 15 03:02 bin/
-rw-r--r--   1 root     sys         1314 Jun 16 07:53 bootenv.rc
drwxr-xr-x   2 root     sys            3 Jul 15 03:03 devicedb/
-rw-r--r--   1 root     sys          479 Jul 15 03:02 filelist.ramdisk
-rw-r--r--   1 root     sys          133 Apr 27 01:43 filelist.safe
-rw-r--r--   1 root     root      102988 Jul 15 03:08 filestat.ramdisk

See that file there ?  The one called bootenv.rc ?  Well that thing
*should* setup some realmode boot environment variables that you can
not get from EEPROM or Firmware because the OpenBoot software does not
exist on x86 :

[EMAIL PROTECTED]:~$ grep -v "^#" /boot/solaris/bootenv.rc
setprop ata-dma-enabled 1
setprop atapi-cd-dma-enabled 1
setprop ttyb-rts-dtr-off false
setprop ttyb-ignore-cd true
setprop ttya-rts-dtr-off false
setprop ttya-ignore-cd true
setprop ttyb-mode 9600,8,n,1,-
setprop ttya-mode 9600,8,n,1,-
setprop lba-access-ok 1
setprop keyboard-layout 'Unknown'
setprop console 'text'

That is an interesting list but I do NOT see bootpath anywhere. I also
wonder why I do not see :

setprop keyboard-layout 'US-English'

but that is nothing compared to the next stuff.

That file /boot/solaris/bootenv.rc is part of the old package called
SUNWrmodr thus :

[EMAIL PROTECTED]:~$ pkginfo -l SUNWrmodr
   PKGINST:  SUNWrmodr
      NAME:  Realmode Modules, (Root)
  CATEGORY:  system
      ARCH:  i386
   VERSION:  11.11,REV=2008.03.22.10.56
    VENDOR:  Sun Microsystems, Inc.
      DESC:  Realmode Modules, (Root)
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed


On Solaris 10 I see the following :

# uname -a
SunOS ganymede 5.10 Generic_127128-11 i86pc i386 i86pc
# grep -v "^#" /boot/solaris/bootenv.rc

setprop ata-dma-enabled '1'
setprop atapi-cd-dma-enabled '0'
setprop ttyb-rts-dtr-off 'false'
setprop ttyb-ignore-cd 'true'
setprop ttya-rts-dtr-off 'false'
setprop ttya-ignore-cd 'true'
setprop ttyb-mode '9600,8,n,1,-'
setprop ttya-mode '9600,8,n,1,-'
setprop lba-access-ok '1'
setprop prealloc-chunk-size '0x2000'
setprop bootpath '/[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci17c2,[EMAIL 
PROTECTED]/[EMAIL PROTECTED],0:a'
setprop keyboard-layout 'US-English'
setprop console 'ttya'

Note the presence of bootpath there.

Also, for the sake of reference, Solaris 8 x86 has similar things going on :

$ uname -a
SunOS titan 5.8 Generic_117351-54 i86pc i386 i86pc
$ pkginfo -l SUNWrmodr
   PKGINST:  SUNWrmodr
      NAME:  Realmode Modules, (Root)
  CATEGORY:  system
      ARCH:  i386
   VERSION:  1.1.0,REV=1999.12.22.16.52
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  Realmode Modules, (Root)
    PSTAMP:  on28-patch-x20041018135933
  INSTDATE:  Jan 24 2008 19:54
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:       53 installed pathnames
                   9 shared pathnames
                  13 directories
                1559 blocks used (approx)

$ cat /boot/solaris/bootenv.rc
#ident  "@(#)bootenv.rc 1.21    01/04/03 SMI"
#
#       bootenv.rc -- boot "environment variables"
#
setprop auto-boot? 'true'
setprop auto-boot-cfg-num '-1'
setprop auto-boot-timeout '5'
setprop boottimeout '0'
setprop bshfirst 'false'
setprop output-device 'ttya'
setprop input-device 'ttya'
setprop boot-file 'kernel/unix'
setprop target-driver-for-scsi 'sd'
setprop target-driver-for-direct 'cmdk'
setprop target-driver-for-csa 'cmdk'
setprop target-driver-for-dsa 'cmdk'
setprop target-driver-for-smartii 'cmdk'
setprop pciide 'true'
setprop prealloc-chunk-size '0x2000'
setprop ata-dma-enabled '0'
setprop kbd-type 'US-English'
setprop kbd-wkeys 'true'
setprop probed-arch-name 'i86pc'
setprop probed-compatible 'i86pc'
setprop bootpath '/[EMAIL PROTECTED],0/pci9004,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0:a'
setprop ttya-ignore-cd 'true'


So on both Solaris 8 x86 and Solaris 10 x86/AMD64 ( s10u5 ) I see a
bootpath device provided to the boot software in some file. Except
with OpenSolaris which does not seem to have such a thing.  Probably
because of ZFS but I do not know.

/********************************
  HERE COMES THE PANIC
 ********************************/

So .. what happens if I perform a ufsdump ( or similar ) of a Solaris
x86 machine and then try to restore it somewhere else? Like on some
other piece of hardware with entirely different disk controllers or
perhaps even into VMware.

bad things ...

panic[cpu0]/thread=fffffffffbc23a20: cannot mount root path

fffffffffbc46860 genunix:rootconf+f7 ()
fffffffffbc46890 genunix:vfs_mountroot+61 ()
fffffffffbc468d0 genunix:main+a5 ()
fffffffffbc468e0 unix:_start+95 ()

[ little observation : those threads increase by nice multiples of 0x10h ]
I booted with the kernel debugger so I also get to see

panic : entering debugger (no dump device, continue to reboot)

Welcome to kmdb
Loaded modules: [ uppc ufs unix cpu_ms.AuthenticAMD.15 krtld genunix
specfs pcplusmp cpu.generic ]
[0]>

So there we have it.

It looks like I need to inform the boot process about what the correct
boot device really is. I *think* that means I need to tweak the boot
envionment with a bootpath device.  That *seems* to be possible with
Solaris 10 but not with OpenSolaris. I could be wrong.  I can tell you
that I can boot with a CDROM and then just look at the PCI device path
to the bootable disk but when I enter that info into the
/boot/solaris/bootenv.rc file as a valid bootpath I get the exact same
panic. I can try to edit the vfstab file and that fails also but I
don't really think the boot process has proceeded that far anyways.

With the kernel debugger it should be possible to look at memory (
vmem_seg structs ) and see if anything at all was read from that
bootenv.rc file or not.

So is there some gap in my knowledge here somewhere?

Dennis
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to