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

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

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

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

P2P core/daemon in Base?

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

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

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

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

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

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

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

Re: pkg does not recognize correct kernel version

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

Re: pkg does not recognize correct kernel version

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

Re: pkg does not recognize correct kernel version

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

Re: pkg does not recognize correct kernel version

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

Lua loader - geli passphrase issue

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 ___

Re: Kernel selection in Lua loader

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

Re: Lua loader - geli passphrase issue

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

Re: pkg does not recognize correct kernel version

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

Re: Kernel selection in Lua loader

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

Re: Kernel selection in Lua loader

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

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

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

GELI changes?

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

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

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

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

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

Re: A small procedural request

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

Re: Kernel selection in Lua loader

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

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

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

Kernel selection in Lua loader

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

Re: A small procedural request

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

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

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

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

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