[OmniOS-discuss] OmniOS r151022 is now out!
Dominik Hassler
hasslerd at gmx.li
Tue May 16 13:53:05 UTC 2017
Ok, I did an installboot -mFf on both disks again (-v is not available
for installboot)
$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
/dev/rdsk/c9t5000CCA04103E0B5d0s0
bootblock written for /dev/rdsk/c9t5000CCA04103E0B5d0s0, 223 sectors
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector
$ sudo installboot -mFf /boot/pmbr /boot/gptzfsboot
/dev/rdsk/c10t5000CCA04103E095d0s0
bootblock written for /dev/rdsk/c10t5000CCA04103E095d0s0, 223 sectors
starting at 1024 (abs 33154)
stage1 written to slice 1 sector 0 (abs 16065)
stage1 written to master boot sector
checked the version:
$ installboot -i /boot/gptzfsboot
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
and compared it to the version of both disks:
$ sudo installboot -i /dev/rdsk/c9t5000CCA04103E0B5d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
$ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
Extended version string: 1.1-2017.4.23.2
MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
everything matches, but still the system boots only from one disk and
not the other. Since it is not the latest version you mentioned I'll
just wait until it is updated I guess. I can at least boot from one disk
so I am not too worried about it at the moment. Still I would prefer to
be able to boot from both.
On 05/16/2017 03:18 PM, Toomas Soome wrote:
>
>> On 16. mai 2017, at 15:58, Dominik Hassler <hasslerd at gmx.li> wrote:
>>
>> Toomas,
>>
>> using a (forced) installboot on both rpool mirror devices did the trick. Loader is now being used.
>>
>> However there is another problem. I can boot w/o problems from the first device. But booting fails from the second device w/ the following message:
>>
>> Can't find /boot/zfsloader
>>
>> illumos/x86 boot
>> Default: disk-1:/boot/zfsloader
>
> Somehow the MBR on second disk is not properly updated and I think it has wrong size recorded for stage2.
>
> The initial installboot was implemented based on installgrub source and we record the LBA with gptzfsboot start sector, and size (in sectors) into MBR.
>
> Now the copy of the MBR (the /boot/pmbr file) is also installed into partition start sector 0), and when the beadm activate is run, the boot blocks are updates, but with same logic, that with MBR+VTOC case, the MBR itself is not updated (to keep multi boot setups safe), and only partition sector 0 and stage 2 are updated. The oversight is that the MBR is loading stage2 directly, and if the gptzfsboot size was changed, the result is that not the entire gptzfsboot is read into the memory and resulting with just the output as you can see.
>
> later we did create the fix for installboot - the fixed installboot will only record the location and size (1 sector) of the partition boot recors (partition relative sector 0), and after that the MBR code will read in the partition block, the partition block will read the stage2, and so the MBR+VTOC case is not an issue any more.
>
> to fix this, run installboot -mFfv against that second disk to ensure the MBR block is properly updated - note the -v again, so you can confirm the MBR and partition block and stage2 are all updated.
>
> With installgrub we actually have the same issue, except, the grub stage2 size virtually did not change and thats why the problem was never revealed.
>
> note, if your installboot command does allow to read the version from /boot/gptzfsboot like that:
>
> $ installboot -i /boot/gptzfsboot
> Extended version string: 1.1-2017.5.6.2
> MD5 hash: 2907581de9ca6bd4d2c12695a32cb749
>
> then it has the bug fixed, and after installing MBR with such binary, the MBR is always reading the sector 0 from partition start, and the future updates are ok.
>
> also note that MBR is always updated with GPT, and hence there the issue does not appear (which why it took some time to notice it - my own test systems were all using GPT:)
>
> rgds,
> toomas
>
>> boot:
>>
>>
>> Debug info below:
>>
>> $ sudo installboot -i /dev/rdsk/c10t5000CCA04103E095d0s0
>> Extended version string: 1.1-2017.4.23.2
>> MD5 hash: 766b5059c45796f049bb38b80e1a1c4d
>>
>> same on both devices
>>
>>
>> $ sudo format -> select disk -> fdisk
>> Total disk size is 36481 cylinders
>> Cylinder size is 16065 (512 byte) blocks
>>
>> Cylinders
>> Partition Status Type Start End Length %
>> ========= ====== ============ ===== === ====== ===
>> 1 Active Solaris2 1 36480 36480 100
>>
>> same on both devices
>>
>>
>> $ sudo prtvtoc /dev/rdsk/c10t5000CCA04103E095d0s2
>> * /dev/rdsk/c10t5000CCA04103E095d0s2 partition map
>> *
>> * Dimensions:
>> * 512 bytes/sector
>> * 63 sectors/track
>> * 255 tracks/cylinder
>> * 16065 sectors/cylinder
>> * 36480 cylinders
>> * 36478 accessible cylinders
>> *
>> * Flags:
>> * 1: unmountable
>> * 10: read-only
>> *
>> * Unallocated space:
>> * First Sector Last
>> * Sector Count Sector
>> * 0 16065 16064
>> *
>> * First Sector Last
>> * Partition Tag Flags Sector Count Sector Mount Directory
>> 0 2 00 16065 586003005 586019069
>> 2 5 01 0 586051200 586051199
>> 8 1 01 0 16065 16064
>>
>>
>> same on both devices
>>
>>
>> boot: status
>> Default: disk-1:/boot/zfsloader
>> boot: statusdisk devices:
>> disk0: BIOS drive C ...
>> disk0a: root
>> disk0i: boot
>> disk1: BIOS drive D ...
>> disk1s1: Solaris 2
>> disk1s1a: root
>> disk1s1i: boot
>> ....
>> zfs devices:
>> pool: rpool
>> bootfs: rpool/ROOT/omnios-r151022
>> config:
>>
>> NAME STATE
>> rpool DEGRADED
>> mirror DEGRADED
>> c9t5000CCA04103E0B5d0s2 ONLINE
>> c10t5000CCA04103E095d0s0 OFFLINE
>>
>> illumos/x86 boot
>> Default: disk-1:/boot/zfsloader
>> boot:
>>
>>
>> Any hints on how to get the system boot from both rpool devices are highly appreciated.
>>
>>
>> Kind regards,
>> Dominik
>>
>> On 05/15/2017 08:40 PM, Toomas Soome wrote:
>>>
>>>> On 15. mai 2017, at 21:06, Dan McDonald <danmcd at omniti.com> wrote:
>>>>
>>>>
>>>>> On May 15, 2017, at 12:49 PM, Dominik Hassler <hasslerd at gmx.li> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> after the upgrade, the boot loader is still GRUB.
>>>>>
>>>>> I did the upgrade according to the upgrade notes. Rebooted once, did a:
>>>>>
>>>>> $ sudo beadm activate omnios-r151022
>>>>> WARNING: menu.lst file /rpool/boot/menu.lst does not exist,
>>>>> generating a new menu.lst file
>>>>> Activated successfully
>>>>>
>>>>> checked for a /etc/default/be file. there is none. Still the boot loader is GRUB instead of loader.
>>>>
>>>> Are you on a mirrored root pool? It's possible the libbe code that installs loader doesn't do it to all disks in a mirrored pool...
>>>>
>>>> Worst-case scenario is to explicitly install it:
>>>>
>>>> foreach (drive)
>>>> installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/<drive>
>>>>
>>>> Dan
>>>>
>>>
>>> The problem you have is that beadm activate does not enforce MBR update in case of MBR+VTOC partitioning; you need to either run bootadm install-bootloader -Mfv or installboot -mv.
>>>
>>> Note that installboot and bootadm install-bootloader have slightly different flags; -v is good to have there, so you will see if the MBR was updated or not.
>>>
>>> The beadm activate and bootadm use the same mechanism to update the bootblocks on all pool member disks, bootadm does have extra flag to allow MBR update. installboot does only update specified disk.
>>>
>>> rgds,
>>> toomas
>>>
>
More information about the OmniOS-discuss
mailing list