[ Based on limited previous experience of such panics.... ]
1. The kernel boots from wherever GRUB or the DCA is told to load the
OS from. This loads some bits from (a filesystem in) disk or network
into RAM and starts executing.
2. The kernel internally calls vfs_mountroot() to re-mount the root
filesystem as a mount-within-the-OS (rather than just bits read into RAM
by the bootloader). For UFS, this is done based on the bootpath property.
3. If the bootpath property does not point to the correct root
filesystem then you panic.
4. There may be differences with OpenSolaris and/or ZFS root.
It's entirely possible that if you boot on new hardware on which the
path to the old boot device does not match then you'll panic. And to
complicate attempts to fix this, the device paths may be different when
booted from CD rather than the OS itself.
As to how to fix this, you could first try resetting /etc/path_to_inst.
To do this, when booted from CD, set /a/etc/path_to_inst to contain only
the following and reboot:
#path_to_inst_bootstrap_1
Note that this changes the c0d0s0 numbering
and may therefore screw up /etc/vfstab !!!
You may need to boot without bootpath, or write down the path it seems
to boot from and put this in bootpath. If this still fails then the fix
may be trickier. Back in the day (before devfs) I *think* it was
possible, when booted from CD, to do something like:
# chroot /a <command-I-forget-to-create-contents-of-/devices>
# chroot /a devlinks
Essentially you're trying to do the equivalent of "chroot /a
<steps-run-by-reconfig-reboot>". And then updating /etc/vfstab. But
the run-time /devices may confuse this.
Caveat emptor; have a good backup; etc.
Hugh.
PPS: with newboot, the bootpath is going to be coming from the boot
archive, not the underlying FS.
Dennis Clarke wrote:
> 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
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
