[OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files)

Jim Klimov jimklimov at cos.ru
Wed Sep 24 07:25:43 UTC 2014


24 сентября 2014 г. 7:47:37 CEST, Tom Robinson <tom.robinson at motec.com.au> пишет:
>On 24/09/14 15:40, Tom Robinson wrote:
>> On 24/09/14 15:35, Dan McDonald wrote:
>>> On Sep 24, 2014, at 1:33 AM, Tom Robinson
><tom.robinson at motec.com.au> wrote:
>>>
>>>> Thanks Dan, I can see where you're going with that idea. Should I
>pay any attention to:
>>>>
>>>> Partition 0 of the disk has an incorrect offset
>>>> Unable to gather device information for /dev/rdsk/c4t3d0s0
>>> That is a bit disturbing.
>>>
>>> What about the other one in the mirror?  c4t2d0s0 ?
>> Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last
>according to installgrub. Is
>> the only way to tell by running installgrub? I get nervous at this
>point. Also my next maintenance
>> window will most likely not be until next week.
>>
>> In theory, installgrub shouldn't have any influence on the currently
>booted system, right?
>Ok, since c4t3d0s0 IS failing to accept the installgrub here goes:
>
># installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0
>Partition 0 of the disk has an incorrect offset
>Unable to gather device information for /dev/rdsk/c4t3d0s0
>
>and
>
># installgrub /mnt/boot/grub/stage1 /boot/grub/stage2
>/dev/rdsk/c4t3d0s0
>Partition 0 of the disk has an incorrect offset
>Unable to gather device information for /dev/rdsk/c4t3d0s0
>
>I'm still nervous about running this on my (apparently) only bootable
>disk... (c4t2d0s0)
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

One point in Dan's message was to use /mnt/.../installgrub.
Another one to consider may be differences in MBR partitioning (with one of those good old partitions being the container for your slice table and ultimately an rpool vdev).

If your system has parted - it can be revealing on a sector-by-sector sizing (and offset) comparison. Otherwise solaris fdisk can be used, though imho not so granular.

Since you have a mirror, don't discard the option of breaking it, creating a partition layout which just works for grub, and either attaching the slice back to the rpool if it remains big enough, or migrating the data (zfs-send/zfs-recv and/or rsync), and after a bootability-check - repartition and reattach the other disk. The tricky part in this quest is to retain the 'rpool' name if you make a new pool - this would probably require booting from live media, importing the new pool (maybe by GUID) as 'rpool' and exporting it.

I wrote a number of howtos and examples on the related subjects on illumos and/or OI wiki's, if you're interested.

HTH,
Jim Klimov
--
Typos courtesy of K-9 Mail on my Samsung Android


More information about the OmniOS-discuss mailing list