> On Oct 17, 2017, at 6:53 AM, Daniel Kiper <daniel.ki...@oracle.com> wrote: > > On Mon, Oct 16, 2017 at 02:04:17PM -0600, Eric Snowberg wrote: >>> On Oct 16, 2017, at 2:44 AM, Daniel Kiper <daniel.ki...@oracle.com> wrote: > > [...] > >>> I am a bit surprised that you are not able to quote a string but I will >>> give you some examples: >>> >>> "/pci@306/pci@1/LSI\,mrsas@0/disk@0\,0" >>> '/pci@306/pci@1/LSI\,mrsas@0/disk@0\,0’ >>> /pci@306/pci@1/LSI\\,mrsas@0/disk@0\\,0 >> >> I just tried all three combinations above, none of which worked. >> All failed within the disk open during boot. > > Really??? Have you tried __EXACTLY__ those listed above? At least > one should work. Try them with echo command. In all cases you should > see on the console: /pci@306/pci@1/LSI\,mrsas@0/disk@0\,0 > No more no less.
AFAIU the search.fs_uuid doesn’t show up in the console. The console comes up too late in the boot. It is embedded into the core.img. I verified they were quoted as you stated above with hexdump. I did need to add the necessary ieee1275/ in front of the disk name so they get routed to the correct driver. The open failed for each case. Something is transforming them that I haven’t found yet. I started looking at just having grub-install embed something like (,gpt1)/grub instead of using the uuid by default. We could then pick up the disk name from OBPs /chosen/bootpath instead. > >> I’m moving on with my other patches now. If I get time in the future >> I’ll look at solving this a different way. But for the moment, trying >> to boot with search.fs_uuid does not work if a disk contains a comma. > > If you __REALLY__ tried strings listed above they should work. If they do > not then it means that search.fs_uuid further process hint somehow. Then > probably it is a bug and should be fixed. > I agree, one of many on SPARC. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
