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@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss