Re: LUA boot loader coming very soon

[Manfred Antar]

> On Aug 20, 2018, at 10:47 AM, Kyle Evans  wrote:
> 
> On Mon, Aug 20, 2018 at 12:44 PM, Manfred Antar  
> wrote:
>> 
>> 
>>> On Aug 20, 2018, at 9:20 AM, Warner Losh  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans  wrote:
>>> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar  
>>> wrote:
 Hi
 How do i get the menu back after switching to LUA loader?
 I’m using a comconsole. Before the switch to LUA I had a menu and a little 
 devil with pitchfork:)
 Now just get the countdown from 10 , then boot.
 Here is my loader.conf.local:
 
 console="comconsole"
 beastie_disable="NO"
 hw.vga.textmode=1
 kern.vt.spclkeys=15
 nvidia_load="YES"
 linux_common_load="YES"
 linux_load="YES"
 linprocfs_load="YES"
 linsysfs_load=“YES"
 
>>> 
>>> Hmm... seems that there was a miscommunication at some point, and the
>>> menu is disabled explicitly on serial boots. console="comconsole" is
>>> enough to disable this in lualoader land. An excerpt from an e-mail I
>>> was forwarded regarding this:
>>> 
>>> if $console contains (space or comma separated) "efi" then do
>>> not draw a menu (fall back to autoboot routine).
>>> 
>>> if $beastie_disable is set to "YES" (case insensitive), then do not
>>> draw a menu (fall back to autoboot routine).
>>> 
>>> We are clearly doing this wrong. I will fix it ASAP.
>>> 
>>> I think that we need  https://reviews.freebsd.org/D16816 to fix all the 
>>> bits.
>>> 
>>> Warner
>> 
>> Ok that works
>> I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, 
>> otherwise just have devilhead.
>> 
>> drawer.default_color_logodef = 'orb'
>> drawer.default_bw_logodef = ‘orbbw'
>> 
>> to:
>> 
>> drawer.default_color_logodef = 'beastie'
>> drawer.default_bw_logodef = ‘beastiebw'
>> 
>> and it’s pretty much the same as the 4th menu i had before.
>> Is there a way to put:
>> 
>> drawer.default_color_logodef = 'beastie'
>> drawer.default_bw_logodef = 'beastiebw'
>> 
>> somewhere else ie loader.rc or loader.lua.local so I don’t have to edit the 
>> /boot/lua/drawer.lua everytime I rebuild world?
>> It doesn’t work to put in loader.conf.local
> 
> In loader.conf(5) land, this is called "loader_logo"
> 
> e.g. loader_logo=“beastie"

I got it now.
I was putting the wrong line in loader.conf.local
loader_logo works!!
Thanks

___
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"

Re: LUA boot loader coming very soon

[Kyle Evans]

On Mon, Aug 20, 2018 at 12:44 PM, Manfred Antar  wrote:
>
>
>> On Aug 20, 2018, at 9:20 AM, Warner Losh  wrote:
>>
>>
>>
>> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans  wrote:
>> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar  
>> wrote:
>> > Hi
>> > How do i get the menu back after switching to LUA loader?
>> > I’m using a comconsole. Before the switch to LUA I had a menu and a little 
>> > devil with pitchfork:)
>> > Now just get the countdown from 10 , then boot.
>> > Here is my loader.conf.local:
>> >
>> > console="comconsole"
>> > beastie_disable="NO"
>> > hw.vga.textmode=1
>> > kern.vt.spclkeys=15
>> > nvidia_load="YES"
>> > linux_common_load="YES"
>> > linux_load="YES"
>> > linprocfs_load="YES"
>> > linsysfs_load=“YES"
>> >
>>
>> Hmm... seems that there was a miscommunication at some point, and the
>> menu is disabled explicitly on serial boots. console="comconsole" is
>> enough to disable this in lualoader land. An excerpt from an e-mail I
>> was forwarded regarding this:
>>
>> if $console contains (space or comma separated) "efi" then do
>> not draw a menu (fall back to autoboot routine).
>>
>> if $beastie_disable is set to "YES" (case insensitive), then do not
>> draw a menu (fall back to autoboot routine).
>>
>> We are clearly doing this wrong. I will fix it ASAP.
>>
>> I think that we need  https://reviews.freebsd.org/D16816 to fix all the bits.
>>
>> Warner
>
> Ok that works
> I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, otherwise 
> just have devilhead.
>
> drawer.default_color_logodef = 'orb'
> drawer.default_bw_logodef = ‘orbbw'
>
> to:
>
> drawer.default_color_logodef = 'beastie'
> drawer.default_bw_logodef = ‘beastiebw'
>
> and it’s pretty much the same as the 4th menu i had before.
> Is there a way to put:
>
> drawer.default_color_logodef = 'beastie'
> drawer.default_bw_logodef = 'beastiebw'
>
> somewhere else ie loader.rc or loader.lua.local so I don’t have to edit the 
> /boot/lua/drawer.lua everytime I rebuild world?
> It doesn’t work to put in loader.conf.local

In loader.conf(5) land, this is called "loader_logo"

e.g. loader_logo="beastie"

Thanks,

Kyle Evans
___
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"

Re: LUA boot loader coming very soon

[Manfred Antar]

> On Aug 20, 2018, at 9:20 AM, Warner Losh  wrote:
> 
> 
> 
> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans  wrote:
> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar  
> wrote:
> > Hi
> > How do i get the menu back after switching to LUA loader?
> > I’m using a comconsole. Before the switch to LUA I had a menu and a little 
> > devil with pitchfork:)
> > Now just get the countdown from 10 , then boot.
> > Here is my loader.conf.local:
> >
> > console="comconsole"
> > beastie_disable="NO"
> > hw.vga.textmode=1
> > kern.vt.spclkeys=15
> > nvidia_load="YES"
> > linux_common_load="YES"
> > linux_load="YES"
> > linprocfs_load="YES"
> > linsysfs_load=“YES"
> >
> 
> Hmm... seems that there was a miscommunication at some point, and the
> menu is disabled explicitly on serial boots. console="comconsole" is
> enough to disable this in lualoader land. An excerpt from an e-mail I
> was forwarded regarding this:
> 
> if $console contains (space or comma separated) "efi" then do
> not draw a menu (fall back to autoboot routine).
> 
> if $beastie_disable is set to "YES" (case insensitive), then do not
> draw a menu (fall back to autoboot routine).
> 
> We are clearly doing this wrong. I will fix it ASAP.
> 
> I think that we need  https://reviews.freebsd.org/D16816 to fix all the bits.
> 
> Warner 

Ok that works
I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, otherwise 
just have devilhead.

drawer.default_color_logodef = 'orb'
drawer.default_bw_logodef = ‘orbbw'

to:

drawer.default_color_logodef = 'beastie'
drawer.default_bw_logodef = ‘beastiebw'

and it’s pretty much the same as the 4th menu i had before.
Is there a way to put:

drawer.default_color_logodef = 'beastie'
drawer.default_bw_logodef = 'beastiebw'

somewhere else ie loader.rc or loader.lua.local so I don’t have to edit the 
/boot/lua/drawer.lua everytime I rebuild world?
It doesn’t work to put in loader.conf.local
Thanks
Manfred
___
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"

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans  wrote:

> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar 
> wrote:
> > Hi
> > How do i get the menu back after switching to LUA loader?
> > I’m using a comconsole. Before the switch to LUA I had a menu and a
> little devil with pitchfork:)
> > Now just get the countdown from 10 , then boot.
> > Here is my loader.conf.local:
> >
> > console="comconsole"
> > beastie_disable="NO"
> > hw.vga.textmode=1
> > kern.vt.spclkeys=15
> > nvidia_load="YES"
> > linux_common_load="YES"
> > linux_load="YES"
> > linprocfs_load="YES"
> > linsysfs_load=“YES"
> >
>
> Hmm... seems that there was a miscommunication at some point, and the
> menu is disabled explicitly on serial boots. console="comconsole" is
> enough to disable this in lualoader land. An excerpt from an e-mail I
> was forwarded regarding this:
>
> if $console contains (space or comma separated) "efi" then do
> not draw a menu (fall back to autoboot routine).
>
> if $beastie_disable is set to "YES" (case insensitive), then do not
> draw a menu (fall back to autoboot routine).
>
> We are clearly doing this wrong. I will fix it ASAP.
>

I think that we need  https://reviews.freebsd.org/D16816 to fix all the
bits.

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"

Re: LUA boot loader coming very soon

[Kyle Evans]

On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar  wrote:
> Hi
> How do i get the menu back after switching to LUA loader?
> I’m using a comconsole. Before the switch to LUA I had a menu and a little 
> devil with pitchfork:)
> Now just get the countdown from 10 , then boot.
> Here is my loader.conf.local:
>
> console="comconsole"
> beastie_disable="NO"
> hw.vga.textmode=1
> kern.vt.spclkeys=15
> nvidia_load="YES"
> linux_common_load="YES"
> linux_load="YES"
> linprocfs_load="YES"
> linsysfs_load=“YES"
>

Hmm... seems that there was a miscommunication at some point, and the
menu is disabled explicitly on serial boots. console="comconsole" is
enough to disable this in lualoader land. An excerpt from an e-mail I
was forwarded regarding this:

if $console contains (space or comma separated) "efi" then do
not draw a menu (fall back to autoboot routine).

if $beastie_disable is set to "YES" (case insensitive), then do not
draw a menu (fall back to autoboot routine).

We are clearly doing this wrong. I will fix it ASAP.

Thanks,

Kyle Evans
___
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"

Re: LUA boot loader coming very soon

[Manfred Antar]

Hi
How do i get the menu back after switching to LUA loader?
I’m using a comconsole. Before the switch to LUA I had a menu and a little 
devil with pitchfork:)
Now just get the countdown from 10 , then boot.
Here is my loader.conf.local:

console="comconsole"
beastie_disable="NO"
hw.vga.textmode=1
kern.vt.spclkeys=15
nvidia_load="YES"
linux_common_load="YES"
linux_load="YES"
linprocfs_load="YES"
linsysfs_load=“YES"

I also had a loader.rc file but it does not seem relevant to LUA:

\ Loader.rc
\ $FreeBSD: head/stand/i386/loader/loader.rc 332413 2018-04-11 18:02:13Z imp $
\
\ Includes additional commands
include /boot/loader.4th
include /boot/efi.4th
try-include /boot/loader.rc.local

\ Reads and processes loader.conf variables
initialize

maybe-efi-resizecons

\ Tests for password -- executes autoboot first if a password was defined
check-password

\ Load in the boot menu
include /boot/beastie.4th

\ Start the boot menu
beastie-start

Thanks
Manfred
___
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"

Re: LUA boot loader coming very soon

[David Wolfskill]

Also, after reverting r329225, I was able to build & boot the build
machine with the Lua loader... but I didn't even see any way of
interacting with it on the serial console.  (I do get that opportunity
with the Forth loader.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: LUA boot loader coming very soon

[David Wolfskill]

On Mon, Feb 12, 2018 at 08:27:27AM -0700, Warner Losh wrote:
> ...
> So please give it a spin and give me any feedback, documentation updates
> and/or bug fixes. I'm especially interested in reviews from people that
> have embedded Lua in other projects or experts in Lua that can improve the
> robustness of the menu code.
> 

I was able to build, install, and (start to -- not loader's fault)
boot my laptop; I have placed screenshots at
.

Some notes:
* For loader_1_lua.jpg, I had (reflexively) already hit "v" to boot
  verbosely, so "Verbose:On" does NOT reflect the default.  On the
  other hand, "ACPI   :off" DOES reflect the default, which is
  opposite from the Forth loader (ref. loader_1_4th.jpg); I suspect that
  this warrants changing.

* The lower left corner of the box seems to have an odd artifact for the
  Lua loader.  I haven't looked, but suspect it will be easy to fix.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Feb 12, 2018 at 2:53 PM, John Baldwin  wrote:

> On Monday, February 12, 2018 02:31:46 PM Warner Losh wrote:
> > On Mon, Feb 12, 2018 at 10:12 AM, John Baldwin  wrote:
> >
> > > On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote:
> > > > Greetings,
> > > >
> > > > As you may know, the Lua (http://www.lua.org) boot loader has been
> in
> > > the
> > > > works for some time. It started out life as a GSoC in 2014 by Pedro
> Souza
> > > > mentored by Wojciech A. Koszek. Rui Paulo created a svn project
> branch to
> > > > try to integrate it. I rebased that effort into a github branch which
> > > Pedro
> > > > Arthur fixed up. Over the past year, I've been cleaning up the boot
> > > loader
> > > > for other reasons, and found the time was ripe to start integrating
> this
> > > > into the tree. However, those integration efforts have taken a while
> as
> > > my
> > > > day-job work on the boot loader took priority. In the mean time, Ed
> Maste
> > > > and the FreeBSD Foundation funded Zakary Nafziger to enhance the
> original
> > > > GSoC Lua scripts to bring it closer to parity with the evolution of
> the
> > > > FORTH menu system since the GSoC project started.
> > > >
> > > > I'm pleased to announce that all these threads of development have
> > > > converged and I'll be pushing the FreeBSD Lua Loader later today.
> This
> > > > loader uses Lua as its scripting language instead of FORTH. While
> > > > co-existance is planned, the timeline for it is looking to be a few
> weeks
> > > > and I didn't want to delay pushing this into the tree for that.
> > > >
> > > > To try the loader, you'll need to build WITHOUT_FORTH=yes and
> > > > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do
> this,
> > > > you can do it in src/stand and install the result (be sure to have
> the
> > > > options for both the build and the install). This will replace your
> > > current
> > > > /boot/loader that is scripted with FORTH to one that's scripted with
> Lua.
> > > > It will install the lua scripts in /boot/lua. The boot is scripted
> with
> > > > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly
> advised
> > > > to create a backup copy of /boot/loader before testing (eg cp
> > > /boot/loader
> > > > /boot/loader_forth), since you'll need to boot that from boot2 if
> > > something
> > > > goes wrong. I've tested it extensively, though, with userboot.so and
> it's
> > > > test program, so all the initial kinks of finding the lua scripts,
> etc
> > > have
> > > > been worked out.
> > > >
> > > > While it's possible to build all the /boot/loader variants with Lua,
> I've
> > > > just tested a BIOS booting /boot/loader both with and without menus
> > > > enabled. I've not tested any of the other variants and the
> instructions
> > > for
> > > > testing some of them may be rather tedious (especially UEFI, if you
> want
> > > a
> > > > simple path to back out). Since there's not been full convergence
> > > testing,
> > > > you'll almost certainly find bumps in this system. Also, all the
> > > > build-system APIs are likely not yet final.
> > > >
> > > > I put  MFC after a month on the commit. Due to the heroic (dare I say
> > > > almost crazy) work of Kyle Evans on merging all the revs from
> -current to
> > > > 11, I'm planning a MFC to 11 after the co-existence issues are
> hammered
> > > > out. In 11, FORTH will be the default, and Lua will  be built by
> default,
> > > > but users will have to do something to use it. 12, both FORTH and Lua
> > > will
> > > > be built and installed, with Lua as default (barring unforeseen
> > > > complications). Once the co-existence stuff goes in, I imagine we'll
> make
> > > > the switch to Lua by default shortly after that. In 13, FORTH will be
> > > > removed unless there's a really really compelling case made to keep
> it.
> > > >
> > > > So please give it a spin and give me any feedback, documentation
> updates
> > > > and/or bug fixes. I'm especially interested in reviews from people
> that
> > > > have embedded Lua in other projects or experts in Lua that can
> improve
> > > the
> > > > robustness of the menu code.
> > >
> > > Do you have some memory usage numbers for LUA vs forth for the
> different
> > > BIOS loaders (text/data/bss sizes)?  For the EFI case we probably have
> lots
> > > of room, but for the non-EFI case we are constrained to 0xa -
> 0xa000
> > > for the text/data/bss and stack (in some cases like PXE booting the top
> > > can be lower than 0xa).  I'm not sure if we have any other
> platforms
> > > with similar memory constraints.
> > >
> >
> > Lua is about 60-70k larger than FORTH for this application:
> >
> > Forth based:
> > -r-xr-xr-x  1 root  wheel  385024 Feb 12 14:14
> > /home/imp/roots/amd64/boot/loader
> > -r-xr-xr-x  1 root  wheel  450560 Feb 12 14:14
> > /home/imp/roots/amd64/boot/zfsloader
> > Lua based:
> > -r-xr-xr-x  1 root  wheel  450560 Feb 12 14:20
> > 

Re: LUA boot loader coming very soon

[John Baldwin]

On Monday, February 12, 2018 02:31:46 PM Warner Losh wrote:
> On Mon, Feb 12, 2018 at 10:12 AM, John Baldwin  wrote:
> 
> > On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote:
> > > Greetings,
> > >
> > > As you may know, the Lua (http://www.lua.org) boot loader has been in
> > the
> > > works for some time. It started out life as a GSoC in 2014 by Pedro Souza
> > > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to
> > > try to integrate it. I rebased that effort into a github branch which
> > Pedro
> > > Arthur fixed up. Over the past year, I've been cleaning up the boot
> > loader
> > > for other reasons, and found the time was ripe to start integrating this
> > > into the tree. However, those integration efforts have taken a while as
> > my
> > > day-job work on the boot loader took priority. In the mean time, Ed Maste
> > > and the FreeBSD Foundation funded Zakary Nafziger to enhance the original
> > > GSoC Lua scripts to bring it closer to parity with the evolution of the
> > > FORTH menu system since the GSoC project started.
> > >
> > > I'm pleased to announce that all these threads of development have
> > > converged and I'll be pushing the FreeBSD Lua Loader later today. This
> > > loader uses Lua as its scripting language instead of FORTH. While
> > > co-existance is planned, the timeline for it is looking to be a few weeks
> > > and I didn't want to delay pushing this into the tree for that.
> > >
> > > To try the loader, you'll need to build WITHOUT_FORTH=yes and
> > > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this,
> > > you can do it in src/stand and install the result (be sure to have the
> > > options for both the build and the install). This will replace your
> > current
> > > /boot/loader that is scripted with FORTH to one that's scripted with Lua.
> > > It will install the lua scripts in /boot/lua. The boot is scripted with
> > > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised
> > > to create a backup copy of /boot/loader before testing (eg cp
> > /boot/loader
> > > /boot/loader_forth), since you'll need to boot that from boot2 if
> > something
> > > goes wrong. I've tested it extensively, though, with userboot.so and it's
> > > test program, so all the initial kinks of finding the lua scripts, etc
> > have
> > > been worked out.
> > >
> > > While it's possible to build all the /boot/loader variants with Lua, I've
> > > just tested a BIOS booting /boot/loader both with and without menus
> > > enabled. I've not tested any of the other variants and the instructions
> > for
> > > testing some of them may be rather tedious (especially UEFI, if you want
> > a
> > > simple path to back out). Since there's not been full convergence
> > testing,
> > > you'll almost certainly find bumps in this system. Also, all the
> > > build-system APIs are likely not yet final.
> > >
> > > I put  MFC after a month on the commit. Due to the heroic (dare I say
> > > almost crazy) work of Kyle Evans on merging all the revs from -current to
> > > 11, I'm planning a MFC to 11 after the co-existence issues are hammered
> > > out. In 11, FORTH will be the default, and Lua will  be built by default,
> > > but users will have to do something to use it. 12, both FORTH and Lua
> > will
> > > be built and installed, with Lua as default (barring unforeseen
> > > complications). Once the co-existence stuff goes in, I imagine we'll make
> > > the switch to Lua by default shortly after that. In 13, FORTH will be
> > > removed unless there's a really really compelling case made to keep it.
> > >
> > > So please give it a spin and give me any feedback, documentation updates
> > > and/or bug fixes. I'm especially interested in reviews from people that
> > > have embedded Lua in other projects or experts in Lua that can improve
> > the
> > > robustness of the menu code.
> >
> > Do you have some memory usage numbers for LUA vs forth for the different
> > BIOS loaders (text/data/bss sizes)?  For the EFI case we probably have lots
> > of room, but for the non-EFI case we are constrained to 0xa - 0xa000
> > for the text/data/bss and stack (in some cases like PXE booting the top
> > can be lower than 0xa).  I'm not sure if we have any other platforms
> > with similar memory constraints.
> >
> 
> Lua is about 60-70k larger than FORTH for this application:
> 
> Forth based:
> -r-xr-xr-x  1 root  wheel  385024 Feb 12 14:14
> /home/imp/roots/amd64/boot/loader
> -r-xr-xr-x  1 root  wheel  450560 Feb 12 14:14
> /home/imp/roots/amd64/boot/zfsloader
> Lua based:
> -r-xr-xr-x  1 root  wheel  450560 Feb 12 14:20
> /home/imp/roots/amd64/boot/loader
> -r-xr-xr-x  1 root  wheel  520192 Feb 12 14:20
> /home/imp/roots/amd64/boot/zfsloader
> 
> So with Lua:
> %  size loader.bin
> textdata bss  dec   hex   filename
>   411840   22264   48304   482408   0x75c68   loader.bin
> % size zfsloader.bin
> textdata bss 

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Feb 12, 2018 at 10:12 AM, John Baldwin  wrote:

> On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote:
> > Greetings,
> >
> > As you may know, the Lua (http://www.lua.org) boot loader has been in
> the
> > works for some time. It started out life as a GSoC in 2014 by Pedro Souza
> > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to
> > try to integrate it. I rebased that effort into a github branch which
> Pedro
> > Arthur fixed up. Over the past year, I've been cleaning up the boot
> loader
> > for other reasons, and found the time was ripe to start integrating this
> > into the tree. However, those integration efforts have taken a while as
> my
> > day-job work on the boot loader took priority. In the mean time, Ed Maste
> > and the FreeBSD Foundation funded Zakary Nafziger to enhance the original
> > GSoC Lua scripts to bring it closer to parity with the evolution of the
> > FORTH menu system since the GSoC project started.
> >
> > I'm pleased to announce that all these threads of development have
> > converged and I'll be pushing the FreeBSD Lua Loader later today. This
> > loader uses Lua as its scripting language instead of FORTH. While
> > co-existance is planned, the timeline for it is looking to be a few weeks
> > and I didn't want to delay pushing this into the tree for that.
> >
> > To try the loader, you'll need to build WITHOUT_FORTH=yes and
> > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this,
> > you can do it in src/stand and install the result (be sure to have the
> > options for both the build and the install). This will replace your
> current
> > /boot/loader that is scripted with FORTH to one that's scripted with Lua.
> > It will install the lua scripts in /boot/lua. The boot is scripted with
> > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised
> > to create a backup copy of /boot/loader before testing (eg cp
> /boot/loader
> > /boot/loader_forth), since you'll need to boot that from boot2 if
> something
> > goes wrong. I've tested it extensively, though, with userboot.so and it's
> > test program, so all the initial kinks of finding the lua scripts, etc
> have
> > been worked out.
> >
> > While it's possible to build all the /boot/loader variants with Lua, I've
> > just tested a BIOS booting /boot/loader both with and without menus
> > enabled. I've not tested any of the other variants and the instructions
> for
> > testing some of them may be rather tedious (especially UEFI, if you want
> a
> > simple path to back out). Since there's not been full convergence
> testing,
> > you'll almost certainly find bumps in this system. Also, all the
> > build-system APIs are likely not yet final.
> >
> > I put  MFC after a month on the commit. Due to the heroic (dare I say
> > almost crazy) work of Kyle Evans on merging all the revs from -current to
> > 11, I'm planning a MFC to 11 after the co-existence issues are hammered
> > out. In 11, FORTH will be the default, and Lua will  be built by default,
> > but users will have to do something to use it. 12, both FORTH and Lua
> will
> > be built and installed, with Lua as default (barring unforeseen
> > complications). Once the co-existence stuff goes in, I imagine we'll make
> > the switch to Lua by default shortly after that. In 13, FORTH will be
> > removed unless there's a really really compelling case made to keep it.
> >
> > So please give it a spin and give me any feedback, documentation updates
> > and/or bug fixes. I'm especially interested in reviews from people that
> > have embedded Lua in other projects or experts in Lua that can improve
> the
> > robustness of the menu code.
>
> Do you have some memory usage numbers for LUA vs forth for the different
> BIOS loaders (text/data/bss sizes)?  For the EFI case we probably have lots
> of room, but for the non-EFI case we are constrained to 0xa - 0xa000
> for the text/data/bss and stack (in some cases like PXE booting the top
> can be lower than 0xa).  I'm not sure if we have any other platforms
> with similar memory constraints.
>

Lua is about 60-70k larger than FORTH for this application:

Forth based:
-r-xr-xr-x  1 root  wheel  385024 Feb 12 14:14
/home/imp/roots/amd64/boot/loader
-r-xr-xr-x  1 root  wheel  450560 Feb 12 14:14
/home/imp/roots/amd64/boot/zfsloader
Lua based:
-r-xr-xr-x  1 root  wheel  450560 Feb 12 14:20
/home/imp/roots/amd64/boot/loader
-r-xr-xr-x  1 root  wheel  520192 Feb 12 14:20
/home/imp/roots/amd64/boot/zfsloader

So with Lua:
%  size loader.bin
textdata bss  dec   hex   filename
  411840   22264   48304   482408   0x75c68   loader.bin
% size zfsloader.bin
textdata bss  dec   hex   filename
  478712   22968   52368   554048   0x87440   zfsloader.bin

so we're at 555k out of 640k before we look at heap usage. Of course, these
numbers are only going to get a lot worse as we pile-in new crypto
features... I know that 

Re: LUA boot loader coming very soon

[John Baldwin]

On Monday, February 12, 2018 08:27:27 AM Warner Losh wrote:
> Greetings,
> 
> As you may know, the Lua (http://www.lua.org) boot loader has been in the
> works for some time. It started out life as a GSoC in 2014 by Pedro Souza
> mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to
> try to integrate it. I rebased that effort into a github branch which Pedro
> Arthur fixed up. Over the past year, I've been cleaning up the boot loader
> for other reasons, and found the time was ripe to start integrating this
> into the tree. However, those integration efforts have taken a while as my
> day-job work on the boot loader took priority. In the mean time, Ed Maste
> and the FreeBSD Foundation funded Zakary Nafziger to enhance the original
> GSoC Lua scripts to bring it closer to parity with the evolution of the
> FORTH menu system since the GSoC project started.
> 
> I'm pleased to announce that all these threads of development have
> converged and I'll be pushing the FreeBSD Lua Loader later today. This
> loader uses Lua as its scripting language instead of FORTH. While
> co-existance is planned, the timeline for it is looking to be a few weeks
> and I didn't want to delay pushing this into the tree for that.
> 
> To try the loader, you'll need to build WITHOUT_FORTH=yes and
> WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this,
> you can do it in src/stand and install the result (be sure to have the
> options for both the build and the install). This will replace your current
> /boot/loader that is scripted with FORTH to one that's scripted with Lua.
> It will install the lua scripts in /boot/lua. The boot is scripted with
> /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised
> to create a backup copy of /boot/loader before testing (eg cp /boot/loader
> /boot/loader_forth), since you'll need to boot that from boot2 if something
> goes wrong. I've tested it extensively, though, with userboot.so and it's
> test program, so all the initial kinks of finding the lua scripts, etc have
> been worked out.
> 
> While it's possible to build all the /boot/loader variants with Lua, I've
> just tested a BIOS booting /boot/loader both with and without menus
> enabled. I've not tested any of the other variants and the instructions for
> testing some of them may be rather tedious (especially UEFI, if you want a
> simple path to back out). Since there's not been full convergence testing,
> you'll almost certainly find bumps in this system. Also, all the
> build-system APIs are likely not yet final.
> 
> I put  MFC after a month on the commit. Due to the heroic (dare I say
> almost crazy) work of Kyle Evans on merging all the revs from -current to
> 11, I'm planning a MFC to 11 after the co-existence issues are hammered
> out. In 11, FORTH will be the default, and Lua will  be built by default,
> but users will have to do something to use it. 12, both FORTH and Lua will
> be built and installed, with Lua as default (barring unforeseen
> complications). Once the co-existence stuff goes in, I imagine we'll make
> the switch to Lua by default shortly after that. In 13, FORTH will be
> removed unless there's a really really compelling case made to keep it.
> 
> So please give it a spin and give me any feedback, documentation updates
> and/or bug fixes. I'm especially interested in reviews from people that
> have embedded Lua in other projects or experts in Lua that can improve the
> robustness of the menu code.

Do you have some memory usage numbers for LUA vs forth for the different
BIOS loaders (text/data/bss sizes)?  For the EFI case we probably have lots
of room, but for the non-EFI case we are constrained to 0xa - 0xa000
for the text/data/bss and stack (in some cases like PXE booting the top
can be lower than 0xa).  I'm not sure if we have any other platforms
with similar memory constraints.

-- 
John Baldwin
___
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"

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Feb 12, 2018 at 9:51 AM, Warner Losh  wrote:

>
>
> On Mon, Feb 12, 2018 at 9:45 AM, Kris Moore  wrote:
>
>> On 02/12/2018 11:31, Warner Losh wrote:
>>
>>
>>
>> On Mon, Feb 12, 2018 at 9:26 AM, Kris Moore  wrote:
>>
>>> On 02/12/2018 10:27, Warner Losh wrote:
>>> > Greetings,
>>> >
>>> > As you may know, the Lua (http://www.lua.org) boot loader has been in
>>> the
>>> > works for some time. It started out life as a GSoC in 2014 by Pedro
>>> Souza
>>> > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch
>>> to
>>> > try to integrate it. I rebased that effort into a github branch which
>>> Pedro
>>> > Arthur fixed up. Over the past year, I've been cleaning up the boot
>>> loader
>>> > for other reasons, and found the time was ripe to start integrating
>>> this
>>> > into the tree. However, those integration efforts have taken a while
>>> as my
>>> > day-job work on the boot loader took priority. In the mean time, Ed
>>> Maste
>>> > and the FreeBSD Foundation funded Zakary Nafziger to enhance the
>>> original
>>> > GSoC Lua scripts to bring it closer to parity with the evolution of the
>>> > FORTH menu system since the GSoC project started.
>>> >
>>> > I'm pleased to announce that all these threads of development have
>>> > converged and I'll be pushing the FreeBSD Lua Loader later today. This
>>> > loader uses Lua as its scripting language instead of FORTH. While
>>> > co-existance is planned, the timeline for it is looking to be a few
>>> weeks
>>> > and I didn't want to delay pushing this into the tree for that.
>>> >
>>> > To try the loader, you'll need to build WITHOUT_FORTH=yes and
>>> > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do
>>> this,
>>> > you can do it in src/stand and install the result (be sure to have the
>>> > options for both the build and the install). This will replace your
>>> current
>>> > /boot/loader that is scripted with FORTH to one that's scripted with
>>> Lua.
>>> > It will install the lua scripts in /boot/lua. The boot is scripted with
>>> > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly
>>> advised
>>> > to create a backup copy of /boot/loader before testing (eg cp
>>> /boot/loader
>>> > /boot/loader_forth), since you'll need to boot that from boot2 if
>>> something
>>> > goes wrong. I've tested it extensively, though, with userboot.so and
>>> it's
>>> > test program, so all the initial kinks of finding the lua scripts, etc
>>> have
>>> > been worked out.
>>> >
>>> > While it's possible to build all the /boot/loader variants with Lua,
>>> I've
>>> > just tested a BIOS booting /boot/loader both with and without menus
>>> > enabled. I've not tested any of the other variants and the
>>> instructions for
>>> > testing some of them may be rather tedious (especially UEFI, if you
>>> want a
>>> > simple path to back out). Since there's not been full convergence
>>> testing,
>>> > you'll almost certainly find bumps in this system. Also, all the
>>> > build-system APIs are likely not yet final.
>>> >
>>> > I put  MFC after a month on the commit. Due to the heroic (dare I say
>>> > almost crazy) work of Kyle Evans on merging all the revs from -current
>>> to
>>> > 11, I'm planning a MFC to 11 after the co-existence issues are hammered
>>> > out. In 11, FORTH will be the default, and Lua will  be built by
>>> default,
>>> > but users will have to do something to use it. 12, both FORTH and Lua
>>> will
>>> > be built and installed, with Lua as default (barring unforeseen
>>> > complications). Once the co-existence stuff goes in, I imagine we'll
>>> make
>>> > the switch to Lua by default shortly after that. In 13, FORTH will be
>>> > removed unless there's a really really compelling case made to keep it.
>>> >
>>> > So please give it a spin and give me any feedback, documentation
>>> updates
>>> > and/or bug fixes. I'm especially interested in reviews from people that
>>> > have embedded Lua in other projects or experts in Lua that can improve
>>> the
>>> > robustness of the menu code.
>>> >
>>> > Warner
>>> > ___
>>> > freebsd-current@freebsd.org mailing list
>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> reebsd.org"
>>>
>>> Warner & Co,
>>>
>>> Great job all! Been wanting this for years, very excited to see it start
>>> landing :)
>>>
>>> One question, if we switch to Lua loader in TrueOS, do you know if the
>>> ZFS boot-environment menus have been implemented / tested yet?
>>
>>
>> I don't think that they have been implemented yet. I've certainly not
>> tested them.
>>
>> Warner
>>
>> Ok, I'll have to mess about with it. I recall there was some library
>> which created to expose ZFS in limited functionality over to the FORTH
>> code. That's probably a good place to start and see if that still works and
>> Lua can probe the pool 

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Feb 12, 2018 at 9:45 AM, Kris Moore  wrote:

> On 02/12/2018 11:31, Warner Losh wrote:
>
>
>
> On Mon, Feb 12, 2018 at 9:26 AM, Kris Moore  wrote:
>
>> On 02/12/2018 10:27, Warner Losh wrote:
>> > Greetings,
>> >
>> > As you may know, the Lua (http://www.lua.org) boot loader has been in
>> the
>> > works for some time. It started out life as a GSoC in 2014 by Pedro
>> Souza
>> > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch
>> to
>> > try to integrate it. I rebased that effort into a github branch which
>> Pedro
>> > Arthur fixed up. Over the past year, I've been cleaning up the boot
>> loader
>> > for other reasons, and found the time was ripe to start integrating this
>> > into the tree. However, those integration efforts have taken a while as
>> my
>> > day-job work on the boot loader took priority. In the mean time, Ed
>> Maste
>> > and the FreeBSD Foundation funded Zakary Nafziger to enhance the
>> original
>> > GSoC Lua scripts to bring it closer to parity with the evolution of the
>> > FORTH menu system since the GSoC project started.
>> >
>> > I'm pleased to announce that all these threads of development have
>> > converged and I'll be pushing the FreeBSD Lua Loader later today. This
>> > loader uses Lua as its scripting language instead of FORTH. While
>> > co-existance is planned, the timeline for it is looking to be a few
>> weeks
>> > and I didn't want to delay pushing this into the tree for that.
>> >
>> > To try the loader, you'll need to build WITHOUT_FORTH=yes and
>> > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do
>> this,
>> > you can do it in src/stand and install the result (be sure to have the
>> > options for both the build and the install). This will replace your
>> current
>> > /boot/loader that is scripted with FORTH to one that's scripted with
>> Lua.
>> > It will install the lua scripts in /boot/lua. The boot is scripted with
>> > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly
>> advised
>> > to create a backup copy of /boot/loader before testing (eg cp
>> /boot/loader
>> > /boot/loader_forth), since you'll need to boot that from boot2 if
>> something
>> > goes wrong. I've tested it extensively, though, with userboot.so and
>> it's
>> > test program, so all the initial kinks of finding the lua scripts, etc
>> have
>> > been worked out.
>> >
>> > While it's possible to build all the /boot/loader variants with Lua,
>> I've
>> > just tested a BIOS booting /boot/loader both with and without menus
>> > enabled. I've not tested any of the other variants and the instructions
>> for
>> > testing some of them may be rather tedious (especially UEFI, if you
>> want a
>> > simple path to back out). Since there's not been full convergence
>> testing,
>> > you'll almost certainly find bumps in this system. Also, all the
>> > build-system APIs are likely not yet final.
>> >
>> > I put  MFC after a month on the commit. Due to the heroic (dare I say
>> > almost crazy) work of Kyle Evans on merging all the revs from -current
>> to
>> > 11, I'm planning a MFC to 11 after the co-existence issues are hammered
>> > out. In 11, FORTH will be the default, and Lua will  be built by
>> default,
>> > but users will have to do something to use it. 12, both FORTH and Lua
>> will
>> > be built and installed, with Lua as default (barring unforeseen
>> > complications). Once the co-existence stuff goes in, I imagine we'll
>> make
>> > the switch to Lua by default shortly after that. In 13, FORTH will be
>> > removed unless there's a really really compelling case made to keep it.
>> >
>> > So please give it a spin and give me any feedback, documentation updates
>> > and/or bug fixes. I'm especially interested in reviews from people that
>> > have embedded Lua in other projects or experts in Lua that can improve
>> the
>> > robustness of the menu code.
>> >
>> > Warner
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>> reebsd.org"
>>
>> Warner & Co,
>>
>> Great job all! Been wanting this for years, very excited to see it start
>> landing :)
>>
>> One question, if we switch to Lua loader in TrueOS, do you know if the
>> ZFS boot-environment menus have been implemented / tested yet?
>
>
> I don't think that they have been implemented yet. I've certainly not
> tested them.
>
> Warner
>
> Ok, I'll have to mess about with it. I recall there was some library which
> created to expose ZFS in limited functionality over to the FORTH code.
> That's probably a good place to start and see if that still works and Lua
> can probe the pool for BE information.
>

OK. There's no such functionality in FORTH in the tree today. However, zfs
sets a number of env vars that loader.getenv() can get in lua.

Warner

Re: LUA boot loader coming very soon

[Kris Moore]

On 02/12/2018 11:31, Warner Losh wrote:
>
>
> On Mon, Feb 12, 2018 at 9:26 AM, Kris Moore  > wrote:
>
> On 02/12/2018 10:27, Warner Losh wrote:
> > Greetings,
> >
> > As you may know, the Lua (http://www.lua.org) boot loader has
> been in the
> > works for some time. It started out life as a GSoC in 2014 by
> Pedro Souza
> > mentored by Wojciech A. Koszek. Rui Paulo created a svn project
> branch to
> > try to integrate it. I rebased that effort into a github branch
> which Pedro
> > Arthur fixed up. Over the past year, I've been cleaning up the
> boot loader
> > for other reasons, and found the time was ripe to start
> integrating this
> > into the tree. However, those integration efforts have taken a
> while as my
> > day-job work on the boot loader took priority. In the mean time,
> Ed Maste
> > and the FreeBSD Foundation funded Zakary Nafziger to enhance the
> original
> > GSoC Lua scripts to bring it closer to parity with the evolution
> of the
> > FORTH menu system since the GSoC project started.
> >
> > I'm pleased to announce that all these threads of development have
> > converged and I'll be pushing the FreeBSD Lua Loader later
> today. This
> > loader uses Lua as its scripting language instead of FORTH. While
> > co-existance is planned, the timeline for it is looking to be a
> few weeks
> > and I didn't want to delay pushing this into the tree for that.
> >
> > To try the loader, you'll need to build WITHOUT_FORTH=yes and
> > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to
> do this,
> > you can do it in src/stand and install the result (be sure to
> have the
> > options for both the build and the install). This will replace
> your current
> > /boot/loader that is scripted with FORTH to one that's scripted
> with Lua.
> > It will install the lua scripts in /boot/lua. The boot is
> scripted with
> > /boot/lua/loader.lua instead of /boot/loader.rc. You are
> strongly advised
> > to create a backup copy of /boot/loader before testing (eg cp
> /boot/loader
> > /boot/loader_forth), since you'll need to boot that from boot2
> if something
> > goes wrong. I've tested it extensively, though, with userboot.so
> and it's
> > test program, so all the initial kinks of finding the lua
> scripts, etc have
> > been worked out.
> >
> > While it's possible to build all the /boot/loader variants with
> Lua, I've
> > just tested a BIOS booting /boot/loader both with and without menus
> > enabled. I've not tested any of the other variants and the
> instructions for
> > testing some of them may be rather tedious (especially UEFI, if
> you want a
> > simple path to back out). Since there's not been full
> convergence testing,
> > you'll almost certainly find bumps in this system. Also, all the
> > build-system APIs are likely not yet final.
> >
> > I put  MFC after a month on the commit. Due to the heroic (dare
> I say
> > almost crazy) work of Kyle Evans on merging all the revs from
> -current to
> > 11, I'm planning a MFC to 11 after the co-existence issues are
> hammered
> > out. In 11, FORTH will be the default, and Lua will  be built by
> default,
> > but users will have to do something to use it. 12, both FORTH
> and Lua will
> > be built and installed, with Lua as default (barring unforeseen
> > complications). Once the co-existence stuff goes in, I imagine
> we'll make
> > the switch to Lua by default shortly after that. In 13, FORTH
> will be
> > removed unless there's a really really compelling case made to
> keep it.
> >
> > So please give it a spin and give me any feedback, documentation
> updates
> > and/or bug fixes. I'm especially interested in reviews from
> people that
> > have embedded Lua in other projects or experts in Lua that can
> improve the
> > robustness of the menu code.
> >
> > 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
> "
>
> Warner & Co,
>
> Great job all! Been wanting this for years, very excited to see it
> start
> landing :)
>
> One question, if we switch to Lua loader in TrueOS, do you know if the
> ZFS boot-environment menus have been implemented / tested yet?
>
>
> I don't think that they have been implemented yet. I've certainly not
> 

Re: LUA boot loader coming very soon

[Warner Losh]

On Mon, Feb 12, 2018 at 9:26 AM, Kris Moore  wrote:

> On 02/12/2018 10:27, Warner Losh wrote:
> > Greetings,
> >
> > As you may know, the Lua (http://www.lua.org) boot loader has been in
> the
> > works for some time. It started out life as a GSoC in 2014 by Pedro Souza
> > mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to
> > try to integrate it. I rebased that effort into a github branch which
> Pedro
> > Arthur fixed up. Over the past year, I've been cleaning up the boot
> loader
> > for other reasons, and found the time was ripe to start integrating this
> > into the tree. However, those integration efforts have taken a while as
> my
> > day-job work on the boot loader took priority. In the mean time, Ed Maste
> > and the FreeBSD Foundation funded Zakary Nafziger to enhance the original
> > GSoC Lua scripts to bring it closer to parity with the evolution of the
> > FORTH menu system since the GSoC project started.
> >
> > I'm pleased to announce that all these threads of development have
> > converged and I'll be pushing the FreeBSD Lua Loader later today. This
> > loader uses Lua as its scripting language instead of FORTH. While
> > co-existance is planned, the timeline for it is looking to be a few weeks
> > and I didn't want to delay pushing this into the tree for that.
> >
> > To try the loader, you'll need to build WITHOUT_FORTH=yes and
> > WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this,
> > you can do it in src/stand and install the result (be sure to have the
> > options for both the build and the install). This will replace your
> current
> > /boot/loader that is scripted with FORTH to one that's scripted with Lua.
> > It will install the lua scripts in /boot/lua. The boot is scripted with
> > /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised
> > to create a backup copy of /boot/loader before testing (eg cp
> /boot/loader
> > /boot/loader_forth), since you'll need to boot that from boot2 if
> something
> > goes wrong. I've tested it extensively, though, with userboot.so and it's
> > test program, so all the initial kinks of finding the lua scripts, etc
> have
> > been worked out.
> >
> > While it's possible to build all the /boot/loader variants with Lua, I've
> > just tested a BIOS booting /boot/loader both with and without menus
> > enabled. I've not tested any of the other variants and the instructions
> for
> > testing some of them may be rather tedious (especially UEFI, if you want
> a
> > simple path to back out). Since there's not been full convergence
> testing,
> > you'll almost certainly find bumps in this system. Also, all the
> > build-system APIs are likely not yet final.
> >
> > I put  MFC after a month on the commit. Due to the heroic (dare I say
> > almost crazy) work of Kyle Evans on merging all the revs from -current to
> > 11, I'm planning a MFC to 11 after the co-existence issues are hammered
> > out. In 11, FORTH will be the default, and Lua will  be built by default,
> > but users will have to do something to use it. 12, both FORTH and Lua
> will
> > be built and installed, with Lua as default (barring unforeseen
> > complications). Once the co-existence stuff goes in, I imagine we'll make
> > the switch to Lua by default shortly after that. In 13, FORTH will be
> > removed unless there's a really really compelling case made to keep it.
> >
> > So please give it a spin and give me any feedback, documentation updates
> > and/or bug fixes. I'm especially interested in reviews from people that
> > have embedded Lua in other projects or experts in Lua that can improve
> the
> > robustness of the menu code.
> >
> > Warner
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
>
> Warner & Co,
>
> Great job all! Been wanting this for years, very excited to see it start
> landing :)
>
> One question, if we switch to Lua loader in TrueOS, do you know if the
> ZFS boot-environment menus have been implemented / tested yet?


I don't think that they have been implemented yet. I've certainly not
tested them.

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"

Re: LUA boot loader coming very soon

[Kris Moore]

On 02/12/2018 10:27, Warner Losh wrote:
> Greetings,
>
> As you may know, the Lua (http://www.lua.org) boot loader has been in the
> works for some time. It started out life as a GSoC in 2014 by Pedro Souza
> mentored by Wojciech A. Koszek. Rui Paulo created a svn project branch to
> try to integrate it. I rebased that effort into a github branch which Pedro
> Arthur fixed up. Over the past year, I've been cleaning up the boot loader
> for other reasons, and found the time was ripe to start integrating this
> into the tree. However, those integration efforts have taken a while as my
> day-job work on the boot loader took priority. In the mean time, Ed Maste
> and the FreeBSD Foundation funded Zakary Nafziger to enhance the original
> GSoC Lua scripts to bring it closer to parity with the evolution of the
> FORTH menu system since the GSoC project started.
>
> I'm pleased to announce that all these threads of development have
> converged and I'll be pushing the FreeBSD Lua Loader later today. This
> loader uses Lua as its scripting language instead of FORTH. While
> co-existance is planned, the timeline for it is looking to be a few weeks
> and I didn't want to delay pushing this into the tree for that.
>
> To try the loader, you'll need to build WITHOUT_FORTH=yes and
> WITH_LOADER_LUA=yes. Fortunately, you needn't do a full world to do this,
> you can do it in src/stand and install the result (be sure to have the
> options for both the build and the install). This will replace your current
> /boot/loader that is scripted with FORTH to one that's scripted with Lua.
> It will install the lua scripts in /boot/lua. The boot is scripted with
> /boot/lua/loader.lua instead of /boot/loader.rc. You are strongly advised
> to create a backup copy of /boot/loader before testing (eg cp /boot/loader
> /boot/loader_forth), since you'll need to boot that from boot2 if something
> goes wrong. I've tested it extensively, though, with userboot.so and it's
> test program, so all the initial kinks of finding the lua scripts, etc have
> been worked out.
>
> While it's possible to build all the /boot/loader variants with Lua, I've
> just tested a BIOS booting /boot/loader both with and without menus
> enabled. I've not tested any of the other variants and the instructions for
> testing some of them may be rather tedious (especially UEFI, if you want a
> simple path to back out). Since there's not been full convergence testing,
> you'll almost certainly find bumps in this system. Also, all the
> build-system APIs are likely not yet final.
>
> I put  MFC after a month on the commit. Due to the heroic (dare I say
> almost crazy) work of Kyle Evans on merging all the revs from -current to
> 11, I'm planning a MFC to 11 after the co-existence issues are hammered
> out. In 11, FORTH will be the default, and Lua will  be built by default,
> but users will have to do something to use it. 12, both FORTH and Lua will
> be built and installed, with Lua as default (barring unforeseen
> complications). Once the co-existence stuff goes in, I imagine we'll make
> the switch to Lua by default shortly after that. In 13, FORTH will be
> removed unless there's a really really compelling case made to keep it.
>
> So please give it a spin and give me any feedback, documentation updates
> and/or bug fixes. I'm especially interested in reviews from people that
> have embedded Lua in other projects or experts in Lua that can improve the
> robustness of the menu code.
>
> 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"

Warner & Co,

Great job all! Been wanting this for years, very excited to see it start
landing :)

One question, if we switch to Lua loader in TrueOS, do you know if the
ZFS boot-environment menus have been implemented / tested yet?


-- 
Kris Moore
Vice President of Engineering
iXsystems
Enterprise Storage & Servers Driven By Open Source

___
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"

Re: PXE boot loader

[Alex Dupre]

I found the issue. I was doing:

cd /usr/src/sys/boot
make depend
make
cp /usr/src/sys/boot/i386/pxeldr/pxeboot /tftpboot

This works os -stable, but not on -current (dunno why)...the pxeboot
is created without problems, but doesn't work.

However, building world as usual creates a working pxeboot in
/usr/obj/usr/src/sys/boot/i386/pxeldr/pxeboot

-- 
Alex Dupre [EMAIL PROTECTED]
http://www.alexdupre.com/  [EMAIL PROTECTED]

Today's excuse: Netscape has crashed


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: PXE boot loader

[Alex Dupre]

This is the exact output:

CLIENT MAC ADDR: 00 00 24 C1 2D F0
CLIENT IP: 10.0.0.36  MASK: 255.255.255.0  DHCP IP: 10.0.0.1
GATEWAY IP: 10.0.0.4
PXE Loader 1.00

Building the boot loader arguments
Relocating the loader and the BTX
Starting the BTX loader


POST: 012345...

rebooting...the pxeboot has been built only with
CPUTYPE=i486 CFLAGS=-O -pipe (from /etc/make.conf)
BOOT_COMCONSOLE_SPEED=57600 -DLOADER_TFTP_SUPPORT (on command line)
parameters. With -STABLE no problems arise.

-- 
Alex Dupre [EMAIL PROTECTED]
http://www.alexdupre.com/  [EMAIL PROTECTED]

Today's excuse: We need a licensed electrician to replace the light bulbs in the 
computer room.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: No /boot/loader

[Bruce Evans]

On Fri, 21 Jul 2000, John Baldwin wrote:

 Bruce Evans wrote:
  On Thu, 20 Jul 2000, John Baldwin wrote:
   ...
   unused even though it is, in fact, used.  The fact that it works at all is
   due to brokenness on our part (we don't check that partitions in a disklabel
   fit in the parent slice) and also results in several hacks in various portions
   of the code where we have to check for such bogusness and work around it.
  
  No, that's wrong too :-) .  We a lot of checking that partitions in a
  disklabel fit in the parent slice.  We clip partitions that don't fit in
  various ways for backwards compatibility.

 Erm, maybe we clip partitions which aren't dangerously dedicated, but
 I've created test dangerously dedicated disks, and we certainly do not
 bother to actually change any of the slice information when we do so.
 disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
 dedicated.

The dangerously dedicated case has one slice covering the whole disk.  We
unclip the slice info from the magic 5 sectors to the size of the whole
disk (as reported by the driver) to handle this.  Reading the slice info
using DIOCGSLICEINFO shows the full size, but no changes are made to the
mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
it is constrained by what the kernel will accept.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

Bruce Evans wrote:
 On Fri, 21 Jul 2000, John Baldwin wrote:
 
  Bruce Evans wrote:
   On Thu, 20 Jul 2000, John Baldwin wrote:
...
unused even though it is, in fact, used.  The fact that it works at all is
due to brokenness on our part (we don't check that partitions in a disklabel
fit in the parent slice) and also results in several hacks in various portions
of the code where we have to check for such bogusness and work around it.
   
   No, that's wrong too :-) .  We a lot of checking that partitions in a
   disklabel fit in the parent slice.  We clip partitions that don't fit in
   various ways for backwards compatibility.
 
  Erm, maybe we clip partitions which aren't dangerously dedicated, but
  I've created test dangerously dedicated disks, and we certainly do not
  bother to actually change any of the slice information when we do so.
  disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
  dedicated.
 
 The dangerously dedicated case has one slice covering the whole disk.  We
 unclip the slice info from the magic 5 sectors to the size of the whole
 disk (as reported by the driver) to handle this.  Reading the slice info
 using DIOCGSLICEINFO shows the full size, but no changes are made to the
 mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
 it is constrained by what the kernel will accept.
 
 Bruce

Ok, so we normally do clip slice information, except in the case of a
dangerously dedicated slice.  Which works fine so long as no one ever
creates a 5 block slice in the 4th entry, as we will expand that
slice to cover all of the disk.  It also means that kernel, like the loader,
has to special case when it sees a dangeriously dedicated slice, which is
rather evil, IMO.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Bruce Evans]

On Sat, 22 Jul 2000, John Baldwin wrote:

 Bruce Evans wrote:
  The dangerously dedicated case has one slice covering the whole disk.  We
  unclip the slice info from the magic 5 sectors to the size of the whole
  disk (as reported by the driver) to handle this.  Reading the slice info
  using DIOCGSLICEINFO shows the full size, but no changes are made to the
  mbr.  This is in the kernel.  I'm not sure exactly what libdisk does, but
  it is constrained by what the kernel will accept.
  
  Bruce

Please don't quote signatures or other irrelevant points.

 Ok, so we normally do clip slice information, except in the case of a
 dangerously dedicated slice.  Which works fine so long as no one ever

There is nothing to clip, since the dangerously dedicated slice is the
whole disk.

 creates a 5 block slice in the 4th entry, as we will expand that
  sector
 slice to cover all of the disk.  It also means that kernel, like the loader,

Normal 5-sector slices are very unlikely to be misinterpreted as
dangerously dedicated ones.  A 5000-sector slice is (or should be) only
interpreted as dangerously dedicated if:
1. all bytes in the partition table have certain values, in particular:
2. the slice type is 0xA5 ("FreeBSD").
3. the starting sector is 0 absolute.  This is is strictly invalid for
   normal slices.
4. the ending C/H/S is 255/255/255.  5-sector slices starting at
   absolute 0 can't reach that far.

 has to special case when it sees a dangeriously dedicated slice, which is
 rather evil, IMO.

It's no more evil than the boot signature.  The garbage in the partition
table is treated as a signature.  It is more authoritative because it is
larger and more magic.

The loader really shouldn't know about the dangerously dedicated case.
Its detection of the dangerously dedicated case is buggy.  It only checks
the conditions (2) and (3) above (and that the slice size is 5).

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

 In message [EMAIL PROTECTED] Leif Neland 
writes:
 : 
 : 
 : On Thu, 20 Jul 2000, Warner Losh wrote:
 : 
 :  In message [EMAIL PROTECTED] Leif 
Neland writes:
 :  : Just to be on the safe side, is there a simple way to see if a disk is
 :  : dedicated?
 :  
 :  fdisk -s ad0
 :  
 :  If there's a slice table, then it will give you a summary report of
 :  the slices.  If not it will report an error (and maybe give you a
 :  faked up listing).
 : 
 : I have windows partitions on my disks here, so they can't be dedicated.
 : fdisk -s ad[0,1,2] all reports
 : invalid fdisk partition found.
 
 Did you do that as root?  All of my windows disks report valid
 partitions.
 
 From my sever:
 % fdisk -s da0
 /dev/da0: 2231 cyl 255 hd 63 sec
 PartStartSize Type Flags
4:   135841014 0xa5 0x80
 
 From my laptop:
 fdisk -s ad0
 /dev/ad0: 559 cyl 240 hd 63 sec
 PartStartSize Type Flags
1:  63 2766897 0x0b 0x00
2: 2766960 5397840 0xa5 0x80
4: 8164800  272160 0xa0 0x00
 
 I'm in group operator, so I can read the disks on my own.  The part
 type 0xa0 is for the suspend to disk partition in my VAIO.
 
 : Does that mean that a dedicated disk has a slice table, a normal doesn't?
 
 No.  That's backwards.  A dedicated disk has no slice table (a
 dangerously dedicated disk, that is), and a "normal" one does have a
 slice table.

No, that's wrong, too.  A normal disk has a proper slice table (slices start
on cylinder boundaries and do not contain the MBR, thus leaving the first
cylinder unused).  A truly dedicated disk (disklabel auto foo) uses a
slightly improper slice table (slices still start and end on cylinder
boundaries and even span the entire disk, however, the only slice contains
the MBR, in fact, we end up writing boot1 into the MBR).  A dangerously
dedicated disk uses a fake, completely bogus slice table that has no relation
at all to the drive's geometry.  As with truly dedicated mode, the MBR is
actually contained in boot1, but in dangerously dedicated mode we use the
slice table hard-coded into the boot code.  This slice table has 1 slice
which is 5 blocks long, or 25000k.  The rest of the disk is marked as
unused even though it is, in fact, used.  The fact that it works at all is
due to brokenness on our part (we don't check that partitions in a disklabel
fit in the parent slice) and also results in several hacks in various portions
of the code where we have to check for such bogusness and work around it.

I'm not a very big fan of the dedicated modes if you couldn't tell. :)
 
 Warner

--

John Baldwin [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Warner Losh]

In message [EMAIL PROTECTED] Leif Neland 
writes:
: 
: 
: On Thu, 20 Jul 2000, Warner Losh wrote:
: 
:  In message [EMAIL PROTECTED] Leif 
:Neland writes:
:  : Just to be on the safe side, is there a simple way to see if a disk is
:  : dedicated?
:  
:  fdisk -s ad0
:  
:  If there's a slice table, then it will give you a summary report of
:  the slices.  If not it will report an error (and maybe give you a
:  faked up listing).
: 
: I have windows partitions on my disks here, so they can't be dedicated.
: fdisk -s ad[0,1,2] all reports
: invalid fdisk partition found.

Did you do that as root?  All of my windows disks report valid
partitions.

From my sever:
% fdisk -s da0
/dev/da0: 2231 cyl 255 hd 63 sec
PartStartSize Type Flags
   4:   135841014 0xa5 0x80

From my laptop:
fdisk -s ad0
/dev/ad0: 559 cyl 240 hd 63 sec
PartStartSize Type Flags
   1:  63 2766897 0x0b 0x00
   2: 2766960 5397840 0xa5 0x80
   4: 8164800  272160 0xa0 0x00

I'm in group operator, so I can read the disks on my own.  The part
type 0xa0 is for the suspend to disk partition in my VAIO.

: Does that mean that a dedicated disk has a slice table, a normal doesn't?

No.  That's backwards.  A dedicated disk has no slice table (a
dangerously dedicated disk, that is), and a "normal" one does have a
slice table.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Bruce Evans]

On Thu, 20 Jul 2000, John Baldwin wrote:

 No, that's wrong, too.  A normal disk has a proper slice table (slices start
 on cylinder boundaries and do not contain the MBR, thus leaving the first
 track
 cylinder unused).  A truly dedicated disk (disklabel auto foo) uses a
  track
 ...
 at all to the drive's geometry.  As with truly dedicated mode, the MBR is
 actually contained in boot1, but in dangerously dedicated mode we use the
 slice table hard-coded into the boot code.  This slice table has 1 slice
 which is 5 blocks long, or 25000k.  The rest of the disk is marked as
 unused even though it is, in fact, used.  The fact that it works at all is
 due to brokenness on our part (we don't check that partitions in a disklabel
 fit in the parent slice) and also results in several hacks in various portions
 of the code where we have to check for such bogusness and work around it.

No, that's wrong too :-) .  We a lot of checking that partitions in a
disklabel fit in the parent slice.  We clip partitions that don't fit in
various ways for backwards compatibility.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

Bruce Evans wrote:
 On Thu, 20 Jul 2000, John Baldwin wrote:
 
  No, that's wrong, too.  A normal disk has a proper slice table (slices start
  on cylinder boundaries and do not contain the MBR, thus leaving the first
  track
  cylinder unused).  A truly dedicated disk (disklabel auto foo) uses a
   track
  ...
  at all to the drive's geometry.  As with truly dedicated mode, the MBR is
  actually contained in boot1, but in dangerously dedicated mode we use the
  slice table hard-coded into the boot code.  This slice table has 1 slice
  which is 5 blocks long, or 25000k.  The rest of the disk is marked as
  unused even though it is, in fact, used.  The fact that it works at all is
  due to brokenness on our part (we don't check that partitions in a disklabel
  fit in the parent slice) and also results in several hacks in various portions
  of the code where we have to check for such bogusness and work around it.
 
 No, that's wrong too :-) .  We a lot of checking that partitions in a
 disklabel fit in the parent slice.  We clip partitions that don't fit in
 various ways for backwards compatibility.
 
 Bruce

Erm, maybe we clip partitions which aren't dangerously dedicated, but
I've created test dangerously dedicated disks, and we certainly do not
bother to actually change any of the slice information when we do so.
disklabel(8) does for truly dedicated, but libdisk doesn't for dangerously
dedicated.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Doug White]

On Wed, 19 Jul 2000, Doug Barton wrote:

  Disk geometry stuffup, or a 'real' disk error.
 
   Well, I put my money on real disk error, but only because it
 vindicates my position that we shouldn't have switched to this new kind of
 disk in the first place. 
 
   As for geometry, I tried both with and without "dangerously
 dedicated." My understanding was that if I used the dos partition entry
 method that we should be able to pick up the geometry correctly, but
 should I try the old dos fdisk trick as well? Also, would the adaptec
 setting to translate 1G be affecting this? It's on currently, which it is
 on all my other motherboards of similar vintage. 

Your boot disk is now *required* (or will be very very soon) to have a
proper slice table in -CURRENT; dedicated disks are deprecated in order to
get a smarter boot0.

Speaking of boot0 you might try using boot0cfg to force packet mode.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Leif Neland]

On Thu, 20 Jul 2000, Doug White wrote:

 Your boot disk is now *required* (or will be very very soon) to have a
 proper slice table in -CURRENT; dedicated disks are deprecated in order to
 get a smarter boot0.
 
So dedicated disks are to be reformatted?
Just to be on the safe side, is there a simple way to see if a disk is
dedicated?

Leif



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Warner Losh]

In message [EMAIL PROTECTED] Leif Neland 
writes:
: Just to be on the safe side, is there a simple way to see if a disk is
: dedicated?

fdisk -s ad0

If there's a slice table, then it will give you a summary report of
the slices.  If not it will report an error (and maybe give you a
faked up listing).

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[John Baldwin]

 On Wed, 19 Jul 2000, Doug Barton wrote:
 
   Disk geometry stuffup, or a 'real' disk error.
  
  Well, I put my money on real disk error, but only because it
  vindicates my position that we shouldn't have switched to this new kind of
  disk in the first place. 
  
  As for geometry, I tried both with and without "dangerously
  dedicated." My understanding was that if I used the dos partition entry
  method that we should be able to pick up the geometry correctly, but
  should I try the old dos fdisk trick as well? Also, would the adaptec
  setting to translate 1G be affecting this? It's on currently, which it is
  on all my other motherboards of similar vintage. 
 
 Your boot disk is now *required* (or will be very very soon) to have a
 proper slice table in -CURRENT; dedicated disks are deprecated in order to
 get a smarter boot0.
 
 Speaking of boot0 you might try using boot0cfg to force packet mode.
 
 Doug White|  FreeBSD: The Power to Serve
 [EMAIL PROTECTED] |  www.FreeBSD.org

As the author of the new parts of boot0: "No".  You are not required to
have a proper slice table for -CURRENT.  It is recommended, as you have
to have it to use boot0, but you couldn't use the old boot0 with dedicated
disks, either.  Basically, only use dedicated modes _if_ the non-dedicated
mode does not work.  Also, if that happens, please let us know it is broke
so we can fix it.  Thanks.

--

John Baldwin [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader (dangerously dedicated)

[Thomas Stromberg]

Doug White wrote:
 
 On Wed, 19 Jul 2000, Doug Barton wrote:
As for geometry, I tried both with and without "dangerously
  dedicated." My understanding was that if I used the dos partition entry
  method that we should be able to pick up the geometry correctly, but
  should I try the old dos fdisk trick as well? Also, would the adaptec
  setting to translate 1G be affecting this? It's on currently, which it is
  on all my other motherboards of similar vintage.
 
 Your boot disk is now *required* (or will be very very soon) to have a
 proper slice table in -CURRENT; dedicated disks are deprecated in order to
 get a smarter boot0.
 
 Speaking of boot0 you might try using boot0cfg to force packet mode.

Even though this does not directly affect -STABLE right now (I hope?), I
think it'd probably be a good idea to maybe turn off the dangerously
dedicated option in sysinstall (or at least turn the question off). At
least in -CURRENT if nowhere else, so no one shoots themself in the
foot.

This would defititely help out at work, as I would no longer get the
question from all of our users during the install "Should I be dedicated
or not?"



-- 

thomas r. stromberg  [EMAIL PROTECTED]
senior systems administratorhttp://www.afterthought.org/
research triangle commerce, inc.  1.919.657.1317

bless(\$Perl++);# the power to hack.  http://www.perl.com/
#include freebsd.h   /* the power to serve. http://www.freebsd.org/ */



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Mike Smith]

   No response to this on -stable. The actual error message is:
 
 Disk error 0x1 (lba=0x7004c)
 No /boot/loader

Disk geometry stuffup, or a 'real' disk error.

   Also, on a whim I decided to try running /boot/loader. I got a

It's not a FreeBSD executable (obviously enough), so you can't do this.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: No /boot/loader

[Doug Barton]

On Wed, 19 Jul 2000, Mike Smith wrote:

  No response to this on -stable. The actual error message is:
  
  Disk error 0x1 (lba=0x7004c)
  No /boot/loader
 
 Disk geometry stuffup, or a 'real' disk error.

Well, I put my money on real disk error, but only because it
vindicates my position that we shouldn't have switched to this new kind of
disk in the first place. 

As for geometry, I tried both with and without "dangerously
dedicated." My understanding was that if I used the dos partition entry
method that we should be able to pick up the geometry correctly, but
should I try the old dos fdisk trick as well? Also, would the adaptec
setting to translate 1G be affecting this? It's on currently, which it is
on all my other motherboards of similar vintage. 

Finally, the other thing that's confusing me is that the error
message mentions "lba," which I thought was strictly an IDE thing. Just
for grins I tried toggling LBA and CHS mode in the bios, but no joy. 

  Also, on a whim I decided to try running /boot/loader. I got a
 
 It's not a FreeBSD executable (obviously enough), so you can't do this.

Yeah... it was born out of frustration, since nothing else was
working anyway. I was kind of surprised that it did anything at all, to be
honest. 

Thanks for your response,

Doug
-- 
"Live free or die"
- State motto of my ancestral homeland, New Hampshire

Do YOU Yahoo!?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message