For initial few updates we have been making changes to our persistent store format and those changes are not backwards compatible. So it will be best if you clear the config as described on the website (under smf model) and reboot before installing the package. Once these changes stabilize (Which I hope every time we make them) you will be able to patch your current setup.
Sumit On Feb 12, 2008, at 10:35 PM, manu sawkar wrote: > great thanks, look forward to the update. Will i be able to patch my > current setup, or is the update procedure always to wipe the pkg clean > and restart? > > thanks again, > -m > > On Feb 13, 2008 1:22 AM, Sumit Gupta <[EMAIL PROTECTED]> wrote: >> Hi Manu >> >> Yes the Assert is in the codepath where the registration was to be >> preserved. So everything except the registration is preserved. >> >> Sumit >> >> >> On Feb 12, 2008, at 10:11 PM, manu sawkar wrote: >> >>> Hey Sumit, >>> >>> Thanks for the quick reply. Still havent been able to actually use >>> a client >>> and connect to verify but i will be doing disk tests with my raid >>> and a client >>> tomorrow so hopefully i'll have some updates, however i can provide >>> you >>> with some more info related to this bug... (that you may or may not >>> already >>> know about) >>> >>> When i reboot my system, the LU's that point to files are >>> preserved... but >>> the ones i've made that point to raw discs are not (perhaps this is >>> due >>> to the failed assert?) >>> >>> the views appear to be preserved though (makes sense i think) >>> this maybe of interest: >>> (the unregistered correspond to a rawdisk i added after it >>> disappeared >>> upon rebooting) >>> >>> stmfadm list-lu -v >>> LU Name: 6000AE4066000000000047B3342D0001 >>> Operational Status: unregistered >>> Provider Name : unregistered >>> Alias : - >>> View Entry Count : 1 >>> LU Name: 6000AE4066000000000047B334A50002 >>> Operational Status: Online >>> Provider Name : sbd >>> Alias : /lun0 >>> View Entry Count : 1 >>> LU Name: 6000AE4066000000000047B33B9B0001 >>> Operational Status: unregistered >>> Provider Name : unregistered >>> Alias : - >>> View Entry Count : 1 >>> >>> >>> On Feb 13, 2008 12:46 AM, Sumit Gupta <[EMAIL PROTECTED]> wrote: >>>> Hi Manu >>>> >>>> Thanks for your feedback. Despite the assert It did work in this >>>> case >>>> as you suspected. Regarding the CLI assert, it has been fixed >>>> and the >>>> fix will be included in the next opensolaris update along with rest >>>> of the changes and fixes. We are looking into some other issues at >>>> the moment and will update the package and sources soon. >>>> >>>> Thanks >>>> Sumit >>>> >>>> On Feb 12, 2008, at 6:32 PM, Manu Sawkar wrote: >>>> >>>>> First off, thanks to Sumit et al. for the great work on this >>>>> amazing project. I'm a total solaris newbie and have enjoyed >>>>> tinkering with the OS the past couple days. The purpose of this >>>>> whole endeavor is to try to create my own (cheap) 4GBs fc target >>>>> and before comstar was available it seemed my options were non- >>>>> existent. Anyways, on to my bug. >>>>> >>>>> I have been able to create and register 2 luns from a 1g mkfile >>>>> and >>>>> a dynamic growing file successfully and exported them with no >>>>> problem (i dont have access to an initiator client till tomorrow, >>>>> so i'm assuming that works). >>>>> >>>>> however, i then added an unformated sata disk to the equation >>>>> because my ultimate goal is to export raw disks from this machine >>>>> with the hopes that those disks could be removed from the solaris >>>>> box and mounted elsewhere if need be (this is possible right? if >>>>> they are exported as raw devices to hosts... i should be able to >>>>> put that disk in the host machine without it knowing that anything >>>>> happened) >>>>> >>>>> anyways, here is what happened: >>>>> >>>>> a format shows the new disk is up. a prtpart shows its 320GB >>>>> i already have 2 LU's registered and i can create the raw disk >>>>> as a >>>>> 3rd LU. However, when i register the 3rd LU i get that assertion >>>>> failure and core dump. It does appears to have registered >>>>> correctly, i can export the view... and subsequently prtpart says >>>>> the device is busy... so it looks like it worked. hopefully it >>>>> did! >>>>> >>>>> Thanks, >>>>> -Manu >>>>> >>>>> below is copied from the terminal. >>>>> >>>>> # format >>>>> Searching for disks...done >>>>> >>>>> >>>>> AVAILABLE DISK SELECTIONS: >>>>> 0. c1d0 <DEFAULT cyl 30385 alt 2 hd 255 sec 63> >>>>> /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL >>>>> PROTECTED]/[EMAIL PROTECTED],0 >>>>> 1. c4d0 <DEFAULT cyl 38911 alt 2 hd 255 sec 63> >>>>> /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL >>>>> PROTECTED]/[EMAIL PROTECTED],0 >>>>> Specify disk (enter its number): ^C >>>>> >>>>> >>>>> # prtpart >>>>> >>>>> Fdisk information for device /dev/rdsk/c4d0p0 >>>>> >>>>> Block Size : 512 bytes >>>>> Controller : ide >>>>> Disk : cmdk >>>>> Capacity : 298 GB >>>>> FDISK table NOT VALID >>>>> Reminder: dont forget to use either 'p0' or 'D0' device >>>>> >>>>> >>>>> # sbdadm list-lu >>>>> >>>>> Found 2 LU(s) >>>>> >>>>> GUID DATA SIZE SOURCE >>>>> -------------------------------- ------------------- >>>>> ---------------- >>>>> 6000ae4066000000000047b2f7080002 53687025664 /lun1 >>>>> 6000ae4066000000000047b2f6160001 1073676288 /lun0 >>>>> >>>>> # sbdadm create-lu /dev/rdsk/c4d0p0 >>>>> LU created succesfully. >>>>> Assigned GUID is 6000ae4066000000000047b303e00001. >>>>> # sbdadm register-lu /dev/rdsk/c4d0p0 >>>>> >>>>> Success! Registered the following LU: >>>>> >>>>> GUID DATA SIZE SOURCE >>>>> -------------------------------- ------------------- >>>>> ---------------- >>>>> 6000ae4066000000000047b303e00001 320070287360 /dev/rdsk/ >>>>> c4d0p0 >>>>> Assertion failed: h->rh_holder == pthread_self(), file ../common/ >>>>> lowlevel.c, line 126 >>>>> Abort - core dumped >>>>> >>>>> # sbdadm list-lu >>>>> >>>>> Found 3 LU(s) >>>>> >>>>> GUID DATA SIZE SOURCE >>>>> -------------------------------- ------------------- >>>>> ---------------- >>>>> 6000ae4066000000000047b303e00001 320070287360 /dev/rdsk/ >>>>> c4d0p0 >>>>> 6000ae4066000000000047b2f7080002 53687025664 /lun1 >>>>> 6000ae4066000000000047b2f6160001 1073676288 /lun0 >>>>> >>>>> # prtpart /dev/rdsk/c4d0p0 >>>>> cannot open file: Device busy >>>>> >>>>> >>>>> This message posted from opensolaris.org >>>>> _______________________________________________ >>>>> storage-discuss mailing list >>>>> [email protected] >>>>> http://mail.opensolaris.org/mailman/listinfo/storage-discuss >>>> >>>> >> >> _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
