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

[O. Hartmann]

On Tue, 20 Feb 2018 12:39:53 +0100
Gary Jennejohn  wrote:

> On Mon, 19 Feb 2018 14:18:15 -0800
> "Chris H"  wrote:
> 
> > 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.
> >   
> 
> fsck fixes these errors only when the user does NOT use the journal.
> You should re-do the fsck.
> 

When first these mysterious errors occured on several boxes running CURRENT,
that was in December 2017 if I'm right, I also whitnessed mysterious and
frequent crashes on several SSD driven machines, where this error described
above occured.

While the error vanished somehow in the meanwhile while CURRENT proceeds, the
crashes continued - on two boxes, I dumped restore the OS on the system's SSD
by reformatting the SSD from sratch (UFS2, soft update+ journaling). On those
boxes the mysterious crashes vanished since then!

On box left so far, my workstation. And this box continous to crash now and
started crashing today again while compiling world/kernel.

The fun-part is: even after a clean shutdown, where I can not detect any
filesystem inconsistencies and rebooting and, again: no reported
inconsistencies on the console/messages/logs, the box crashes spontanously. Now
(today) I could trigger the reboot by starting "make -j4 buildworld
buildkernel" and after showing the initial compiler statements/build framework
statements, the box went to Nirwana. A well known phenomenon right now.

I checked now the consistency of the filesystem, here is the result of
the /usr/obj tree, which is a dedicated GPT partition
(label: /dev/gpt/usr.obj):


[...]
 root@box1:~ # fsck -fy /dev/gpt/usr.obj
** /dev/gpt/usr.obj
** Last Mounted on /usr/obj
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED  I=515  OWNER=root MODE=0
SIZE=0 MTIME=Feb 22 07:25 2018 
NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? yes

DIRECTORY CORRUPTED  I=169691  OWNER=root MODE=40775
SIZE=1536 MTIME=Feb 22 05:16 2018 
DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd

UNEXPECTED SOFT UPDATE INCONSISTENCY

SALVAGE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4%
fragmentation)

* FILE SYSTEM MARKED DIRTY *

* FILE SYSTEM WAS MODIFIED *

* PLEASE RERUN FSCK *

[...]

When doing a installworld, I pre-emptively perform in single user mode before
mounting the partitions a "fsck -yf" two times. In most cases, the filesystem
are reported clean, but sometimes especially those under high I/O (/usr/src and
mostly /usr/obj on this build machine) there are reports of corruption.

As I reported, the very same behaviour occured on three boxes simultanously and
I got rid of it by completely reformatting the SSDs (never had issues so far
with HDD based boxes!). 

I hope I can refurbish this weekend the remaining box and I could report, if
desired, whether this box returns to a healthy state as the others or if my
observation was a simple coincidence of issues ...

Thanks for the patience,

Oliver
___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Awesome, thanks for the update and the work that you have done!

Now we just need some more reviewers eyes on the code :)

Br,

Tommi

On Thu, 22 Feb 2018 at 2.03, Eric McCorkle  wrote:

> FYI, I just IFC'ed everything, and the current patches are still fine.
>
> Also, the full GELI + standalone loader has been deployed on one of my
> laptops for some time now.
>
> On 02/21/2018 18:15, Eric McCorkle wrote:
> > The GELI work could be merged at this point, though it won't be usable
> > without an additional patch to enable loader-only operation.  The
> > patches are currently up for review:
> >
> > This is the order in which they'd need to be merged:
> >
> >
> > https://reviews.freebsd.org/D12732
> >
> > This one changes the efipart device.  Toomas Soome identified some
> > problems, which I have addressed.  He has not re-reviewed it, however.
> >
> >
> > https://reviews.freebsd.org/D12692
> >
> > This adds some crypto code needed for GELI.  It simply adds new code,
> > and doesn't conflict with anything.
> >
> >
> > https://reviews.freebsd.org/D12698
> >
> > This adds the EFI KMS interface code, and has the EFI loader pass keys
> > into the keybuf interface.
> >
> >
> > I can't post the main GELI driver until those get merged, as it depends
> > on them.  It can be found on the geli branch on my github freebsd
> > repository, however.
> >
> >
> > Additionally, you need this patch, which allows loader.efi to function
> > when installed directly to the ESP:
> >
> > https://reviews.freebsd.org/D13497
> >
> > On 02/20/2018 22:56, Tommi Pernila wrote:
> >> Hi Eric,
> >>
> >> could you provide a brief update how the work is going?
> >>
> >>
> >> Br,
> >>
> >> Tommi
> >>
> >>
> >> On Nov 16, 2017 04:29, "Eric McCorkle"  >> > wrote:
> >>
> >> Right, so basically, the remaining GELI patches are against loader,
> and
> >> most of them can go in independently of the work on removing boot1.
> >> There's a unanimous consensus on getting rid of boot1 which
> includes its
> >> original author, so that's going to happen.
> >>
> >>
> >> For GELI, we have the following (not necessarily in order):
> >>
> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
> >> interactions
> >> b) Modifications to the efipart driver
> >> c) boot crypto
> >> d) GELI partition types (not strictly necessary)
> >>
> >> Then there's the GELI driver itself.  (a) and (c) are good to land,
> (b)
> >> needs some more work after Toomas Soome pointed out a legitimate
> >> problem, and (d) actually needs a good bit more code (but again,
> it's
> >> more cosmetic).  Additionally, the GELI driver will need further
> mods to
> >> efipart to be written (nothing too big).  But we could go ahead
> with (a)
> >> and (c), as they've already been proven to work.
> >>
> >> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied
> with
> >> the 7th RISC-V workshop at the end of the month.
> >>
> >> Once this stuff is all in, loader should handle any GELI volumes it
> >> finds, and it should Just Work once boot1 is gone.
> >>
> >>
> > ___
> > 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"

P2P core/daemon in Base?

[Le Baron d’Merde]

Dear Fellows,

Nothing new and probably will not be implemented, specially by me who can't 
write code, but I am sharing this idea anyway.

The point would be to have a P2P core/daemon in Base with some API to be used 
by clients, including pkg, freebsd-update, and portsnap becoming P2P 
based/capable, and would also allowing any user that desire to become a FreeBSD 
mirror[1]. What would reduce the load on the FreeBSD infrastructure.

Other than those, idealistic, that built-in P2P core to be also capable of 
handling
"modern" needs, like a net/syncthing equivalent client, and the usual torrent 
clients (CLI,
GTK, Qt etc.).

Some time ago, while digging in the Syncthing resources I found some people 
willing
to use that to keep files synced between thousands of servers, and so I imagine 
this
kind of feature would (very?) be appealing at enterprise level.

This piece of software could of course be integrated with IPFW, Capsicum or 
wherever be necessary, possible or desired.


1 - The FreeBSD mirror capability would be a separated feature allowing for 
those who
desire to partially mirror the FreeBSD packages, etc. For instance in a way 
that user
to mirror from just the latest packages to everything.

-- 
Best Regards.
LBdM.
___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Eric McCorkle]

FYI, I just IFC'ed everything, and the current patches are still fine.

Also, the full GELI + standalone loader has been deployed on one of my
laptops for some time now.

On 02/21/2018 18:15, Eric McCorkle wrote:
> The GELI work could be merged at this point, though it won't be usable
> without an additional patch to enable loader-only operation.  The
> patches are currently up for review:
> 
> This is the order in which they'd need to be merged:
> 
> 
> https://reviews.freebsd.org/D12732
> 
> This one changes the efipart device.  Toomas Soome identified some
> problems, which I have addressed.  He has not re-reviewed it, however.
> 
> 
> https://reviews.freebsd.org/D12692
> 
> This adds some crypto code needed for GELI.  It simply adds new code,
> and doesn't conflict with anything.
> 
> 
> https://reviews.freebsd.org/D12698
> 
> This adds the EFI KMS interface code, and has the EFI loader pass keys
> into the keybuf interface.
> 
> 
> I can't post the main GELI driver until those get merged, as it depends
> on them.  It can be found on the geli branch on my github freebsd
> repository, however.
> 
> 
> Additionally, you need this patch, which allows loader.efi to function
> when installed directly to the ESP:
> 
> https://reviews.freebsd.org/D13497
> 
> On 02/20/2018 22:56, Tommi Pernila wrote:
>> Hi Eric,
>>
>> could you provide a brief update how the work is going?
>>
>>
>> Br,
>>
>> Tommi
>>
>>
>> On Nov 16, 2017 04:29, "Eric McCorkle" > > wrote:
>>
>> Right, so basically, the remaining GELI patches are against loader, and
>> most of them can go in independently of the work on removing boot1.
>> There's a unanimous consensus on getting rid of boot1 which includes its
>> original author, so that's going to happen.
>>
>>
>> For GELI, we have the following (not necessarily in order):
>>
>> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
>> interactions
>> b) Modifications to the efipart driver
>> c) boot crypto
>> d) GELI partition types (not strictly necessary)
>>
>> Then there's the GELI driver itself.  (a) and (c) are good to land, (b)
>> needs some more work after Toomas Soome pointed out a legitimate
>> problem, and (d) actually needs a good bit more code (but again, it's
>> more cosmetic).  Additionally, the GELI driver will need further mods to
>> efipart to be written (nothing too big).  But we could go ahead with (a)
>> and (c), as they've already been proven to work.
>>
>> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with
>> the 7th RISC-V workshop at the end of the month.
>>
>> Once this stuff is all in, loader should handle any GELI volumes it
>> finds, and it should Just Work once boot1 is gone.
>>
>>
> ___
> 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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Eric McCorkle]

The GELI work could be merged at this point, though it won't be usable
without an additional patch to enable loader-only operation.  The
patches are currently up for review:

This is the order in which they'd need to be merged:


https://reviews.freebsd.org/D12732

This one changes the efipart device.  Toomas Soome identified some
problems, which I have addressed.  He has not re-reviewed it, however.


https://reviews.freebsd.org/D12692

This adds some crypto code needed for GELI.  It simply adds new code,
and doesn't conflict with anything.


https://reviews.freebsd.org/D12698

This adds the EFI KMS interface code, and has the EFI loader pass keys
into the keybuf interface.


I can't post the main GELI driver until those get merged, as it depends
on them.  It can be found on the geli branch on my github freebsd
repository, however.


Additionally, you need this patch, which allows loader.efi to function
when installed directly to the ESP:

https://reviews.freebsd.org/D13497

On 02/20/2018 22:56, Tommi Pernila wrote:
> Hi Eric,
> 
> could you provide a brief update how the work is going?
> 
> 
> Br,
> 
> Tommi
> 
> 
> On Nov 16, 2017 04:29, "Eric McCorkle"  > wrote:
> 
> Right, so basically, the remaining GELI patches are against loader, and
> most of them can go in independently of the work on removing boot1.
> There's a unanimous consensus on getting rid of boot1 which includes its
> original author, so that's going to happen.
> 
> 
> For GELI, we have the following (not necessarily in order):
> 
> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
> interactions
> b) Modifications to the efipart driver
> c) boot crypto
> d) GELI partition types (not strictly necessary)
> 
> Then there's the GELI driver itself.  (a) and (c) are good to land, (b)
> needs some more work after Toomas Soome pointed out a legitimate
> problem, and (d) actually needs a good bit more code (but again, it's
> more cosmetic).  Additionally, the GELI driver will need further mods to
> efipart to be written (nothing too big).  But we could go ahead with (a)
> and (c), as they've already been proven to work.
> 
> I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with
> the 7th RISC-V workshop at the end of the month.
> 
> Once this stuff is all in, loader should handle any GELI volumes it
> finds, and it should Just Work once boot1 is gone.
> 
> 
___
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"

top: sysctl(vfs.bufspace...) expected 8, got 4

[O. Hartmann]

On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 
23:06:15 CET 2018
 amd64) I'm honored by this nice bug when calling top:

top: sysctl(vfs.bufspace...) expected 8, got 4


Regards,

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpGq73wGLtKr.pgp
Description: OpenPGP digital signature

Re: pkg does not recognize correct kernel version

[Andreas Nilsson]

As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
easier to deal with.

Best regards
Andreas

On Feb 21, 2018 20:45, "Trond Endrestøl" <
trond.endres...@fagskolen.gjovik.no> wrote:

> On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote:
>
> > On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl
> >  wrote:
> >
> > > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:
> > >
> > > > Does this mean I always have to do a *clean* buildworld after every
> > > > version
> > > > bump? This takes ages.
> > >
> > > Yes, I've come to the conclusion that whenever __FreeBSD_version in
> > > sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
> > > recreate everything to ensure the correct value of osversion in the
> > > .note.tag section of each executable, and reinstall base prior to
> > > updating localbase. See PR 225104 for more details,
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.
> > >
> >
> > pkg: Newer FreeBSD version for package gnome-menus:
> > - package: 1200058
> > - running kernel: 1200056
> >
> > So it says "running kernel", but it actually checked "version of
> > FreeBSD_version while building /bin/sh" or something like that.
> > This sounds over-engineered and (more important) confusing.
>
> I tried the simply approach of running "make clean; make build" in
> /usr/src/bin/sh, hoping it would generate binaries with the correct
> osversion in the .note.tag section. Boy, I couldn't be more wrong.
> Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever
> osversion is increased. I'm probably missing a simpler step.
>
> --
> Trond.
> ___
> 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

[Trond Endrestøl]

On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote:

> On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl
>  wrote:
> 
> > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:
> > 
> > > Does this mean I always have to do a *clean* buildworld after every
> > > version
> > > bump? This takes ages.
> > 
> > Yes, I've come to the conclusion that whenever __FreeBSD_version in
> > sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
> > recreate everything to ensure the correct value of osversion in the
> > .note.tag section of each executable, and reinstall base prior to
> > updating localbase. See PR 225104 for more details,
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.
> > 
> 
> pkg: Newer FreeBSD version for package gnome-menus:
> - package: 1200058
> - running kernel: 1200056
> 
> So it says "running kernel", but it actually checked "version of
> FreeBSD_version while building /bin/sh" or something like that.
> This sounds over-engineered and (more important) confusing.

I tried the simply approach of running "make clean; make build" in 
/usr/src/bin/sh, hoping it would generate binaries with the correct 
osversion in the .note.tag section. Boy, I couldn't be more wrong. 
Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever 
osversion is increased. I'm probably missing a simpler step.

-- 
Trond.
___
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]

Still breaks automation, doesn’t it?

> On 21. Feb 2018, at 20:49, Andreas Nilsson  wrote:
> 
> As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
> easier to deal with.
> 
> Best regards
> Andreas
> 
> On Feb 21, 2018 20:45, "Trond Endrestøl" <
> trond.endres...@fagskolen.gjovik.no> wrote:
> 
>>> On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote:
>>> 
>>> On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl
>>>  wrote:
>>> 
> On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:
> 
> Does this mean I always have to do a *clean* buildworld after every
> version
> bump? This takes ages.
 
 Yes, I've come to the conclusion that whenever __FreeBSD_version in
 sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
 recreate everything to ensure the correct value of osversion in the
 .note.tag section of each executable, and reinstall base prior to
 updating localbase. See PR 225104 for more details,
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.
 
>>> 
>>> pkg: Newer FreeBSD version for package gnome-menus:
>>> - package: 1200058
>>> - running kernel: 1200056
>>> 
>>> So it says "running kernel", but it actually checked "version of
>>> FreeBSD_version while building /bin/sh" or something like that.
>>> This sounds over-engineered and (more important) confusing.
>> 
>> I tried the simply approach of running "make clean; make build" in
>> /usr/src/bin/sh, hoping it would generate binaries with the correct
>> osversion in the .note.tag section. Boy, I couldn't be more wrong.
>> Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever
>> osversion is increased. I'm probably missing a simpler step.
>> 
>> --
>> Trond.
>> ___
>> 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"

___
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

[Trond Endrestøl]

On Wed, 21 Feb 2018 20:49+0100, Andreas Nilsson wrote:

> As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
> easier to deal with.

That's an huge improvement. sys/sys/param.h and base are in agreement 
on the systems I manage, so I won't see the improvement in action for 
some time.

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

Lua loader - geli passphrase issue

[Kalle Carlbark]

Hi,

Geli passphrase longer than 15 characters puts you directly to the beastie boot 
menu without you hitting the enter key.

GELI passphrase: 1234567890123456

Is that the correct behavior or have I missed something?


Peace,

//Kalle

___
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: Kernel selection in Lua loader

[Kyle Evans]

On Wed, Feb 21, 2018 at 12:18 PM, Rodney W. Grimes
 wrote:
>> On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans  wrote:
>> > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill  
>> > wrote:
>> >>
>> >> ...
>> >> kernels="kernel kernel.old kernel.save"
>> >>
>> >> and the Forth loader presented (precisely) those kernels as the
>> >> available options for selecting a kernel to load and boot.
>> >>
>> >
>> > Right, so, we (and by we I mean cem@) actually implemented a form of
>> > auto-detection for kernels. Any directory in in /boot with a file
>> > named 'kernel' inside will be automatically listed, and that
>> > supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5).
>> >
>> > (*) I use "supplemented" because I changed that in r329709, just a
>> > little bit ago, to not do the autodetection if a 'kernels' is
>> > explicitly set in loader.conf(5) My reasoning here is that there's
>> > probably a reason one has set it explicitly, whether it be to hide
>> > bogus kernels or just to slim down the list of kernels they need to
>> > cycle through.
>>
>> Yep.  And to add a little more detail, because I like this behavior,
>> I've convinced Kyle to add a knob to re-enable the autodetection
>> behavior even in the presence of kernels="", by adding a
>> kernels_autodetect="yes" knob to loader.conf (r329733).
>
> Or how about parse a wildcard * in kernels= to mean do the same as
> kernels_autodetect=yes
> the should make it possible to control the order of them on
> the list bo doing something like
> kernels=/boot/kernel;/boot/kernel.old;*;/altboot/kernel;/altboot/kernel.GENERIC
>
>
>
>> Note that any kernels in kernels="" are offered first in the list, in
>> the same order as configured; any additional autodetected kernels
>> follow at the end (as you observed earlier):
>
> The mechansism now only allows autodetec at end, use of a wildcard to
> show when to insert autodetect allows a fairly arbitrary order.
>

I think we might have a problem right now with trying to do this while
Forth is still the default; how would it interpret such an entry?

I'd almost want to go a step further and say that * should indicate
where we search. Right now, it's a hard-coded /boot. I'd express that
in kernels as /boot/*, which tells the loader to search directories
matching /boot/* for a 'kernel' file and use that.

This could then be expanded to do things like /altboot/* and search
/altboot for other kernels. That'd need a little more work because we
don't currently search non-/boot directories[*] when we're actually
trying to load kernels.

[*] Unless they appear in the module_path, then we search for
"$kernel" as a file.
___
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 loader - geli passphrase issue

[Kyle Evans]

On Wed, Feb 21, 2018 at 1:59 PM, Kalle Carlbark
 wrote:
> Hi,
>
> Geli passphrase longer than 15 characters puts you directly to the beastie 
> boot menu without you hitting the enter key.
>
> GELI passphrase: 1234567890123456
>
> Is that the correct behavior or have I missed something?
>

You have missed how silly this behavior was. =)

Fixed in r329748, sorry about that!

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: pkg does not recognize correct kernel version

[Ronald Klop]

On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl  
 wrote:



On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:

Does this mean I always have to do a *clean* buildworld after every  
version

bump? This takes ages.


Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.



pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056

So it says "running kernel", but it actually checked "version of  
FreeBSD_version while building /bin/sh" or something like that.

This sounds over-engineered and (more important) confusing.

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: Kernel selection in Lua loader

[Rodney W. Grimes]

> On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans  wrote:
> > On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill  
> > wrote:
> >>
> >> ...
> >> kernels="kernel kernel.old kernel.save"
> >>
> >> and the Forth loader presented (precisely) those kernels as the
> >> available options for selecting a kernel to load and boot.
> >>
> >
> > Right, so, we (and by we I mean cem@) actually implemented a form of
> > auto-detection for kernels. Any directory in in /boot with a file
> > named 'kernel' inside will be automatically listed, and that
> > supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5).
> >
> > (*) I use "supplemented" because I changed that in r329709, just a
> > little bit ago, to not do the autodetection if a 'kernels' is
> > explicitly set in loader.conf(5) My reasoning here is that there's
> > probably a reason one has set it explicitly, whether it be to hide
> > bogus kernels or just to slim down the list of kernels they need to
> > cycle through.
> 
> Yep.  And to add a little more detail, because I like this behavior,
> I've convinced Kyle to add a knob to re-enable the autodetection
> behavior even in the presence of kernels="", by adding a
> kernels_autodetect="yes" knob to loader.conf (r329733).

Or how about parse a wildcard * in kernels= to mean do the same as
kernels_autodetect=yes
the should make it possible to control the order of them on
the list bo doing something like
kernels=/boot/kernel;/boot/kernel.old;*;/altboot/kernel;/altboot/kernel.GENERIC



> Note that any kernels in kernels="" are offered first in the list, in
> the same order as configured; any additional autodetected kernels
> follow at the end (as you observed earlier):

The mechansism now only allows autodetec at end, use of a wildcard to
show when to insert autodetect allows a fairly arbitrary order.

> >> with the Lua loader, I was being offered a choice among 4 kernels
> >> (rather than the expected 3).  Cycling through them (twice; I wanted
> >> to be sure the behavior was reproducible), I noted that the presented
> >> options were:
> >>
> >> * default/kernel
> >> * kernel.old
> >> * kernel.save
> >> * kernel.panic
> >>
> >> (in that sequence).
> 
> Best,
> Conrad

-- 
Rod Grimes rgri...@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: Kernel selection in Lua loader

[Conrad Meyer]

On Wed, Feb 21, 2018 at 6:11 AM, Kyle Evans  wrote:
> On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill  wrote:
>>
>> ...
>> kernels="kernel kernel.old kernel.save"
>>
>> and the Forth loader presented (precisely) those kernels as the
>> available options for selecting a kernel to load and boot.
>>
>
> Right, so, we (and by we I mean cem@) actually implemented a form of
> auto-detection for kernels. Any directory in in /boot with a file
> named 'kernel' inside will be automatically listed, and that
> supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5).
>
> (*) I use "supplemented" because I changed that in r329709, just a
> little bit ago, to not do the autodetection if a 'kernels' is
> explicitly set in loader.conf(5) My reasoning here is that there's
> probably a reason one has set it explicitly, whether it be to hide
> bogus kernels or just to slim down the list of kernels they need to
> cycle through.

Yep.  And to add a little more detail, because I like this behavior,
I've convinced Kyle to add a knob to re-enable the autodetection
behavior even in the presence of kernels="", by adding a
kernels_autodetect="yes" knob to loader.conf (r329733).

Note that any kernels in kernels="" are offered first in the list, in
the same order as configured; any additional autodetected kernels
follow at the end (as you observed earlier):

>> with the Lua loader, I was being offered a choice among 4 kernels
>> (rather than the expected 3).  Cycling through them (twice; I wanted
>> to be sure the behavior was reproducible), I noted that the presented
>> options were:
>>
>> * default/kernel
>> * kernel.old
>> * kernel.save
>> * kernel.panic
>>
>> (in that sequence).

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

We have something like this that I added yesterday in r329692, but
named a little bit differently ("local.lua", "local module"). Mostly
added because I've been using it to locally add test menu options and
writing some of the documentation for how to hook into our new lua
system to do things, and it was getting tiresome having to manually
revert those bits in loader.lua when I wanted to make changes to the
in-tree loader.lua.

We'd basically rename this to loader.local.lua to match more closely
to current convention, move "cli_execute" out to either core.lua or
maybe it and the boot commands are worthy of their own "cli" module,
then be happy.

> This specific example should have always been a loader.conf variable (and
> not an exec). While the gop command is useful, the loader should have, as
> part of it's forth sequence, had something that would set the GOP mode if
> the uefi_gop_mode loader.conf variable was set (I get why that wasn't done
> that way in the forth loader, insert rant of Fear of FORTH here). So we
> 

GELI changes?

[Krassimir Slavchev]

Hi All,

On FreeBSD 8 & 9 I was able to use GELI on preloaded image providing
keys either via loader.conf or via custom usb driver.
On FreeBSD 11 & CURRENT I can not make usb drivers to load before GELI
(e.g. MODULE_DEPEND(g_eli, my_usb_device, 1, 1, 1) in g_eli.c). Also,
loading keys from loader.conf is not working (Cannot decrypt Master Key)
which may be related to current EFI changes. On CURRENT loading keys
from loader.conf produces kernel panic because cryptosoft is not
initialized (opencrypto/crypto.c:497, CRYPTO_DRIVER_LOCK() spin mutex
(null)).

So, could we load USB layer before GELI?
Is there a way to re-taste a GEOM provider a bit later but before root
mount?

Best regards,

-- 
Krassimir Slavchev   Bulinfo Ltd.
kra...@bulinfo.net   (+359 2) 9699 166
http://www.bulinfo.net   (+359 2) 9699 160
___
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 Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans  wrote:

> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor 
> wrote:
> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
> >>
> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <
> lis...@club.fr>
> >> wrote:
> >>>
> >>> [... snip ...]
> >>>
> >>> Moreover, the "boot [kernel]" loader command does not work:
> >>>
> >>> OK ls /boot/kernel.old/kernel
> >>>  /boot/kernel.old/kernel
> >>> OK boot kernel.old
> >>> Command failed
> >>> OK boot /boot/kernel.old/kernel
> >>> Command failed
> >>> OK boot kernel
> >>> Command failed
> >>>
> >>> On the other hand, just "boot" works.
> >>>
> >>
> >> This part should work as expected as of r329674, so please give that a
> >> shot. I'm still trying to see if I can reproduce your box drawing
> >> problem.
> >>
> >> Thanks,
> >>
> >> Kyle Evans
> >>
> >
> > Thanks Kyle.
> >
> > boot command works now. There is though a somewhat strangely formulated
> > messages when trying to load an non-existent kernel:
> >
> > OK boot fake
> > Failed to load kernel ’fake’
> > Failed to load any kernel
> > can’t load ’kernel’
> >
> > The two last lines are odd: Did the loader try to load a fallback kernel
> and
> > failed? That would explain the ’kernel’ name in quotes, but I have such a
> > kernel… Also, just nitpicking, but "can’t" should be capitalized.
>
> (CC'ing Rod, since he also commented on this)
>
> I'm only directly responsible for the first two messages. =) I've
> removed the second one, though, since it was a carry-over from when it
> would try to load the selected kernel and then some default kernel
> that might be in your module_path.
>
> We can look at changing "can't load 'kernel'" to capitalize and remove
> the contraction, but that's common loader stuff and should've also
> been displayed for the same Forth scenario.
>
> > Then, I have just remembered why I was seeing a higher resolution menu
> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new
> > loader is not implementing the inclusion of this file, because I can
> change
> > the gop mode in the loader with 'gop set [0-3]'.
> >
>
> Oy. This is actually a Forth file, so we can't really maintain all of
> the functionality that would have been allowed there. Technically,
> things like this should probably either appear in your loader.conf(5)
> in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is
> read, or we should provide some other means of running pure loader
> command scripts at different points in the loader sequence. (CC
> Warner, because he probably has thoughts about this latter idea)
>

While loader.rc is FORTH, it's contrived FORTH designed to look like
command line interaction. While some crazy people like me have actual forth
in these, most do not, really (apart from the include /boot/XXX.4th lines,
that is, which could be filtered).

We have two choices here: Try to provide some level of compatibility shims,
or provide a new way to say these things in Lua.

In the original SoC code, loader.lua lived in /boot and looked to be
something that people could modify. We likely need to do something similar.
loader.lua right now has nothing but were in the forth world called
'include' and then very similar commands to the forth loader.rc. Perhaps
the right answer is to move cli_execute out of /boot/lua/loader.lua, move
that file up, and add the try-include functionality to try to include a
loader.local.lua. Then we could tell people to move to the Lua syntax way
of doing things. We'd have to hunt down all the hacks like this, but that
wouldn't be terrible. Bonus points if we could convert the common ones
either to lua code automatically, or to loader.conf variables.

This specific example should have always been a loader.conf variable (and
not an exec). While the gop command is useful, the loader should have, as
part of it's forth sequence, had something that would set the GOP mode if
the uefi_gop_mode loader.conf variable was set (I get why that wasn't done
that way in the forth loader, insert rant of Fear of FORTH here). So we
should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few
other things that are simple settings to make it easier for users to set
this stuff up and start to move away from the FoF kludges that we've
accumulated. A new loader.conf variable would also allow coexistence of the
two loaders, which will be further helped with some patches I have to the
build system coming soon.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Rodney W. Grimes]

> Le 20/02/2018 ? 22:45, Kyle Evans a ?crit?:
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram?n Molina Menor  
> > wrote:
> >> [... snip ...]
> >>
> >> Moreover, the "boot [kernel]" loader command does not work:
> >>
> >> OK ls /boot/kernel.old/kernel
> >>  /boot/kernel.old/kernel
> >> OK boot kernel.old
> >> Command failed
> >> OK boot /boot/kernel.old/kernel
> >> Command failed
> >> OK boot kernel
> >> Command failed
> >>
> >> On the other hand, just "boot" works.
> >>
> > 
> > This part should work as expected as of r329674, so please give that a
> > shot. I'm still trying to see if I can reproduce your box drawing
> > problem.
> > 
> > Thanks,
> > 
> > Kyle Evans
> > 
> 
> Thanks Kyle.
> 
> boot command works now. There is though a somewhat strangely formulated 
> messages when trying to load an non-existent kernel:
> 
> OK boot fake
> Failed to load kernel ?fake?
> Failed to load any kernel
> can?t load ?kernel?
> 
> The two last lines are odd: Did the loader try to load a fallback kernel 
> and failed? That would explain the ?kernel? name in quotes, but I have 
> such a kernel? Also, just nitpicking, but "can?t" should be capitalized.

To be supper nt picky can't should also be spelled can not.

> Then, I have just remembered why I was seeing a higher resolution menu 
> before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new 
> loader is not implementing the inclusion of this file, because I can 
> change the gop mode in the loader with 'gop set [0-3]'.
> 
> This has thus nothing to do with the drawing lines, I guess.
> 
> Best regards.
-- 
Rod Grimes rgri...@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: A small procedural request

[Julian Elischer]

On 21/2/18 7:14 pm, Tomoaki AOKI wrote:

Hi.

+1. But have one suggestion for format.
Something like

  Broken by: rXXX
  Broken by: Unknown (Bugfix but the revision introduced it is unknown)

and optionally

  Broken by: No (To emphasize it's NOT a bugfix.)


I think that is probably too much, but the    Broken by:  would be 
good.


would be better for scripts already handling "MFC after: " or
"X-MFC-With: " etc. to support this.

If put on the top with "MFC rXX: Comments", it can be

  FIX rXX: Comments


possibly..
that Would allow some sort of collection of the data to  suggest good 
places to

retrospectively base your head following (but not too closely) branches.
but may be more work that people are willing to do..
For myself, just a hint of where the bug was introduced would help a lot.
further more if you have a branch/product based at some point in time, 
this would help

you to know when a patch needs to be cherry picked back to your code.


or for multiple revisions,

  FIX rXX rYY rZZ: Comments for multiple individuals
  FIX rXX-rYY: Comments for massive continuous range

would be better.

Regards.


On Wed, 21 Feb 2018 12:01:33 +0800
Julian Elischer  wrote:


Hi,〓 I have a very small request to those committing into head.

If you commit a fix, then if it is possible to easily do so, can you
give the revision number in which the regression was introduced?

like "this was〓 broken in r329xxx"

this allows people who are looking for specific problems to say "Ok
that bug was introduced after the snapshot I'm working on and can't be
my issue".

(we are not always working on the very tip).


thanks

Julian


___
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: Kernel selection in Lua loader

[Kyle Evans]

On Wed, Feb 21, 2018 at 6:36 AM, David Wolfskill  wrote:
> The Lua loader appears to be using a mechanism other than the
> "kernels=..." specification in /boot/loader.conf to slect potential
> kernels to load.  I'm not claiming this is "bad" -- just "different."
>
> I noticed because I sometimes build a kernel that ... panics, or some
> such thing, so I hve had occasion to make use of kernel.old.  But in the
> process of engaging a developer and trying patches, the default behavior
> is that kernel.old gets overwritten next time I build a kernel.
>
> So I had taken to copying /boot/*.old to /boot/*.save manually as the
> occasion warrants; I modified /boot/loader.conf to include:
>
> kernels="kernel kernel.old kernel.save"
>
> and the Forth loader presented (precisely) those kernels as the
> available options for selecting a kernel to load and boot.
>

Right, so, we (and by we I mean cem@) actually implemented a form of
auto-detection for kernels. Any directory in in /boot with a file
named 'kernel' inside will be automatically listed, and that
supplemented(*) 'kernels' and 'kernel' specified in loader.conf(5).

(*) I use "supplemented" because I changed that in r329709, just a
little bit ago, to not do the autodetection if a 'kernels' is
explicitly set in loader.conf(5) My reasoning here is that there's
probably a reason one has set it explicitly, whether it be to hide
bogus kernels or just to slim down the list of kernels they need to
cycle through.

> [ ... snip ... ]
___
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 Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor  wrote:
> Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>>
>> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
>> wrote:
>>>
>>> [... snip ...]
>>>
>>> Moreover, the "boot [kernel]" loader command does not work:
>>>
>>> OK ls /boot/kernel.old/kernel
>>>  /boot/kernel.old/kernel
>>> OK boot kernel.old
>>> Command failed
>>> OK boot /boot/kernel.old/kernel
>>> Command failed
>>> OK boot kernel
>>> Command failed
>>>
>>> On the other hand, just "boot" works.
>>>
>>
>> This part should work as expected as of r329674, so please give that a
>> shot. I'm still trying to see if I can reproduce your box drawing
>> problem.
>>
>> Thanks,
>>
>> Kyle Evans
>>
>
> Thanks Kyle.
>
> boot command works now. There is though a somewhat strangely formulated
> messages when trying to load an non-existent kernel:
>
> OK boot fake
> Failed to load kernel ’fake’
> Failed to load any kernel
> can’t load ’kernel’
>
> The two last lines are odd: Did the loader try to load a fallback kernel and
> failed? That would explain the ’kernel’ name in quotes, but I have such a
> kernel… Also, just nitpicking, but "can’t" should be capitalized.

(CC'ing Rod, since he also commented on this)

I'm only directly responsible for the first two messages. =) I've
removed the second one, though, since it was a carry-over from when it
would try to load the selected kernel and then some default kernel
that might be in your module_path.

We can look at changing "can't load 'kernel'" to capitalize and remove
the contraction, but that's common loader stuff and should've also
been displayed for the same Forth scenario.

> Then, I have just remembered why I was seeing a higher resolution menu
> before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new
> loader is not implementing the inclusion of this file, because I can change
> the gop mode in the loader with 'gop set [0-3]'.
>

Oy. This is actually a Forth file, so we can't really maintain all of
the functionality that would have been allowed there. Technically,
things like this should probably either appear in your loader.conf(5)
in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is
read, or we should provide some other means of running pure loader
command scripts at different points in the loader sequence. (CC
Warner, because he probably has thoughts about this latter idea)
___
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 selection in Lua loader

[David Wolfskill]

The Lua loader appears to be using a mechanism other than the
"kernels=..." specification in /boot/loader.conf to slect potential
kernels to load.  I'm not claiming this is "bad" -- just "different."

I noticed because I sometimes build a kernel that ... panics, or some
such thing, so I hve had occasion to make use of kernel.old.  But in the
process of engaging a developer and trying patches, the default behavior
is that kernel.old gets overwritten next time I build a kernel.

So I had taken to copying /boot/*.old to /boot/*.save manually as the
occasion warrants; I modified /boot/loader.conf to include:

kernels="kernel kernel.old kernel.save"

and the Forth loader presented (precisely) those kernels as the
available options for selecting a kernel to load and boot.

Usually, if I manually copy/move kernels around, I also save the kernel
that misbehaved (in case further poking around in its internals may be
warranted); a typical name for such a beast is "kernel.panic" (as I
usually have at most a single such misbehaving kernel around).

Thus, I noticed when I did my smoke-test boot after freshily building:

FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #108  
r329703M/329706:1200058: Wed Feb 21 04:04:36 PST 2018 
r...@g1-215.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY  amd64

with the Lua loader, I was being offered a choice among 4 kernels
(rather than the expected 3).  Cycling through them (twice; I wanted
to be sure the behavior was reproducible), I noted that the presented
options were:

* default/kernel
* kernel.old
* kernel.save
* kernel.panic

(in that sequence).  I did not attempt to select any of the non-default
options, however. :-)

Nor did I remove the 'kernels="kernel kernel.old kernel.save"'
specificaton from /boot/loader.conf to see what would happen.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Yes, the indictments don't "prove" guilt; that's what trials are for.

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


signature.asc
Description: PGP signature

Re: A small procedural request

[Tomoaki AOKI]

Hi.

+1. But have one suggestion for format.
Something like

 Broken by: rXXX
 Broken by: Unknown (Bugfix but the revision introduced it is unknown)

and optionally

 Broken by: No (To emphasize it's NOT a bugfix.)

would be better for scripts already handling "MFC after: " or
"X-MFC-With: " etc. to support this.

If put on the top with "MFC rXX: Comments", it can be

 FIX rXX: Comments

or for multiple revisions,

 FIX rXX rYY rZZ: Comments for multiple individuals
 FIX rXX-rYY: Comments for massive continuous range

would be better.

Regards.


On Wed, 21 Feb 2018 12:01:33 +0800
Julian Elischer  wrote:

> Hi,〓 I have a very small request to those committing into head.
> 
> If you commit a fix, then if it is possible to easily do so, can you 
> give the revision number in which the regression was introduced?
> 
> like "this was〓 broken in r329xxx"
> 
> this allows people who are looking for specific problems to say "Ok 
> that bug was introduced after the snapshot I'm working on and can't be 
> my issue".
> 
> (we are not always working on the very tip).
> 
> 
> thanks
> 
> Julian
> 
> 
> ___
> 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"
> 
> 


-- 
Tomoaki AOKI
___
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 20/02/2018 à 22:45, Kyle Evans a écrit :

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

[... snip ...]

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.



This part should work as expected as of r329674, so please give that a
shot. I'm still trying to see if I can reproduce your box drawing
problem.

Thanks,

Kyle Evans



Thanks Kyle.

boot command works now. There is though a somewhat strangely formulated 
messages when trying to load an non-existent kernel:


OK boot fake
Failed to load kernel ’fake’
Failed to load any kernel
can’t load ’kernel’

The two last lines are odd: Did the loader try to load a fallback kernel 
and failed? That would explain the ’kernel’ name in quotes, but I have 
such a kernel… Also, just nitpicking, but "can’t" should be capitalized.


Then, I have just remembered why I was seeing a higher resolution menu 
before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new 
loader is not implementing the inclusion of this file, because I can 
change the gop mode in the loader with 'gop set [0-3]'.


This has thus nothing to do with the drawing lines, I guess.

Best regards.
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Juan Ramón Molina Menor]

Le 20/02/2018 à 21:20, Mateusz Guzik a écrit :

Committed in https://svnweb.freebsd.org/base?view=revision=329660

thanks for reporting


Thanks Mateusz, Konstantin, issue solved.
___
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"