Moritz Willers wrote:
> It's been a while, but with all those hints (thanks!) and the biosdev 
> source I managed to understand that my bios is not doing EDD and biosdev 
> resorts to trying to figure which disk maps to which as reported by the 
> bios, by comparing the first block on the disk with the same as given 
> through bios dev data.  If the first block is the same on all disks it 
> fails,  making the fdisk info different on all disks helps the mapping 
> process.
> 
> After making the fdisk info different, biosdev reported the boot device 
> as being my "second" disk
> 
> 0x81 /pci at 0,0/pci-ide at 8/ide at 0/cmdk at 0,0
> 
> but as mentioned elsewhere that's no good as lucreate is explicitly 
> looking for 0x80.   Using the same workaround as mentioned in 
> http://www.opensolaris.org/jive/thread.jspa?messageID=38932 I finally 
> had success and was able to lucreate and live upgrade.
> 
> But ... this really isn't quite straight forward, is it? ... trying to 
> live upgrade again I now get a new error and lucreate refuses to run in 
> a different way:
> 
> wicked# lustatus
> Boot Environment           Is       Active Active    Can    Copy
> Name                       Complete Now    On Reboot Delete Status
> -------------------------- -------- ------ --------- ------ ----------
> snv_40                     yes      yes    yes       no     -
> wicked# lucreate -n snv_45 -m /:d30:ufs,preserve
> Discovering physical storage devices
> Discovering logical storage devices
> Cross referencing storage devices with boot environment configurations
> Determining types of file systems supported
> Validating file system requests
> The device name <d30> expands to device path </dev/md/dsk/d30>
> ...
> Updating boot environment description database on all BEs.
> Searching /dev for possible boot environment filesystem devices
> 
> ERROR: Mirror </dev/md/dsk/d30> submirror </dev/md/rdsk/d20> is not 
> single disk stripe.
> ERROR: Cannot determine boot device for Solaris Volume Manager 
> metadevice</dev/md/dsk/d30>.
> The only metadevices that support the root file system
> are a stripe with only a single disk or a mirror on a single-disk stripe.
> 
> wicked# metastat -p d30
> d30 -m /dev/md/rdsk/d20 1
> d20 1 1 /dev/rdsk/c1d0s0
> 
> d20 used to a submirror of d40:
> 
> wicked% df /
> /                  (/dev/md/dsk/d40   ):17274886 blocks  1184609 files
> wicked% metastat -p d40
> d40 -m /dev/md/rdsk/d10 1
> d10 1 1 /dev/rdsk/c2d0s0
> wicked%
> 
> Why does it claim that d30 is not a single-disk stripe? (and why did it 
> work just fine before?)
> 

I'm not sure why it's not working, that should be detected correctly; 
when you say it worked fine before, what build was that?

> Any chance the source to liveupgrade will be put out into the open, so I 
> wouldn't have to dig in the dark with closed binaries trying to upgrade 
> my otherwise open source system?
> 

You can try setting the environment variable LU_DEBUG to some integer 
value and see what additional info you can get out of it.

As for the open-sourcing, well, we're working on the rest of the install 
consolidation, but I do not expect that we'll be able to open-source 
Live Upgrade.

Dave

Reply via email to