So I have an SXCE (Nevada) based paravirtual guest with a UFS root. I decided to attach another virtual disk to the guest and use LiveUpgrade to update it to the latest Nevada build. That all went pretty smoothly. I then tried to luactivate the new boot environment, and then issued an init 6 to reboot, expecting (or hoping) that it would boot into this new boot environment. Unfortunately it did not. I just booted back into the original boot environment. So I''m looking for tips on how to get Xen to boot the guest from this new disk. I think it would probably be pretty painful to just change the disk definition from xvdc to xvda, since that would effectively change the device assignment from c0t2d0 to c0t0d0 which will cause problems finding root and such since vfstab for one has entries for the former. Is there a magic virsh or xm domain config tweak that I am missing? I did notice that xm list -l domain didn''t show the new disk as bootable. I don''t know whether that is the first problem or not. Pointers to documentation would be helpful. Thanks. --joe
On Wed, Jun 03, 2009 at 10:05:58AM -0700, Joseph Mocker wrote:> Unfortunately it did not. I just booted back into the original bootRight: there''s no way for the OS to communicate which of the disks is the boot disk (only which slice, BE, etc.)> I think it would probably be pretty painful to just change the disk > definition from xvdc to xvda, since that would effectively change the > device assignment from c0t2d0 to c0t0d0 which will cause problems > finding root and such since vfstab for one has entries for the former.The solution is surprisingly dumb: simply list the disk first! A golden-oldie talks a little bit about this: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6537397 6537397 pygrub should look for the disk numbered ''0'' not the first listed. I''m updating the bug now... regards john
LOL. I wondered if that could be it for a second then dismissed it. Just tried it, it worked. Thanks! --joe John Levon wrote:> On Wed, Jun 03, 2009 at 10:05:58AM -0700, Joseph Mocker wrote: > > >> Unfortunately it did not. I just booted back into the original boot >> > > Right: there''s no way for the OS to communicate which of the disks is > the boot disk (only which slice, BE, etc.) > > >> I think it would probably be pretty painful to just change the disk >> definition from xvdc to xvda, since that would effectively change the >> device assignment from c0t2d0 to c0t0d0 which will cause problems >> finding root and such since vfstab for one has entries for the former. >> > > The solution is surprisingly dumb: simply list the disk first! > > A golden-oldie talks a little bit about this: > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6537397 > 6537397 pygrub should look for the disk numbered ''0'' not the first listed. > > I''m updating the bug now... > > regards > john >