Re: pkg does not recognize correct kernel version

[Andreas Nilsson]

I think this was worked around in pkg 1.10.5. As a temporary workaround do
pkg -o OSVERSION=1200058 update -f
pkg upgrade

Best regards
Andreas


On Feb 19, 2018 23:54, "Ronald Klop"  wrote:

On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov 
wrote:

On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote:
>
>> Am 19.02.2018 um 21:24 schrieb Ronald Klop:
>> > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling 
>> wrote:
>> >
>> >> Hi Ronald,
>> >>
>> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
>> >>> I just did this.
>> >>>
>> >>> root@sjakie ~]# pkg upgrade
>> >>> Updating FreeBSD repository catalogue...
>> >>> Fetching meta.txz: 100%944 B   0.9kB/s00:01
>> >>> Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
>> >>> Processing entries:   0%
>> >>> pkg: Newer FreeBSD version for package gnome-menus:
>> >>> - package: 1200058
>> >>> - running kernel: 1200056
>> >>> pkg: repository FreeBSD contains packages for wrong OS version:
>> >>> FreeBSD:12:amd64
>> >>> Processing entries: 100%
>> >>> Unable to update repository FreeBSD
>> >>> Error updating repositories!
>> >>>
>> >>> [root@sjakie ~]# uname -UK
>> >>> 1200058 1200058
>> >>>
>> >>> [root@sjakie ~]# uname -a
>> >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb
>> 18
>> >>> 12:37:36 CET 2018 >>> ronald@sjakie:/data/ronald/obj
>> -freebsd-current/data/ronald/freebsd-current/amd64.amd64/
>> sys/GENERIC-NODEBUGamd64
>> >>>
>> >>>
>> >>>
>> >>> So uname gives a different version than pkg detects.
>> >>>
>> >>> What is happening? pkg update -f gives the same result. -o
>> >>> OSVERSION=1200058 helps, but does not feel like the right solution.
>> >>>
>> >>> Regards,
>> >>> Ronald.
>> >>
>> >> Please try
>> >>
>> >> #sysctl kern.osreldate
>> >> kern.osreldate: 1200058
>> >>
>> >> HTH,
>> >> Rainer Hurling
>> >
>> >
>> > [root@sjakie ~]# sysctl kern.osreldate
>> > kern.osreldate: 1200058
>> >
>> > Regards,
>> > Ronald.
>>
>> On my kernel patchlevel 1200058 (r329446) I get:
>>
>> #pkg update -f
>> Updating FreeBSD repository catalogue...
>> Fetching meta.txz: 100%944 B   0.9kB/s00:01
>> Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
>> Processing entries: 100%
>> FreeBSD repository update completed. 28645 packages processed.
>> All repositories are up to date.
>>
>>
>> Perhaps more a local problem :(
>>
>
> Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD
>

Which man page? I can't find it in pkg help update or pkg help upgrade or
man pkg.


version note:
> orion% file /bin/ls
> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1
> (1101506), FreeBSD-style, stripped
>
> Update world past the __FreeBSD_version which is reported for the
> repository.
>

Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Regards,
Ronald.

___
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"
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 3:38 PM, "Kyle Evans"  wrote:

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco
to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script,
it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not
sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot
them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.


Forth has a framework for making all commands forth words. It leverages
that to run the intercept. We already have the intercept in place with a
stupidly simple policy. We totally can do something generic that would
solve this and maybe other problems. Let's chat online tomorrow about a
couple of possibilities we can choose from.

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: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 4:32 PM, Warner Losh  wrote:
> 
> 
> 
>> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>> 
>> 
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>> 
>> I can indeed confirm this as fact.
>> 
>> Not able to help much because I am driving cross-country (San Francisco to 
>> Orlando) right now with the spouse and dog.
>> 
>> We get back March 3rd, but I will be checking-in from time to time for 
>> sporadic responses during downtime.
> 
> The command in loader.4th is defined as:
> 
> : boot
>   0= if ( interpreted ) get_arguments then
> 
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ; 
> 
> The thing to know here is when you see 'boot' as part of above script, it's 
> calling the 'boot' cli command, not itself recursively.
> 

What is actually going on is that when the “boot” function is compiled, the 
reference to “boot” inside it is to the already-existing word defined 
previously. Forth allows you to have multiply-defined names. The “boot” command 
inside the “boot” function is replaced with the address of previous boot during 
function compilation because the function is m not defined and given an address 
in the dictionary until it is completed (last line compiled).
— 
Devin
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

 gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei  wrote:
>
>
> On 2/19/18 5:48 PM, Kyle Evans wrote:
>>
>>
>> On Feb 19, 2018 5:44 PM, "Peter Lei" > > wrote:
>>
>>
>>
>> On 2/19/18 2:21 PM, Kyle Evans wrote:
>> > Hello!
>> >
>> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
>> mailto:lis...@club.fr>> wrote:
>> >> I have done a full build of r329555 to test the new Lua boot loader.
>> >>
>> >> Both the new and the old kernels panic after being loaded with:
>> >>
>> >> panic: running without device atpic requires a local APIC
>> >>
>> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
>> a previous
>> >> message:
>> >>
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>> 
>> 
>> >>
>> >> OK show hint.acpi.0.disabled
>> >> 1
>> >>
>> >> Setting ACPI to On resolves the issue.
>> >
>> > As David noted, this should actually Just Work (TM) now. Can you break
>> > into a loader prompt with just the forth loader and tell me what "show
>> > hint.acpi.0.rsdp" looks like?
>>
>>
>> This doesn't appear to "just work out-of-the-box" yet when EFI booting
>> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
>>
>> Under EFI and lua loader, the following is set when breaking to prompt:
>> hint.acpi.0.disabled=1
>> Under forth loader, this is not present/set.
>>
>> In neither case is hint.acpi.0.rsdp present/set as that appears to get
>> set during the exec of the loaded kernel...
>>
>> I've worked around the issue by adding hint.acpi.0.disabled="0" to
>> loader.conf (or patching the amd64 efi loader code to explicitly clear
>> that hint).
>>
>>
>> [Apologies for broken quoting, currently mobile]
>>
>> What happens if you patch this line out?
>> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233
>
>
> Ah, right - yep, commenting out that line works.
>

This should be fixed as of r329614. hint.acpi.0.rsdp gets set upon
exec of the loaded kernel in the EFI world, then in i386 world it's
before lualoader comes into play. We should probably do as forth does
and disable ACPI stuff on !i386 (IIRC the option disappears
completely), but IIRC we haven't yet exposed TARGET/TARGET_ARCH to
lua.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 5:48 PM, Kyle Evans wrote:
> 
> 
> On Feb 19, 2018 5:44 PM, "Peter Lei"  > wrote:
> 
> 
> 
> On 2/19/18 2:21 PM, Kyle Evans wrote:
> > Hello!
> >
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
> mailto:lis...@club.fr>> wrote:
> >> I have done a full build of r329555 to test the new Lua boot loader.
> >>
> >> Both the new and the old kernels panic after being loaded with:
> >>
> >> panic: running without device atpic requires a local APIC
> >>
> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
> a previous
> >> message:
> >>
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
> 
> 
> >>
> >> OK show hint.acpi.0.disabled
> >> 1
> >>
> >> Setting ACPI to On resolves the issue.
> >
> > As David noted, this should actually Just Work (TM) now. Can you break
> > into a loader prompt with just the forth loader and tell me what "show
> > hint.acpi.0.rsdp" looks like?
> 
> 
> This doesn't appear to "just work out-of-the-box" yet when EFI booting
> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
> 
> Under EFI and lua loader, the following is set when breaking to prompt:
>     hint.acpi.0.disabled=1
> Under forth loader, this is not present/set.
> 
> In neither case is hint.acpi.0.rsdp present/set as that appears to get
> set during the exec of the loaded kernel...
> 
> I've worked around the issue by adding hint.acpi.0.disabled="0" to
> loader.conf (or patching the amd64 efi loader code to explicitly clear
> that hint).
> 
> 
> [Apologies for broken quoting, currently mobile]
> 
> What happens if you patch this line out?
> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233


Ah, right - yep, commenting out that line works.


> I'll have to go back and figure out what I was thinking here again. It
> made sense when I wrote it, maybe explicitly disabling ACPI if it's not
> immediately detected was the wrong move. =)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Feb 19, 2018 5:44 PM, "Peter Lei"  wrote:



On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).


[Apologies for broken quoting, currently mobile]

What happens if you patch this line out?
https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233

I'll have to go back and figure out what I was thinking here again. It made
sense when I wrote it, maybe explicitly disabling ACPI if it's not
immediately detected was the wrong move. =)
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
> 
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
> 
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).



smime.p7s
Description: S/MIME Cryptographic Signature

Re: pkg does not recognize correct kernel version

[Ronald Klop]

On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov  
 wrote:



On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote:

Am 19.02.2018 um 21:24 schrieb Ronald Klop:
> On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling   
wrote:

>
>> Hi Ronald,
>>
>> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
>>> I just did this.
>>>
>>> root@sjakie ~]# pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching meta.txz: 100%944 B   0.9kB/s00:01
>>> Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
>>> Processing entries:   0%
>>> pkg: Newer FreeBSD version for package gnome-menus:
>>> - package: 1200058
>>> - running kernel: 1200056
>>> pkg: repository FreeBSD contains packages for wrong OS version:
>>> FreeBSD:12:amd64
>>> Processing entries: 100%
>>> Unable to update repository FreeBSD
>>> Error updating repositories!
>>>
>>> [root@sjakie ~]# uname -UK
>>> 1200058 1200058
>>>
>>> [root@sjakie ~]# uname -a
>>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun  
Feb 18
>>> 12:37:36 CET 2018 >>>  
ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64

>>>
>>>
>>>
>>> So uname gives a different version than pkg detects.
>>>
>>> What is happening? pkg update -f gives the same result. -o
>>> OSVERSION=1200058 helps, but does not feel like the right solution.
>>>
>>> Regards,
>>> Ronald.
>>
>> Please try
>>
>> #sysctl kern.osreldate
>> kern.osreldate: 1200058
>>
>> HTH,
>> Rainer Hurling
>
>
> [root@sjakie ~]# sysctl kern.osreldate
> kern.osreldate: 1200058
>
> Regards,
> Ronald.

On my kernel patchlevel 1200058 (r329446) I get:

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.


Perhaps more a local problem :(


Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD


Which man page? I can't find it in pkg help update or pkg help upgrade or  
man pkg.



version note:
orion% file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),  
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1  
(1101506), FreeBSD-style, stripped


Update world past the __FreeBSD_version which is reported for the  
repository.


Does this mean I always have to do a *clean* buildworld after every  
version bump? This takes ages.


Regards,
Ronald.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script, it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:

>
>
> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> >
> > It seems that the Forth loader might be doing something sneaky and
> > replacing the standard common "boot" with a Forth boot that handles
> > this a lot better. CC'ing dteske@ so they can confirm.
>
> I can indeed confirm this as fact.
>
> Not able to help much because I am driving cross-country (San Francisco to
> Orlando) right now with the spouse and dog.
>
> We get back March 3rd, but I will be checking-in from time to time for
> sporadic responses during downtime.
>

The command in loader.4th is defined as:

: boot
  0= if ( interpreted ) get_arguments then

  \ Unload only if a path was passed
  dup if
>r over r> swap
c@ [char] - <> if
  0 1 unload drop
else
  s" kernelname" getenv? if ( a kernel has been loaded )
try-menu-unset
bootmsg 1 boot exit
  then
  load_kernel_and_modules
  ?dup if exit then
  try-menu-unset
  bootmsg 0 1 boot exit
then
  else
s" kernelname" getenv? if ( a kernel has been loaded )
  try-menu-unset
  bootmsg 1 boot exit
then
load_kernel_and_modules
?dup if exit then
try-menu-unset
bootmsg 0 1 boot exit
  then
  load_kernel_and_modules
  ?dup 0= if bootmsg 0 1 boot then
;

The thing to know here is when you see 'boot' as part of above script, it's
calling the 'boot' cli command, not itself recursively.

I can help do more interpretation of the details if you need Kyle. Not sure
how much to spell out, but the brief pseudo code is:

If there were any arguments that didn't start with '-', unload.
  otherwise if kernelname is in in the environment, run the 'menu-unset'
forth word if it exists, print the boot message and boot.
  Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if it exists), print the boot message and boot with kernelname
Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
it exists), print the boot message and boot with kernelname
if all that fails, load the kernel and modules and if that works boot 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"

kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

[Chris H]

I'm seeing a number of messages like the following:
kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

and was wondering if it's anything to be concerned with, or whether
fsck(8) is fixing them.
This began to happen when the power went out on a new install:
FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST 2017
root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
which hadn't yet been hooked up to the UPS.
I performed an fsck in single user mode upon power-up. Which ended with the
mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL.
I answered Y.
FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly:
newfs -U -j

Thank you for all your time, and consideration.

--Chris


___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.




Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?


OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...


In fact, I don’t think this has ever worked here… I’ve found a very old 
(July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.




There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.


Thanks.



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.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.


I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U 
processor, 4GB RAM). The only thing I can think of is that the ACPI of 
this model is not well supported, but the errors I have are related to 
thermal zones…:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with 
ccache and WITH_META_MODE, but this build process has been working 
nicely for months.


The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of 
things to slim down the memstick, but still, it has been stable till now:


juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks setting locale and thus tmux
#WITHOUT_LOCALES=
WITHOUT_LPR=
WITHOUT_MAIL=

Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> 
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.

I can indeed confirm this as fact.

Not able to help much because I am driving cross-country (San Francisco to 
Orlando) right now with the spouse and dog.

We get back March 3rd, but I will be checking-in from time to time for sporadic 
responses during downtime.
— 
Cheers,
Devin
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh  wrote:
>
>
> On Feb 19, 2018 1:23 PM, "Kyle Evans"  wrote:
>
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
>> previous
>> message:
>>
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?
>
>> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
>> keyboard only becomes responsive at the loader stage.
>
> Hmm...
>
>> There is an error during this stage:
>>
>> Loading /boot/defaults/loader.conf
>> Failed to open config: ’/boot/loader.conf.local’
>
> David's diagnosis of this is right- this is more of an informational
> message that you don't need to worry about.
>
>> 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.
>
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.
>
>
> Indeed, it does.
>
> Loader.4th defines boot. Search for ': boot' to see it.
>

I've created D14442 [1] to improve this situation a little bit. We
should also either:

1.) Provide a way for lua to register a function to handle a loader command, or
2.) Provide a way for lua/forth to tell the common boot what modules to load.

These both entail a good amount of work and quite a few places to
fail, but one of them needs to happen. =(

[1] https://reviews.freebsd.org/D14442
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 15:39, David Wolfskill a écrit :

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html


That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.


OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader:
the keyboard only becomes responsive at the loader stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)


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.


And the Lua loader permits kernel selection, as well (as the Forth
laoder has).


Finally, the double lines drawing a frame around the loader menu do not
work with the new loader and are replaced by ? characters in a box.


That has also been fixed for me (as of r329517).


Hope it helps,
Juan



Peace,
david


Thanks David. It’s strange I’m having issues resolved for you in commits 
older than the one I used here…


___
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: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 1:23 PM, "Kyle Evans"  wrote:

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> 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.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Indeed, it does.

Loader.4th defines boot. Search for ': boot' to see it.

Warner

> Finally, the double lines drawing a frame around the loader menu do not
work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
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"
___
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: pkg does not recognize correct kernel version

[Konstantin Belousov]

On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote:
> Am 19.02.2018 um 21:24 schrieb Ronald Klop:
> > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling  wrote:
> > 
> >> Hi Ronald,
> >>
> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
> >>> I just did this.
> >>>
> >>> root@sjakie ~]# pkg upgrade
> >>> Updating FreeBSD repository catalogue...
> >>> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
> >>> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
> >>> Processing entries:   0%
> >>> pkg: Newer FreeBSD version for package gnome-menus:
> >>> - package: 1200058
> >>> - running kernel: 1200056
> >>> pkg: repository FreeBSD contains packages for wrong OS version:
> >>> FreeBSD:12:amd64
> >>> Processing entries: 100%
> >>> Unable to update repository FreeBSD
> >>> Error updating repositories!
> >>>
> >>> [root@sjakie ~]# uname -UK
> >>> 1200058 1200058
> >>>
> >>> [root@sjakie ~]# uname -a
> >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
> >>> 12:37:36 CET 2018  
> >>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64
> >>>
> >>>
> >>>
> >>> So uname gives a different version than pkg detects.
> >>>
> >>> What is happening? pkg update -f gives the same result. -o
> >>> OSVERSION=1200058 helps, but does not feel like the right solution.
> >>>
> >>> Regards,
> >>> Ronald.
> >>
> >> Please try
> >>
> >> #sysctl kern.osreldate
> >> kern.osreldate: 1200058
> >>
> >> HTH,
> >> Rainer Hurling
> > 
> > 
> > [root@sjakie ~]# sysctl kern.osreldate
> > kern.osreldate: 1200058
> > 
> > Regards,
> > Ronald.
> 
> On my kernel patchlevel 1200058 (r329446) I get:
> 
> #pkg update -f
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%944 B   0.9kB/s00:01
> Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
> Processing entries: 100%
> FreeBSD repository update completed. 28645 packages processed.
> All repositories are up to date.
> 
> 
> Perhaps more a local problem :(

Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD
version note:
orion% file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically 
linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 (1101506), 
FreeBSD-style, stripped

Update world past the __FreeBSD_version which is reported for the repository.
___
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: pkg does not recognize correct kernel version

[Rainer Hurling]

Am 19.02.2018 um 21:24 schrieb Ronald Klop:
> On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling  wrote:
> 
>> Hi Ronald,
>>
>> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
>>> I just did this.
>>>
>>> root@sjakie ~]# pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
>>> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
>>> Processing entries:   0%
>>> pkg: Newer FreeBSD version for package gnome-menus:
>>> - package: 1200058
>>> - running kernel: 1200056
>>> pkg: repository FreeBSD contains packages for wrong OS version:
>>> FreeBSD:12:amd64
>>> Processing entries: 100%
>>> Unable to update repository FreeBSD
>>> Error updating repositories!
>>>
>>> [root@sjakie ~]# uname -UK
>>> 1200058 1200058
>>>
>>> [root@sjakie ~]# uname -a
>>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
>>> 12:37:36 CET 2018  
>>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64
>>>
>>>
>>>
>>> So uname gives a different version than pkg detects.
>>>
>>> What is happening? pkg update -f gives the same result. -o
>>> OSVERSION=1200058 helps, but does not feel like the right solution.
>>>
>>> Regards,
>>> Ronald.
>>
>> Please try
>>
>> #sysctl kern.osreldate
>> kern.osreldate: 1200058
>>
>> HTH,
>> Rainer Hurling
> 
> 
> [root@sjakie ~]# sysctl kern.osreldate
> kern.osreldate: 1200058
> 
> Regards,
> Ronald.

On my kernel patchlevel 1200058 (r329446) I get:

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.


Perhaps more a local problem :(
___
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: pkg does not recognize correct kernel version

[Ronald Klop]

On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling  wrote:


Hi Ronald,

Am 19.02.2018 um 20:27 schrieb Ronald Klop:

I just did this.

root@sjakie ~]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
Processing entries:   0%
pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version:
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!

[root@sjakie ~]# uname -UK
1200058 1200058

[root@sjakie ~]# uname -a
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018
ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG 
amd64



So uname gives a different version than pkg detects.

What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.

Regards,
Ronald.


Please try

#sysctl kern.osreldate
kern.osreldate: 1200058

HTH,
Rainer Hurling



[root@sjakie ~]# sysctl kern.osreldate
kern.osreldate: 1200058


Regards,
Ronald.
___
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: pkg does not recognize correct kernel version

[Ronald Klop]

On Mon, 19 Feb 2018 20:54:57 +0100, Michael Gmelin  wrote:




On 19. Feb 2018, at 20:27, Ronald Klop  wrote:

I just did this.

root@sjakie ~]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
Processing entries:   0%
pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version:  
FreeBSD:12:amd64

Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!

[root@sjakie ~]# uname -UK
1200058 1200058

[root@sjakie ~]# uname -a
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb  
18 12:37:36 CET 2018  
ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG   
amd64



So uname gives a different version than pkg detects.

What is happening? pkg update -f gives the same result. -o  
OSVERSION=1200058 helps, but does not feel like the right solution.


What is the output of ‘freebsd-version’?

Best,
Michael





[root@sjakie ~]# freebsd-version
12.0-CURRENT


Regards,
Ronald.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> 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.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.

> Finally, the double lines drawing a frame around the loader menu do not work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
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: pkg does not recognize correct kernel version

[Rainer Hurling]

Hi Ronald,

Am 19.02.2018 um 20:27 schrieb Ronald Klop:
> I just did this.
> 
> root@sjakie ~]# pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
> Processing entries:   0%
> pkg: Newer FreeBSD version for package gnome-menus:
> - package: 1200058
> - running kernel: 1200056
> pkg: repository FreeBSD contains packages for wrong OS version:
> FreeBSD:12:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD
> Error updating repositories!
> 
> [root@sjakie ~]# uname -UK
> 1200058 1200058
> 
> [root@sjakie ~]# uname -a
> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
> 12:37:36 CET 2018
> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>  
> amd64
> 
> 
> So uname gives a different version than pkg detects.
> 
> What is happening? pkg update -f gives the same result. -o
> OSVERSION=1200058 helps, but does not feel like the right solution.
> 
> Regards,
> Ronald.

Please try

#sysctl kern.osreldate
kern.osreldate: 1200058

HTH,
Rainer Hurling
___
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: pkg does not recognize correct kernel version

[Michael Gmelin]

> On 19. Feb 2018, at 20:27, Ronald Klop  wrote:
> 
> I just did this.
> 
> root@sjakie ~]# pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%944 B   0.9kB/s00:01
> Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
> Processing entries:   0%
> pkg: Newer FreeBSD version for package gnome-menus:
> - package: 1200058
> - running kernel: 1200056
> pkg: repository FreeBSD contains packages for wrong OS version: 
> FreeBSD:12:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD
> Error updating repositories!
> 
> [root@sjakie ~]# uname -UK
> 1200058 1200058
> 
> [root@sjakie ~]# uname -a
> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 
> 12:37:36 CET 2018 
> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>   amd64
> 
> 
> So uname gives a different version than pkg detects.
> 
> What is happening? pkg update -f gives the same result. -o OSVERSION=1200058 
> helps, but does not feel like the right solution.

What is the output of ‘freebsd-version’?

Best,
Michael


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

pkg does not recognize correct kernel version

[Ronald Klop]

I just did this.

root@sjakie ~]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   6.0MB/s00:01
Processing entries:   0%
pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version:  
FreeBSD:12:amd64

Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!

[root@sjakie ~]# uname -UK
1200058 1200058

[root@sjakie ~]# uname -a
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18  
12:37:36 CET 2018  
ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG   
amd64



So uname gives a different version than pkg detects.

What is happening? pkg update -f gives the same result. -o  
OSVERSION=1200058 helps, but does not feel like the right solution.


Regards,
Ronald.
___
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: How to find CPU microcode version ?

[Shane Ambler]

On 18/02/2018 21:11, Kurt Jaeger wrote:
> Hi!

> Around the 14th, processes started to be killed for out of swapspace,
> even if the box had almost no load at all.
> 
> pid 1056 (mutt), uid 104, was killed: out of swap space
> pid 536 (devd), uid 0, was killed: out of swap space
> pid 15093 (exim), uid 26, was killed: out of swap space
> pid 91868 (mutt), uid 104, was killed: out of swap space
> pid 1086 (sshd), uid 104, was killed: out of swap space
> 
> Reboot of the box and waiting a few hours and the problem re-occured.
> 
> The box has 32 GB RAM and 34 GB swap, which never was utilized
> beyond a few hundred MBs.

One situation that can cause out of swap errors is large amounts of
wired ram. Wired ram is memory that can't be swapped out. When you get
around 80 or 90% of physical ram wired you start seeing those errors.

You can see the amount of wired displayed in top or
sysctl vm.stats.vm.v_wire_count then times that by hw.pagesize

There is a vm.max_wired but it doesn't appear to be an enforced limit.

-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: ACPI panic on boot with new Lua loader and other minor issues

[David Wolfskill]

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
> 
> Both the new and the old kernels panic after being loaded with:
> 
> panic: running without device atpic requires a local APIC
> 
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
> previous message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.

> OK show hint.acpi.0.disabled
> 1
> 
> Setting ACPI to On resolves the issue.
> 
> Also, I can not stop boot2 to try to use the copy of the Forth loader: 
> the keyboard only becomes responsive at the loader stage.

> There is an error during this stage:
> 
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)

> 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.

And the Lua loader permits kernel selection, as well (as the Forth
laoder has).

> Finally, the double lines drawing a frame around the loader menu do not 
> work with the new loader and are replaced by ? characters in a box.

That has also been fixed for me (as of r329517).

> Hope it helps,
> Juan
> 

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

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

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



I forgot that I tried starting with "unload", which seems to work, but 
does not correct the issue:


OK unload
OK boot kernel.old
Command failed
___
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"

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
previous message:

https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader: 
the keyboard only becomes responsive at the loader stage.


There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’

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.

Finally, the double lines drawing a frame around the loader menu do not 
work with the new loader and are replaced by ? characters in a box.


Hope it helps,
Juan
___
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: Buildworld failing during llvm

[Ben Woods]

On 18 February 2018 at 09:52, Ben Woods  wrote:

> Hi everyone,
>
> My attempts to build FreeBSD 12-current have been failing as of yesterday
> with the error below. This problem persists with current at the time of
> writing this email (r329497).
>
> Given llvm was updated to 6.0 around that time, I suspect it is related:
> https://svnweb.freebsd.org/base?view=revision&revision=329410
>
>
> --- clang.full ---
> c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
> -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include
> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\"
> -ffunction-sections -fdata-sections -g -O0 -Qunused-arguments
> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11
> -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions
> -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib
> -o clang.full  cc1_main.o cc1as_main.o driver.o
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw
> -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr
> -lpthread -legacy
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a:
> could not read symbols: Malformed archive
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [clang.full] Error code 1
>
>
> Regards,
> Ben
>
> --
> From: Benjamin Woods
> woods...@gmail.com
>


I found this issue was caused by having the following line in my
/etc/make.conf (which I had there for some ports debugging):
DEBUG_FLAGS=-g -O0

I wouldn't have thought this should cause the clang build to fail...


Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
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"