[OmniOS-discuss] Boot from mirrored USB?

[alka]

Sadly I cannot help to overcome this behaviour.
If one could plugin any bootable device in any slot
(sata, ide or usb) and it would bootup just like
plain old stupid DOS with the bios bootup order- 
that would be a huge improvement in handling - 
allowing " preconfigured deploy and emergency disks"

I really hope someone with more Grub knowledge
is willing to look at this item as well and help to fix it.

Gea


Am 01.11.2013 um 14:04 schrieb Jim Klimov:

> On 2013-10-31 18:28, Günther Alka wrote:
>> Only problem: currently you can only boot from usb when you plugin the
>> sticks in those ports
>> that were used during setup. It would be perfect it you may boot from
>> any usb port maybe on similar
>> mainboards. But this seems a Grub restriction where the physical
>> bootdevice is hardcoded during setup.
> 
> This is also a problem in other cases, such as attempts to switch from
> LegacyIDE to SATA on the motherboard. In my case on a laptop, booting
> from USB causes the SATA devices to be enumerated differently than if
> I boot from a SATA disk, so legacy-ide is the only practically working
> option :(
> 
> My research into the problem led me to believe that it is possible to
> code a different solution into the bootloader and rpool-importer, but
> my attempts to complete this have stalled :(
> 
> I may be wrong (some time has passed) but somewhere here:
> http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libgrubmgmt/common/libgrub_fs.c
> ...grub locates the "physpath" strings from the rpool-component labels
> and passes these strings to the kernel (as well as the rootfs dataset
> by number, not name).
> 
> Then in zfs_mountroot() at
> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/zfs_vfsops.c
> the booted kernel tries to mount the provided device path - which
> fails due to renamed devices.
> 
> I tried to make GRUB also detect and pass the GUID of the pool for the
> process to fall back in case of absent devices, and this required to
> implement appropriate ascii_to_uint64() and/or ascii_to_uint64_hex(),
> and the opposite functions in both GRUB and ZFS, as well as to figure
> out the proper use of nvlists and spa_import_rootpool() and stuff like
> that. In short, this seemed like an easy quest for someone who knows
> their way around the ZFS code, but I was blind there and did fail.
> I believe the GUID value passing from GRUB to kernel worked (but not
> completely certain of that though), and mounting of an rpool by GUID
> apparently did not succeed, and then I had other pressing quests :(
> If anyone is interested to pick up, I can share the diffs of what
> I did though :)
> 
> HTH,
> //Jim Klimov
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20131101/740a52b9/attachment.html>