search for: path_to_inst

Zpool split is a wonderful feature and it seems to work well, and the choice of which disk got which name was perfect! But there seems to be an odd anomaly (at least with b132) . Started with c0t1d0s0 running b132 (root pool is called rpool) Attached c0t0d0s0 and waited for it to resilver Rebooted from c0t0d0s0 zpool split rpool spool Rebooted from c0t0d0s0, both rpool and spool were mounted

Hi, Given two disk c1t0d0 (DISK A) and c1t1d0 (DISK B)... 1/ Standard install on DISK A. 2/ zfs boot install on DISK B. 3/ I change the boot order and my zfs boot works fine. 4/ I install grub on the mbr of DISK B 5/ I disconnect and replace DISK A with DISK B 6/ Reboot, get the grub menu select Solaris ZFS and it panics that it cannot mount root path @ device XXX... This is not a ZFS

Apparently with zfs boot, if the zpool is a version grub doesn''t recognize, it merely ignores any zfs entries in menu.lst, and apparently instead boots the first entry it thinks it can boot. I ran into this myself due to some boneheaded mistakes while doing a very manual zfs / install at the summit. Shouldn''t it at least spit out a warning? If so, I have no issues filing a

Hello, I am curious to know if there is an easy way to guess or identify the device names of disks. Previously the /dev/dsk/c0t0d0s0 system made sense to me... I had a SATA controller card with 8 ports, and they showed up with the numbers 1-8 in the "t" position of the device name. But I just built a new system with two LSI SAS HBAs in it, and my device names are along the lines of:

...).        If so, what event is used to force an attach? b. The attach is failed and a default set of nodes is created and adjusted when the device is        accessable? c. The attach is successful and everything is cleaned up later when the device is available. 8. Is it possible to query the path_to_inst data via a system call to determine the minors created     for a disk during early boot? This question is related to question 7; If the Solaris disk driver     makes a default assumption about the label type before the device is available and creates     nodes accordingly, how can this decision...

...ide (obp-device, d80000042c) ide (obp-device, d800000435) pci-ide (pci-ide, d80000043e) ide (ide, d800000466) cmdk (block, d800000477) ide (ide, d80000048e) sd (cdrom, d8000004a5) /etc/path_to_inst "/pci at 0,0/pci8086,25ae at 1c/pci11ab,11ab at 3" 0 "marvell88sx" "/pci at 0,0/pci8086,25ae at 1c/pci11ab,11ab at 3/disk at 0,0" 3 "sd" "/pci at 0,0/pci8086,25ae at 1c/pci11ab,11ab at 3/disk at 2,0" 4 "sd" "/pci at 0,0/pci8086,25ae...

Hello all, It was often asked and discussed on the list about "how to change rpool HDDs from AHCI to IDE mode" and back, with the modern routine involving reconfiguration of the BIOS, bootup from separate live media, simple import and export of the rpool, and bootup from the rpool. The documented way is to reinstall the OS upon HW changes. Both are inconvenient to say the least.

Hiya, Is there any reason (and anything to worry about) if disk target IDs don''t start at 0 (zero). For some reason mine are like this (3 controllers - 1 onboard and 2 PCIe); AVAILABLE DISK SELECTIONS: 0. c8t0d0 <ATA -ST9160314AS -SDM1 cyl 19454 alt 2 hd 255 sec 63> /pci at 0,0/pci10de,cb84 at 5/disk at 0,0 1. c8t1d0 <ATA -ST9160314AS -SDM1