On Thu, Jun 26, 2008 at 4:06 PM, Ethan Quach <[EMAIL PROTECTED]> wrote:
>
>
> Henry Jen wrote:
>>
>> On Thu, Jun 26, 2008 at 3:19 PM, Ethan Quach <[EMAIL PROTECTED]> wrote:
>>>
>>> Henry Jen wrote:
>>>>
>>>> On Thu, Jun 26, 2008 at 10:18 AM, Ethan Quach <[EMAIL PROTECTED]
>>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>>
>>>>
>>>>   Henry Jen wrote:
>>>>
>>>> $ beadm list
>>>>
>>>> BE            Active Active on Mountpoint Space
>>>> Name                 reboot               Used
>>>> ----          ------ --------- ---------- -----
>>>> opensolaris   yes    yes       legacy     5.11G
>>>> opensolaris-1 no     yes       -          5.10G
>>>>  After reboot, GRUB does not show up, and boot into OpenSolaris with a
>>>> keystroke.
>>>
>>> So is 'osol' on c4d0s3 and 'pool' on c4d0s7?
>>>
>>
>> Yes.
>>
>>> beadm doesn't support multiple pools yet, so having a BE on
>>> that second 'osol' pool there will confuse beadm for certain
>>> operations. (Like how it shows two BEs as 'Active on reboot')
>>> If possible, you should delete the BE on 'osol' (since its the
>>> smaller pool), and just continue to use 'pool' for your BEs.
>>> This would mean you need to copy the menu.lst into
>>> /pool/boot/grub/menu.lst and installgrub onto it.
>>>
>>
>> osol is the pool converted from an old slice for LU BE to which I
>> installed OpenSolaris 2008.05.
>> pool is an old pool used for /export.
>>
>> I don't recall why I didn't add the slice into existing pool, probably
>> because I cannot.
>
> Well, you can, but I would highly suggest not to.  Using two vdevs
> from the same disk to stripe a pool adversely affects zfs performance.
> zfs will think both vdevs are on two different disks and will try
> to optimize.  This obviously doesn't work too well since both vdevs
> share the same seek heads, etc.
>

Uh, that's why. :-)

>> Do I only need to copy menu.lst or everything in
>> there?
>
> No, just the menu.lst is all that's needed in the pool's
> pool dataset (i.e. the top level dataset of the root pool)
>
>> As I mentioned, the GRUB does not function properly with
>> display.
>
> There is a bug where if the splashimage specified in the
> menu.lst cannot be found in the root dataset that's being
> booted (the dataset set as 'bootfs' in the pool property list),
> the GRUB menu shows up as blank.
>
> Which pool is being booted?
>
> What is the 'bootfs' property of that pool?
> (zfs get bootfs <poolname>)
>

Both pool shows:

bad property list: invalid property 'bootfs'
usage:
        get [-rHp] [-o field[,...]] [-s source[,...]]
            <"all" | property[,...]> [filesystem|volume|snapshot] ...


With 'zfs get bootfs:', noted the colon, it says:

NAME  PROPERTY  VALUE    SOURCE
pool  bootfs:   -        -

> What is listed as the splashimage in your menu.lst of
> the pool that's being booted.
>

splashimage /boot/grub/splash.xpm.gz

Attached is the menu.lst file.

Cheers,
Henry

Attachment: menu.lst
Description: Binary data

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to