On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans <kev...@freebsd.org> wrote:
> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor <lis...@club.fr> > wrote: > > Le 20/02/2018 à 22:45, Kyle Evans a écrit : > >> > >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor < > lis...@club.fr> > >> wrote: > >>> > >>> [... snip ...] > >>> > >>> Moreover, the "boot [kernel]" loader command does not work: > >>> > >>> OK ls /boot/kernel.old/kernel > >>> /boot/kernel.old/kernel > >>> OK boot kernel.old > >>> Command failed > >>> OK boot /boot/kernel.old/kernel > >>> Command failed > >>> OK boot kernel > >>> Command failed > >>> > >>> On the other hand, just "boot" works. > >>> > >> > >> This part should work as expected as of r329674, so please give that a > >> shot. I'm still trying to see if I can reproduce your box drawing > >> problem. > >> > >> Thanks, > >> > >> Kyle Evans > >> > > > > Thanks Kyle. > > > > boot command works now. There is though a somewhat strangely formulated > > messages when trying to load an non-existent kernel: > > > > OK boot fake > > Failed to load kernel ’fake’ > > Failed to load any kernel > > can’t load ’kernel’ > > > > The two last lines are odd: Did the loader try to load a fallback kernel > and > > failed? That would explain the ’kernel’ name in quotes, but I have such a > > kernel… Also, just nitpicking, but "can’t" should be capitalized. > > (CC'ing Rod, since he also commented on this) > > I'm only directly responsible for the first two messages. =) I've > removed the second one, though, since it was a carry-over from when it > would try to load the selected kernel and then some default kernel > that might be in your module_path. > > We can look at changing "can't load 'kernel'" to capitalize and remove > the contraction, but that's common loader stuff and should've also > been displayed for the same Forth scenario. > > > Then, I have just remembered why I was seeing a higher resolution menu > > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new > > loader is not implementing the inclusion of this file, because I can > change > > the gop mode in the loader with 'gop set [0-3]'. > > > > Oy. This is actually a Forth file, so we can't really maintain all of > the functionality that would have been allowed there. Technically, > things like this should probably either appear in your loader.conf(5) > in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is > read, or we should provide some other means of running pure loader > command scripts at different points in the loader sequence. (CC > Warner, because he probably has thoughts about this latter idea) > While loader.rc is FORTH, it's contrived FORTH designed to look like command line interaction. While some crazy people like me have actual forth in these, most do not, really (apart from the include /boot/XXX.4th lines, that is, which could be filtered). We have two choices here: Try to provide some level of compatibility shims, or provide a new way to say these things in Lua. In the original SoC code, loader.lua lived in /boot and looked to be something that people could modify. We likely need to do something similar. loader.lua right now has nothing but were in the forth world called 'include' and then very similar commands to the forth loader.rc. Perhaps the right answer is to move cli_execute out of /boot/lua/loader.lua, move that file up, and add the try-include functionality to try to include a loader.local.lua. Then we could tell people to move to the Lua syntax way of doing things. We'd have to hunt down all the hacks like this, but that wouldn't be terrible. Bonus points if we could convert the common ones either to lua code automatically, or to loader.conf variables. This specific example should have always been a loader.conf variable (and not an exec). While the gop command is useful, the loader should have, as part of it's forth sequence, had something that would set the GOP mode if the uefi_gop_mode loader.conf variable was set (I get why that wasn't done that way in the forth loader, insert rant of Fear of FORTH here). So we should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few other things that are simple settings to make it easier for users to set this stuff up and start to move away from the FoF kludges that we've accumulated. A new loader.conf variable would also allow coexistence of the two loaders, which will be further helped with some patches I have to the build system coming soon. Warner _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
