Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

[Philip Paeps]

On 2024-05-08 23:53:57 (+0800), Mark Millard wrote:


On Apr 29, 2024, at 20:16, Mark Millard  wrote:


On Apr 29, 2024, at 20:11, Mark Millard  wrote:


On Apr 29, 2024, at 19:54, Mark Millard  wrote:


On Apr 28, 2024, at 18:06, Philip Paeps  wrote:


On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
On Apr 18, 2024, at 08:02, Mark Millard  
wrote:

void  wrote on
Date: Thu, 18 Apr 2024 14:08:36 UTC :


Not sure where to post this..

The last bulk build for arm64 appears to have happened around
mid-March on ampere2. Is it broken?


main-armv7 building is broken and the last completed build
was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It
gets stuck making no progress until manually forced to stop,
which leads to huge elapsed times for the incomplete builds:

[...]

My guess is that FreeBSD has something that broken after 
bd45bbe440
that was broken as of f5f08e41aa and was still broken at 
75464941dc .




One thing of possible note:

Failing . . .

Host OSVERSION: 156
Jail OSVERSION: 1500014


I have finished a package builder refresh this morning.  All our 
builder hosts (except PowerPC - I don't touch those) are now on 
main-n269671-feabaf8d5389 (OSVERSION 1500018).


ampere1 successfully finished its 140releng-armv7-quarterly build, 
so it looks like the problem with stuck builds was limited to 
ampere2 building main-armv7.  I'll keep a close eye on this one 
when it starts its next build.




I see that main-armv7 started.

It queued only 31935 instead of the prior 34528 (or more): it is 
doing an
incremental build instead of a full build. For example, pkg was not 
built
but instead the prior build is in use. Thus bad results from the 
prior

build might be involved in this new build.

I'd recommend forcing a full "poudriere bulk -c -a" that does a 
from-scratch

build for the purposes of the main-armv7 test.


Actually the test is not going to previde the information we are
after as things are.

giflib-5.2.2 failed to build, which leads to devel/doxygen being
skipped. devel/doxygen was the first one to hang up in the prior
2 failing attempts, if I remember right.

giflib-5.2.2 also causes graphics/graphviz to be skipped.
graphics/graphviz was installed just before the hangup in all of
the example hanups. So the context will not be replicated.

We need graphics/giflib to build to actually do the test.


Looks like:

https://cgit.freebsd.org/ports/commit/graphics/giflib?id=5007109903fc271e3ef0ba01d78781c1fed99f3f

is the fix for the graphic/giflib build failure.


Well, main-armv7 is building again and things are still
getting stuck. So much for my idea. For reference I
list the over 10-hr-so-far ones:

doxygen-1.9.6_1,2   build-depends 13:03:54
py39-pydot-2.0.0run-depends   12:24:04
py39-pygraphviz-1.6 lib-depends   12:10:38

"ps -alxdww" would likely be appropriate to get a copy
of the otuput of.

"procstat -k -k" usage and the like on stuck processes
would probably be appropriate.

Does anyone with appropriate investigative background
have login access to ampere2 to take a look at what
is getting stuck?


This is unfortunate.  I'm sure I have the appropriate background, but 
I'm spread very thin!  I'll get as much information as I can about this 
machine while it's stuck, before I bounce it again.


I think it may be worth a try building those ports in isolation on 
ref14-aarch64, and see what they're trying to do.  I'll also set up a 
set of refX-armv7 jails on that machine.


Hopefully we can get to the bottom of this soon.  This is a very tedious 
failure mode.


We could also try to put an older armv7 image on the builder jail on 
ampere2.  Depending on whether we have a sufficiently old image, that 
will either be very straightforward, or a very deep rabbit hole.


Thanks again for keeping an eye on this.  We really should have better 
monitoring for stuck builds than "Mark will tell us". :-)


Philip

Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]

[Mark Millard]

On Apr 29, 2024, at 20:16, Mark Millard  wrote:

> On Apr 29, 2024, at 20:11, Mark Millard  wrote:
> 
>> On Apr 29, 2024, at 19:54, Mark Millard  wrote:
>> 
>>> On Apr 28, 2024, at 18:06, Philip Paeps  wrote:
>>> 
 On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
> On Apr 18, 2024, at 08:02, Mark Millard  wrote:
>> void  wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>> 
>>> Not sure where to post this..
>>> 
>>> The last bulk build for arm64 appears to have happened around
>>> mid-March on ampere2. Is it broken?
>> 
>> main-armv7 building is broken and the last completed build
>> was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It
>> gets stuck making no progress until manually forced to stop,
>> which leads to huge elapsed times for the incomplete builds:
>> 
>> [...]
>> 
>> My guess is that FreeBSD has something that broken after bd45bbe440
>> that was broken as of f5f08e41aa and was still broken at 75464941dc .
>> 
> 
> One thing of possible note:
> 
> Failing . . .
> 
> Host OSVERSION: 156
> Jail OSVERSION: 1500014
 
 I have finished a package builder refresh this morning.  All our builder 
 hosts (except PowerPC - I don't touch those) are now on 
 main-n269671-feabaf8d5389 (OSVERSION 1500018).
 
 ampere1 successfully finished its 140releng-armv7-quarterly build, so it 
 looks like the problem with stuck builds was limited to ampere2 building 
 main-armv7.  I'll keep a close eye on this one when it starts its next 
 build.
 
>>> 
>>> I see that main-armv7 started.
>>> 
>>> It queued only 31935 instead of the prior 34528 (or more): it is doing an
>>> incremental build instead of a full build. For example, pkg was not built
>>> but instead the prior build is in use. Thus bad results from the prior
>>> build might be involved in this new build.
>>> 
>>> I'd recommend forcing a full "poudriere bulk -c -a" that does a from-scratch
>>> build for the purposes of the main-armv7 test.
>> 
>> Actually the test is not going to previde the information we are
>> after as things are.
>> 
>> giflib-5.2.2 failed to build, which leads to devel/doxygen being
>> skipped. devel/doxygen was the first one to hang up in the prior
>> 2 failing attempts, if I remember right.
>> 
>> giflib-5.2.2 also causes graphics/graphviz to be skipped.
>> graphics/graphviz was installed just before the hangup in all of
>> the example hanups. So the context will not be replicated.
>> 
>> We need graphics/giflib to build to actually do the test.
> 
> Looks like:
> 
> https://cgit.freebsd.org/ports/commit/graphics/giflib?id=5007109903fc271e3ef0ba01d78781c1fed99f3f
> 
> is the fix for the graphic/giflib build failure.

Well, main-armv7 is building again and things are still
getting stuck. So much for my idea. For reference I
list the over 10-hr-so-far ones:

doxygen-1.9.6_1,2   build-depends 13:03:54
py39-pydot-2.0.0run-depends   12:24:04
py39-pygraphviz-1.6 lib-depends   12:10:38

"ps -alxdww" would likely be appropriate to get a copy
of the otuput of.

"procstat -k -k" usage and the like on stuck processes
would probably be appropriate.

Does anyone with appropriate investigative background
have login access to ampere2 to take a look at what
is getting stuck?


===
Mark Millard
marklmi at yahoo.com

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 30/05/23 00:26, Ivan Quitschal wrote:



On Mon, 29 May 2023, Tomoaki AOKI wrote:


On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi  wrote:


On 28/05/23 20:45, Guido Falsi wrote:


It may well be something broke... but I'm just wanting to be double
sure it's against a consistent package set. If something broke, then I
can't help.


I see, I did not understand what you meant at first.

What I posted was the result of a simple "pkg upgrade", which is what I
usually do to update the machine, and usually works quite fine.

I have not tested forcing all packages reinstallation ("pkg upgrade -f"
if I get it correctly).

That is something I was already planning to do. Will report back
tomorrow for that.



Well forcing reinstallation of all ports (with rebuilt kmod ports) made
the issue disappear.

SO it looks like it was really nothing. Sorry for the noise and thanks
for the suggestions!

--
Guido Falsi 


IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.

This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.


--
Tomoaki AOKI    





try using this drm-kmod here, instead of the ones within ports

git clone https://github.com/freebsd/drm-kmod

thats the only one that works for me


I'm having good results with:

> pkg info -o '*kmod*'
drm-515-kmod-5.15.25_3 graphics/drm-515-kmod
gpu-firmware-amd-kmod-picasso-20230210 graphics/gpu-firmware-amd-kmod
gpu-firmware-amd-kmod-raven-20230210 graphics/gpu-firmware-amd-kmod


from the official tree.

--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 30/05/23 00:18, Tomoaki AOKI wrote:

On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi  wrote:


On 28/05/23 20:45, Guido Falsi wrote:


It may well be something broke... but I'm just wanting to be double
sure it's against a consistent package set. If something broke, then I
can't help.


I see, I did not understand what you meant at first.

What I posted was the result of a simple "pkg upgrade", which is what I
usually do to update the machine, and usually works quite fine.

I have not tested forcing all packages reinstallation ("pkg upgrade -f"
if I get it correctly).

That is something I was already planning to do. Will report back
tomorrow for that.



Well forcing reinstallation of all ports (with rebuilt kmod ports) made
the issue disappear.

SO it looks like it was really nothing. Sorry for the noise and thanks
for the suggestions!

--
Guido Falsi 


IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.

This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.


Poudriere did not rebuild the kmod ports since there was no 
__FreeBSD_version change. I usually force it being rebuild by hand, but 
this time I forgot!


I did force pkg reinstall for it by hand, but this just reinstalled the 
same previous package.


In the end I forced rebuilding it and reinstalling everything and the 
issue disappeared.


--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Ivan Quitschal]

On Mon, 29 May 2023, Tomoaki AOKI wrote:


On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi  wrote:


On 28/05/23 20:45, Guido Falsi wrote:


It may well be something broke... but I'm just wanting to be double
sure it's against a consistent package set. If something broke, then I
can't help.


I see, I did not understand what you meant at first.

What I posted was the result of a simple "pkg upgrade", which is what I
usually do to update the machine, and usually works quite fine.

I have not tested forcing all packages reinstallation ("pkg upgrade -f"
if I get it correctly).

That is something I was already planning to do. Will report back
tomorrow for that.



Well forcing reinstallation of all ports (with rebuilt kmod ports) made
the issue disappear.

SO it looks like it was really nothing. Sorry for the noise and thanks
for the suggestions!

--
Guido Falsi 


IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.

This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.


--
Tomoaki AOKI





try using this drm-kmod here, instead of the ones within ports

git clone https://github.com/freebsd/drm-kmod

thats the only one that works for me

--tzk

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Tomoaki AOKI]

On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi  wrote:

> On 28/05/23 20:45, Guido Falsi wrote:
> 
> >> It may well be something broke... but I'm just wanting to be double 
> >> sure it's against a consistent package set. If something broke, then I 
> >> can't help.
> > 
> > I see, I did not understand what you meant at first.
> > 
> > What I posted was the result of a simple "pkg upgrade", which is what I 
> > usually do to update the machine, and usually works quite fine.
> > 
> > I have not tested forcing all packages reinstallation ("pkg upgrade -f" 
> > if I get it correctly).
> > 
> > That is something I was already planning to do. Will report back 
> > tomorrow for that.
> > 
> 
> Well forcing reinstallation of all ports (with rebuilt kmod ports) made 
> the issue disappear.
> 
> SO it looks like it was really nothing. Sorry for the noise and thanks 
> for the suggestions!
> 
> -- 
> Guido Falsi 

IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.

This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.


-- 
Tomoaki AOKI

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 28/05/23 20:45, Guido Falsi wrote:

It may well be something broke... but I'm just wanting to be double 
sure it's against a consistent package set. If something broke, then I 
can't help.


I see, I did not understand what you meant at first.

What I posted was the result of a simple "pkg upgrade", which is what I 
usually do to update the machine, and usually works quite fine.


I have not tested forcing all packages reinstallation ("pkg upgrade -f" 
if I get it correctly).


That is something I was already planning to do. Will report back 
tomorrow for that.




Well forcing reinstallation of all ports (with rebuilt kmod ports) made 
the issue disappear.


SO it looks like it was really nothing. Sorry for the noise and thanks 
for the suggestions!


--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 28/05/23 18:22, Warner Losh wrote:



On Sun, May 28, 2023, 9:20 AM Guido Falsi <mailto:m...@madpilot.net>> wrote:


On 28/05/23 16:41, Warner Losh wrote:
 > Sill questions.  Did you update only some of your packages? You
really
 > need to update them all at the same time to have them be compatible.
 > Some projects have a fast moving abi they don't keep compatible
very well.
 >

I'm running FreeBSD head here, using pkgbase. I upgraded a few base
packages (I create them with poudriere).

I also updated the ports tree and updated other ports using the
resulting binaries (also created with poudriere)

The pkgs that were updated when xfwm4 stopped working were listed in my
first post [1].


So not all of the non pkg base packages? Have you tried updating them 
all? Or you did update them all and the list of what updated was in the 
post? I read it when first posted and again now and am unsure which it is...


It may well be something broke... but I'm just wanting to be double sure 
it's against a consistent package set. If something broke, then I can't 
help.


I see, I did not understand what you meant at first.

What I posted was the result of a simple "pkg upgrade", which is what I 
usually do to update the machine, and usually works quite fine.


I have not tested forcing all packages reinstallation ("pkg upgrade -f" 
if I get it correctly).


That is something I was already planning to do. Will report back 
tomorrow for that.


--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Graham Perrin]

On 27/05/2023 09:31, Guido Falsi wrote:
I'm seeing a strange issue with xfwm4 on my laptop 


How much memory, how much VRAM?

running head (commit 5804b7ab378d6207130bd1685c931da6a4e76e55), using 
pkgbase, everything build on poudriere.


I have filed an issue upstream with a description and some finding:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/722

…


I recently had a blackout on CURRENT with every start of Xfce. I didn't 
bother to look at details of the blackout, but I worked around by giving 
more memory to the virtual machine.




OpenPGP_signature
Description: OpenPGP digital signature

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Warner Losh]

On Sun, May 28, 2023, 9:20 AM Guido Falsi  wrote:

> On 28/05/23 16:41, Warner Losh wrote:
> > Sill questions.  Did you update only some of your packages? You really
> > need to update them all at the same time to have them be compatible.
> > Some projects have a fast moving abi they don't keep compatible very
> well.
> >
>
> I'm running FreeBSD head here, using pkgbase. I upgraded a few base
> packages (I create them with poudriere).
>
> I also updated the ports tree and updated other ports using the
> resulting binaries (also created with poudriere)
>
> The pkgs that were updated when xfwm4 stopped working were listed in my
> first post [1].
>

So not all of the non pkg base packages? Have you tried updating them all?
Or you did update them all and the list of what updated was in the post? I
read it when first posted and again now and am unsure which it is...

It may well be something broke... but I'm just wanting to be double sure
it's against a consistent package set. If something broke, then I can't
help.

Also a good time to plug zfs root and snapshots to roll back to if the
upgrade fails. But that's like for future you...

I tested downgrading glib, but nothing changed. Other things updated
> there look completely unrelated (well except the kernel obviously).
>


Yea, I've rarely had good luck with that path.


> Now that you mention it, I may have forgot to force poudriere to rebuild
> the drm-kmod port. I'll try that, just in case!
>

That's unlikely the cause. Though it wouldn't hurt. Usually it simply won't
load. And this package us matched to a specific kernel so make sure you
rebuild against the headers of the kernel installed.

Warner

[1] https://lists.freebsd.org/archives/freebsd-current/2023-May/003734.html
>
> --
> Guido Falsi 
>
>

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 28/05/23 16:41, Warner Losh wrote:
Sill questions.  Did you update only some of your packages? You really 
need to update them all at the same time to have them be compatible. 
Some projects have a fast moving abi they don't keep compatible very well.




I'm running FreeBSD head here, using pkgbase. I upgraded a few base 
packages (I create them with poudriere).


I also updated the ports tree and updated other ports using the 
resulting binaries (also created with poudriere)


The pkgs that were updated when xfwm4 stopped working were listed in my 
first post [1].


I tested downgrading glib, but nothing changed. Other things updated 
there look completely unrelated (well except the kernel obviously).



Now that you mention it, I may have forgot to force poudriere to rebuild 
the drm-kmod port. I'll try that, just in case!




[1] https://lists.freebsd.org/archives/freebsd-current/2023-May/003734.html

--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Warner Losh]

Sill questions.  Did you update only some of your packages? You really need
to update them all at the same time to have them be compatible. Some
projects have a fast moving abi they don't keep compatible very well.

Warner

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 28/05/23 16:03, Alastair Hogge wrote:

Hello Guido,

On 2023-05-28 12:44, Guido Falsi wrote:

On 28/05/23 00:42, Alastair Hogge wrote:

Hello,

Is there some way to test your X session with minimum components, and slowly 
adding whatever XFCE does?


Maybe I was not perfectly clear. Xorg works fine, I already tested with another 
window manager.


Perfection is an unhealthy Neo-liberal ideology, I avoid it at all cost.
I missed the gitlab link earlier, tho thank you so much for taking the
time to explain that again to me, sorry if I have caused an
inconvenience here.


Well Maybe I came out a little aggressive, I did not mean perfection in 
any special way, just as a form of speech.


Unluckily this is not an easy one to properly debug. I was lucky enough 
to find a workaround that is "good enough".




My sympathies in your struggle, from another AMD GPU FreeBSD struggler.


Actually my first struggle with AMD on this laptop, it has worked quite 
fine up to now. My other AMD machine I use as a headless builder, I 
sometimes connect a monitor but just to get to the console, so graphics 
drivers are not an issue there.


--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Alastair Hogge]

Hello Guido,

On 2023-05-28 12:44, Guido Falsi wrote:
> On 28/05/23 00:42, Alastair Hogge wrote:
>> Hello,
>> 
>> Is there some way to test your X session with minimum components, and slowly 
>> adding whatever XFCE does?
> 
> Maybe I was not perfectly clear. Xorg works fine, I already tested with 
> another window manager.

Perfection is an unhealthy Neo-liberal ideology, I avoid it at all cost.
I missed the gitlab link earlier, tho thank you so much for taking the
time to explain that again to me, sorry if I have caused an
inconvenience here.

My sympathies in your struggle, from another AMD GPU FreeBSD struggler.

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 28/05/23 00:42, Alastair Hogge wrote:

Hello,

Is there some way to test your X session with minimum components, and 
slowly adding whatever XFCE does?


Maybe I was not perfectly clear. Xorg works fine, I already tested with 
another window manager.


The only thing that changed is that I updated to more recent head, 
updated a bunch of ports (none directly related to Xorg/DRI3) and xfwm4 
started crashing with the errors I reported. Everything else seems to 
work fine (except other xfce components that depend on xfwm4, which show 
various degrees of bad behavior caused by xfwm4 not running).


xfwm4 was NOT updated or reinstalled.



I would switch from using a X Display Manager, and launch X from the 
login vty using startx (if not already ), with a minimum .xinitrc. I 
would find out what is needed to get a minimal XFCE going, for example, 
maybe just the Window Manager, no Compositor, or nothing at all to see 
if X handles the display mode setting at all.


As I said this is something already easily tested. Everything works 
except xfwm4 crashes on startup if DRI3 is enabled.


I am reasonably sure xfwm4 would not crash if compiled without 
compositor support, since the crash happens in code that is protected by 
ifdefs and would be removed is disabling compositor.


That should would also not run if disabling the compositor, so I'm 
reasonably sure that would be another possible (but even uglier than 
disabling DRI3) workaround.




Also, where are your X logs? It is is normally at /var/log/X.something. 
It this log empty after the crash?


As stated before I posted a bug report with xfce:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/722

Please go there, there is the relevant line from .xsession-errors and a 
backtrace from the core file xfwm4 left behind.



As a further note, for my usage keeping DRI3 is not a problem, so if the 
only worry I had was to get working xfce on my laptop I would be finished.


What, instead, I'd like to try to understand is what is causing this and 
if it could affect more users in the future.


--
Guido Falsi 

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Alastair Hogge]

Hello,

Is there some way to test your X session with minimum components, and slowly 
adding whatever XFCE does?

I would switch from using a X Display Manager, and launch X from the login vty 
using startx (if not already ), with a minimum .xinitrc. I would find out what 
is needed to get a minimal XFCE going, for example, maybe just the Window 
Manager, no Compositor, or nothing at all to see if X handles the display mode 
setting at all.

Also, where are your X logs? It is is normally at /var/log/X.something. It this 
log empty after the crash?


To anarchy and health 

On 28 May 2023 2:03:51 am AWST, Guido Falsi  wrote:
>On 27/05/23 10:31, Guido Falsi wrote:
>> Hi,
>> 
>> I'm seeing a strange issue with xfwm4 on my laptop running head (commit 
>> 5804b7ab378d6207130bd1685c931da6a4e76e55), using pkgbase, everything build 
>> on poudriere.
>> 
>> I have filed an issue upstream with a description and some finding:
>> 
>> https://gitlab.xfce.org/xfce/xfwm4/-/issues/722
>> 
>> I'm testing changing some things but I get the same exact error 100% 
>> repeatable.
>> 
>
>A friend of mine suggested trying to disable DRI 3 and this indeed allowed 
>xfwm4 to not crash.
>
>This is a workaround, not a fix, and does not explain what is causing the 
>behavior.
>
>Not sure where I should be looking, I'll also check changes in kernel that 
>could be related.
>
>Again if anyone has some insight please share!
>
>-- 
>Guido Falsi 
>
>

-- 
Sent from a device with a tiny bloody screen and no hard keyboard; please 
excuse my brevity.

Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

On 27/05/23 10:31, Guido Falsi wrote:

Hi,

I'm seeing a strange issue with xfwm4 on my laptop running head (commit 
5804b7ab378d6207130bd1685c931da6a4e76e55), using pkgbase, everything 
build on poudriere.


I have filed an issue upstream with a description and some finding:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/722

I'm testing changing some things but I get the same exact error 100% 
repeatable.




A friend of mine suggested trying to disable DRI 3 and this indeed 
allowed xfwm4 to not crash.


This is a workaround, not a fix, and does not explain what is causing 
the behavior.


Not sure where I should be looking, I'll also check changes in kernel 
that could be related.


Again if anyone has some insight please share!

--
Guido Falsi 

Help request: strange issue with xfce xfwm4 on AMD hardware, running head

[Guido Falsi]

Hi,

I'm seeing a strange issue with xfwm4 on my laptop running head (commit 
5804b7ab378d6207130bd1685c931da6a4e76e55), using pkgbase, everything 
build on poudriere.


I have filed an issue upstream with a description and some finding:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/722

I'm testing changing some things but I get the same exact error 100% 
repeatable.


I'm now going to try older drm (machine has drm-515, will try drm-510).

Don't expect a solution, but what I'm looking for is suggestions on 
where I could try looking for a solution. At present I'm just shuffling 
things around hoping to stumble on something that fixes it.


I also fear this could become a more generalized problem once the cause 
reaches (via latest or quarterly packages, or release of 14.0 for 
example) more users. I'd really rather exclude this eventuality.


What changed since it was running fine is base was updated to very 
recent head(via pkgbase) and the following ports:


May 23 09:34:06 ubik pkg[4420]: xorgproto upgraded: 2022.1 -> 2022.1_1
May 23 09:34:06 ubik pkg[4420]: libxfce4menu upgraded: 4.18.3 -> 4.18.4
May 23 09:34:06 ubik pkg[4420]: double-conversion upgraded: 3.2.1 -> 3.3.0
May 23 09:34:06 ubik pkg[4420]: libuv upgraded: 1.44.2 -> 1.45.0
May 23 09:34:09 ubik pkg[4420]: FreeBSD-kernel-generic upgraded: 
14.snap20230512220621 -> 14.snap20230522103000

May 23 09:34:10 ubik pkg[4420]: qt6-base reinstalled: 6.4.2_2 -> 6.4.2_2
May 23 09:34:13 ubik pkg[4420]: FreeBSD-utilities upgraded: 
14.snap20230513072958 -> 14.snap20230522103000
May 23 09:34:13 ubik pkg[4420]: FreeBSD-yp upgraded: 
14.snap20230425153702 -> 14.snap20230522103000
May 23 09:34:14 ubik pkg[4420]: FreeBSD-sendmail upgraded: 
14.snap20230425153702 -> 14.snap20230522103000

May 23 09:34:14 ubik pkg[4420]: dua-cli upgraded: 2.19.2_2 -> 2.20.1
May 23 09:34:14 ubik pkg[4420]: FreeBSD-zoneinfo upgraded: 
14.snap20230425153702 -> 14.snap20230522103000

May 23 09:34:14 ubik pkg[4420]: vmutils upgraded: 1.87.4_1 -> 1.87.6
May 23 09:34:14 ubik pkg[4420]: gexiv2 upgraded: 0.14.0 -> 0.14.1
May 23 09:34:16 ubik pkg[4420]: FreeBSD-tests upgraded: 
14.snap20230512220621 -> 14.snap20230522103000

May 23 09:34:16 ubik pkg[4420]: xfce4-panel upgraded: 4.18.3_1 -> 4.18.4
May 23 09:34:19 ubik pkg[4420]: boost-libs upgraded: 1.82.0 -> 1.82.0_1
May 23 09:34:19 ubik pkg[4420]: babl upgraded: 0.1.102 -> 0.1.106
May 23 09:34:19 ubik pkg[4420]: firefox upgraded: 113.0.1,2 -> 113.0.2,2
May 23 09:34:21 ubik pkg[4420]: FreeBSD-runtime-dev upgraded: 
14.snap20230512220621 -> 14.snap20230522103000

May 23 09:34:21 ubik pkg[4420]: curl upgraded: 8.0.1 -> 8.1.0
May 23 09:34:21 ubik pkg[4420]: FreeBSD-unbound upgraded: 
14.snap20230512220621 -> 14.snap20230522103000


--
Guido Falsi 

Realtek rtw89 - in main - help request (fwd)

[Bjoern A. Zeeb]

Hi,

I figured not all may follow freebsd-wireless so forwarding here.
Please follow-up on freebsd-wireless or with me if possible.

Lots of joy,
/bz

--
Bjoern A. Zeeb r15:7

-- Forwarded message --
Date: Fri, 9 Sep 2022 16:49:38 + (UTC)
From: Bjoern A. Zeeb 
To: FreeBSD wireless mailing list 
Subject: Realtek rtw89 - in main - help request

Hi,

I just added Realtek's rtw89 driver to main (CURRENT, HEAD we have too
many names for that since CVS days).  I've been sitting for too long on
it (almost done) and figured that "you" could help if it was available.

It is still disconected from the build, the man page is missing, .. but
if added to sys/modules/Makefile would compile, load, load firmware,
create a wireless interface, scan...

I'll update https://wiki.freebsd.org/WiFi/Rtw89 in a bit to add any
news I can think of.

*** Important for rtw89 owners ***

I know I exchanged emails with some of you before.
If you have an rtw89 (89 not 88!) please drop me a line and mention
(1) if you want to test as-is now;  it would be good if the current
state as I see it can be replicated
(2) are able to help debugging and/or implementing what is left to pass
packets
(3) you cannot do (2) but you'd be willing to test changes if (1) worked
for you.

I'll be at EuroBSDCon next week, so my reply time may vary.  If you have
an rtw89 and be there definitively corner me! :)

Thakns a lot,
Bjoern

--
Bjoern A. Zeeb r15:7

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/27/2022 3:58 pm, Mark Johnston wrote:

On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote:

On 02/26/2022 11:08 am, Larry Rosenman wrote:
> On 02/26/2022 10:57 am, Larry Rosenman wrote:
>> On 02/26/2022 10:37 am, Juraj Lutter wrote:
 On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
 I'm running this script:
 #!/bin/sh
 for i in $(zfs list -H | awk '{print $1}')
 do
   FS=$1
   FN=$(echo ${FS} | sed -e s@/@_@g)
   sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh
 l...@freenas.lerctr.org cat - \> $FN
 done



>>> I’d put, like:
>>>
>>> echo ${FS}
>>>
>>> before “sudo zfs send”, to get at least a bit of a clue on where it
>>> can get to.
>>>
>>> otis
>>>
>>>
>>> —
>>> Juraj Lutter
>>> o...@freebsd.org
>> I just looked at the destination to see where it died (it did!) and I
>> bectl destroy'd the
>> BE that crashed it, and am running a new scrub -- we'll see whether
>> that was sufficient.
>>
>> Thanks, all!
> Well, it was NOT sufficient More zfs export fun to come :(

I was able to export the rest of the datasets, and re-install 
14-CURRENT

from a recent snapshot, and restore the datasets I care about.

I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the
controller device node, about the size of a disk.  Presumably this is
the result of some kind of misconfiguration somewhere, and /dev/mfid0
was meant instead.



per advice from markj@ I deleted the /{etc,boot}/zfs/zpool.cache files, 
and this issue went

away.  Stale cache files which are no longer needed.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Mark Johnston]

On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote:
> On 02/26/2022 11:08 am, Larry Rosenman wrote:
> > On 02/26/2022 10:57 am, Larry Rosenman wrote:
> >> On 02/26/2022 10:37 am, Juraj Lutter wrote:
>  On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
>  I'm running this script:
>  #!/bin/sh
>  for i in $(zfs list -H | awk '{print $1}')
>  do
>    FS=$1
>    FN=$(echo ${FS} | sed -e s@/@_@g)
>    sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh 
>  l...@freenas.lerctr.org cat - \> $FN
>  done
>  
>  
>  
> >>> I’d put, like:
> >>> 
> >>> echo ${FS}
> >>> 
> >>> before “sudo zfs send”, to get at least a bit of a clue on where it 
> >>> can get to.
> >>> 
> >>> otis
> >>> 
> >>> 
> >>> —
> >>> Juraj Lutter
> >>> o...@freebsd.org
> >> I just looked at the destination to see where it died (it did!) and I
> >> bectl destroy'd the
> >> BE that crashed it, and am running a new scrub -- we'll see whether
> >> that was sufficient.
> >> 
> >> Thanks, all!
> > Well, it was NOT sufficient More zfs export fun to come :(
> 
> I was able to export the rest of the datasets, and re-install 14-CURRENT 
> from a recent snapshot, and restore the datasets I care about.
> 
> I'm now seeing:
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> pid 48 (zpool), jid 0, uid 0: exited on signal 6
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> pid 54 (zpool), jid 0, uid 0: exited on signal 6
> 
> On boot.  Ideas?

That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the
controller device node, about the size of a disk.  Presumably this is
the result of some kind of misconfiguration somewhere, and /dev/mfid0
was meant instead.

Re: ZFS PANIC: HELP.

[Michael Butler]

On 2/27/22 16:09, Larry Rosenman wrote:

On 02/27/2022 3:03 pm, Michael Butler wrote:

[ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 
14-CURRENT from a recent snapshot, and restore the datasets I care 
about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and
mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended
up setting the debug flag for mrsas in /etc/sysctl.conf ..

dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael


I don't see it:
✖1 ❯ sysctl dev.mfi
dev.mfi.0.keep_deleted_volumes: 0
dev.mfi.0.delete_busy_volumes: 0
dev.mfi.0.%parent: pci3
dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 
subdevice=0x1f17 class=0x010400

dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0
dev.mfi.0.%driver: mfi
dev.mfi.0.%desc: Dell PERC H700 Integrated
dev.mfi.%parent:


 my brain-fade - you're right; it is only there and tunable in the 
mrsas driver.


My apologies :-(

Michael

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/27/2022 3:03 pm, Michael Butler wrote:

[ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 
14-CURRENT from a recent snapshot, and restore the datasets I care 
about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and
mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended
up setting the debug flag for mrsas in /etc/sysctl.conf ..

dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael


I don't see it:
✖1 ❯ sysctl dev.mfi
dev.mfi.0.keep_deleted_volumes: 0
dev.mfi.0.delete_busy_volumes: 0
dev.mfi.0.%parent: pci3
dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 
subdevice=0x1f17 class=0x010400

dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0
dev.mfi.0.%driver: mfi
dev.mfi.0.%desc: Dell PERC H700 Integrated
dev.mfi.%parent:

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Michael Butler]

 [ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 14-CURRENT 
from a recent snapshot, and restore the datasets I care about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and mrsas 
drivers to be 'chatty' in this way - IOCTL complaints. I ended up 
setting the debug flag for mrsas in /etc/sysctl.conf ..


dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/26/2022 11:08 am, Larry Rosenman wrote:

On 02/26/2022 10:57 am, Larry Rosenman wrote:

On 02/26/2022 10:37 am, Juraj Lutter wrote:

On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh 
l...@freenas.lerctr.org cat - \> $FN

done




I’d put, like:

echo ${FS}

before “sudo zfs send”, to get at least a bit of a clue on where it 
can get to.


otis


—
Juraj Lutter
o...@freebsd.org

I just looked at the destination to see where it died (it did!) and I
bectl destroy'd the
BE that crashed it, and am running a new scrub -- we'll see whether
that was sufficient.

Thanks, all!

Well, it was NOT sufficient More zfs export fun to come :(


I was able to export the rest of the datasets, and re-install 14-CURRENT 
from a recent snapshot, and restore the datasets I care about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/26/2022 10:57 am, Larry Rosenman wrote:

On 02/26/2022 10:37 am, Juraj Lutter wrote:

On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh 
l...@freenas.lerctr.org cat - \> $FN

done




I’d put, like:

echo ${FS}

before “sudo zfs send”, to get at least a bit of a clue on where it 
can get to.


otis


—
Juraj Lutter
o...@freebsd.org

I just looked at the destination to see where it died (it did!) and I
bectl destroy'd the
BE that crashed it, and am running a new scrub -- we'll see whether
that was sufficient.

Thanks, all!

Well, it was NOT sufficient More zfs export fun to come :(

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/26/2022 10:37 am, Juraj Lutter wrote:

On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh l...@freenas.lerctr.org 
cat - \> $FN

done




I’d put, like:

echo ${FS}

before “sudo zfs send”, to get at least a bit of a clue on where it can 
get to.


otis


—
Juraj Lutter
o...@freebsd.org
I just looked at the destination to see where it died (it did!) and I 
bectl destroy'd the
BE that crashed it, and am running a new scrub -- we'll see whether that 
was sufficient.


Thanks, all!
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Leidinger]

 Quoting Larry Rosenman  (from Fri, 25 Feb 2022  
20:03:51 -0600):



On 02/25/2022 2:11 am, Alexander Leidinger wrote:

Quoting Larry Rosenman  (from Thu, 24 Feb 2022  
20:19:45 -0600):



I tried a scrub -- it panic'd on a fatal double fault. 

  Suggestions?


 The safest / cleanest (but not fastest) is data export and  
pool re-creation. If you export dataset by dataset (instead of  
recursively all), you can even see which dataset is causing the  
issue. In case this per dataset export narrows down the issue and  
it is a dataset you don't care about (as in: 1) no issue to  
recreate from scratch or 2) there is a backup available) you could  
delete this (or each such) dataset and re-create it in-place (= not  
re-creating the entire pool).


Bye,
Alexander.
 http://www.Leidinger.net alexan...@leidinger.net: PGP  
0x8F31830F9F2772BF

http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF


  I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh  
l...@freenas.lerctr.org cat - \> $FN

done

   

  How will I know a "Problem" dataset?


You told a scrub is panicing the system. A scrub only touches occupied  
blocks. As such a problem-dataset should panic your system. If it  
doesn't panic at all, the problem may be within a snapshot which  
contains data which is deleted in later versions of the dataset.


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpYqsU391ZUr.pgp
Description: Digitale PGP-Signatur

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/25/2022 2:11 am, Alexander Leidinger wrote:

Quoting Larry Rosenman  (from Thu, 24 Feb 2022 20:19:45 
-0600):



I tried a scrub -- it panic'd on a fatal double fault.

Suggestions?


The safest / cleanest (but not fastest) is data export and pool 
re-creation. If you export dataset by dataset (instead of recursively 
all), you can even see which dataset is causing the issue. In case this 
per dataset export narrows down the issue and it is a dataset you don't 
care about (as in: 1) no issue to recreate from scratch or 2) there is 
a backup available) you could delete this (or each such) dataset and 
re-create it in-place (= not re-creating the entire pool).


Bye,
Alexander.

http://www.Leidinger.net alexan...@leidinger.net: PGP 
0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 
0x8F31830F9F2772BF


I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh l...@freenas.lerctr.org 
cat - \> $FN

done

How will I know a "Problem" dataset?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Leidinger]

 Quoting Larry Rosenman  (from Thu, 24 Feb 2022  
20:19:45 -0600):



I tried a scrub -- it panic'd on a fatal double fault. 

  Suggestions?


The safest / cleanest (but not fastest) is data export and pool  
re-creation. If you export dataset by dataset (instead of recursively  
all), you can even see which dataset is causing the issue. In case  
this per dataset export narrows down the issue and it is a dataset you  
don't care about (as in: 1) no issue to recreate from scratch or 2)  
there is a backup available) you could delete this (or each such)  
dataset and re-create it in-place (= not re-creating the entire pool).


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpbleK3b3rSl.pgp
Description: Digitale PGP-Signatur

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/24/2022 8:07 pm, Larry Rosenman wrote:


On 02/24/2022 1:27 pm, Larry Rosenman wrote:

On 02/24/2022 10:48 am, Rob Wing wrote:

even with those set, I still get the panid. :(

Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL 
system.


UGH.


I chroot'd to the pool, and built a no invariants kernel.  It booted and 
seems(!) to be running.


Is there any diagnostics/clearing the crappy ZIL?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

I tried a scrub -- it panic'd on a fatal double fault.

Suggestions?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/24/2022 1:27 pm, Larry Rosenman wrote:


On 02/24/2022 10:48 am, Rob Wing wrote:


even with those set, I still get the panid. :(


Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL 
system.


UGH.


I chroot'd to the pool, and built a no invariants kernel.  It booted and 
seems(!) to be running.


Is there any diagnostics/clearing the crappy ZIL?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/24/2022 10:48 am, Rob Wing wrote:


Yes, I believe so.

On Thu, Feb 24, 2022 at 7:42 AM Larry Rosenman  wrote:

On 02/24/2022 10:36 am, Rob Wing wrote:

You might try setting `sysctl vfs.zfs.recover=1` and `sysctl 
vfs.zfs.spa.load_verify_metadata=0`.


I had a similar error the other day (couple months ago). The best I did 
was being able to import the pool read only. I ended up restoring from 
backup.


Are those tunables that I can set in loader.conf?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

even with those set, I still get the panid. :(

Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL 
system.


UGH.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Rob Wing]

Yes, I believe so.

On Thu, Feb 24, 2022 at 7:42 AM Larry Rosenman  wrote:

> On 02/24/2022 10:36 am, Rob Wing wrote:
>
> You might try setting `sysctl vfs.zfs.recover=1` and `sysctl
> vfs.zfs.spa.load_verify_metadata=0`.
>
> I had a similar error the other day (couple months ago). The best I did
> was being able to import the pool read only. I ended up restoring from
> backup.
>
>
>
> Are those tunables that I can set in loader.conf?
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/24/2022 10:36 am, Rob Wing wrote:

You might try setting `sysctl vfs.zfs.recover=1` and `sysctl 
vfs.zfs.spa.load_verify_metadata=0`.


I had a similar error the other day (couple months ago). The best I did 
was being able to import the pool read only. I ended up restoring from 
backup.






Are those tunables that I can set in loader.conf?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Rob Wing]

You might try setting `sysctl vfs.zfs.recover=1` and `sysctl
vfs.zfs.spa.load_verify_metadata=0`.

I had a similar error the other day (couple months ago). The best I did was
being able to import the pool read only. I ended up restoring from backup.

On Thu, Feb 24, 2022 at 7:30 AM Alexander Motin  wrote:

> On 24.02.2022 10:57, Larry Rosenman wrote:
> > On 02/23/2022 9:27 pm, Larry Rosenman wrote:
> >> It crashes just after root mount (this is the boot pool and only pool
> >> on the system),
> >> seeL
> >> https://www.lerctr.org/~ler/14-BOOT-Crash.png
> >
> > Where do I go from here?
>
> I see 2 ways: 1) Since it is only an assertion and 13 is working (so
> far), you may just build 14 kernel without INVARIANTS option and later
> recreate the pool when you have time.  2) You may treat it as metadata
> corruption: import pool read-only and evacuate the data.  If you have
> recent enough snapshots you may be able to easily replicate the pool
> with all the settings to some other disk.  ZIL is not replicated, so
> corruptions there should not be a problem.  If there are no snapshots,
> then either copy on file level, or you may be able to create snapshot
> for replication in 13 (on 14 without INVARIANTS), importing pool
> read-write.
>
> --
> Alexander Motin
>
>

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/24/2022 10:29 am, Alexander Motin wrote:

On 24.02.2022 10:57, Larry Rosenman wrote:

On 02/23/2022 9:27 pm, Larry Rosenman wrote:

It crashes just after root mount (this is the boot pool and only pool
on the system),
seeL
https://www.lerctr.org/~ler/14-BOOT-Crash.png


Where do I go from here?


I see 2 ways: 1) Since it is only an assertion and 13 is working (so
far), you may just build 14 kernel without INVARIANTS option and later
recreate the pool when you have time.  2) You may treat it as metadata
corruption: import pool read-only and evacuate the data.  If you have
recent enough snapshots you may be able to easily replicate the pool
with all the settings to some other disk.  ZIL is not replicated, so
corruptions there should not be a problem.  If there are no snapshots,
then either copy on file level, or you may be able to create snapshot
for replication in 13 (on 14 without INVARIANTS), importing pool
read-write.


Ugh.  The box is a 6 disk R710, and all 6 disks are in the pool.

I do have a FreeNAS box with enough space to copy the data out.  There 
ARE snaps of MOST filesystems that are taken regularly.


The 13 I'm booting from is the 13 memstick image.

There are ~70 filesystems (IIRC) with poudriere, ports, et al.

I'm not sure how to build the 14 kernel from the 13 booted box.

Ideas?  Methods?


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Motin]

On 24.02.2022 10:57, Larry Rosenman wrote:

On 02/23/2022 9:27 pm, Larry Rosenman wrote:

It crashes just after root mount (this is the boot pool and only pool
on the system),
seeL
https://www.lerctr.org/~ler/14-BOOT-Crash.png


Where do I go from here?


I see 2 ways: 1) Since it is only an assertion and 13 is working (so 
far), you may just build 14 kernel without INVARIANTS option and later 
recreate the pool when you have time.  2) You may treat it as metadata 
corruption: import pool read-only and evacuate the data.  If you have 
recent enough snapshots you may be able to easily replicate the pool 
with all the settings to some other disk.  ZIL is not replicated, so 
corruptions there should not be a problem.  If there are no snapshots, 
then either copy on file level, or you may be able to create snapshot 
for replication in 13 (on 14 without INVARIANTS), importing pool read-write.


--
Alexander Motin

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/23/2022 9:27 pm, Larry Rosenman wrote:

On 02/23/2022 9:15 pm, Alexander Motin wrote:

On 23.02.2022 22:01, Larry Rosenman wrote:

On 02/23/2022 8:58 pm, Alexander Motin wrote:

On 23.02.2022 21:52, Larry Rosenman wrote:

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that 
debugging

enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log 
records
(or false positive), that could happen so due to use of -F 
recovery
option on `zpool import`, that supposed to try import pool at 
earlier
transaction group if there is some metadata corruption found.  It 
is
not supposed to work 100% and only a last resort.  Though may be 
that
assertion is just excessively strict for that specific recovery 
case.
If as you say pool can be imported and scrubbed on 13, then I'd 
expect

following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot 
at https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access 
to the console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I 
can export it cleanly on the 13 system?


Why do you need to import without mounting file systems?  I think 
you

may actually wish them to be mounted to replay their ZILs.  Just use
-R option to mount file systems in some different place.


I get the errors shown at:
https://www.lerctr.org/~ler/14-mount-R-output.png

Should I worry?  Or do something(tm) here?


This looks weird, but may possibly depend on mount points topology,
whether /mnt is writable, etc.  What happen if you export it now and
try to import it in normal way on 14 without -F?


It crashes just after root mount (this is the boot pool and only pool
on the system),
seeL
https://www.lerctr.org/~ler/14-BOOT-Crash.png


Where do I go from here?


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/23/2022 9:15 pm, Alexander Motin wrote:

On 23.02.2022 22:01, Larry Rosenman wrote:

On 02/23/2022 8:58 pm, Alexander Motin wrote:

On 23.02.2022 21:52, Larry Rosenman wrote:

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that debugging
enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log 
records

(or false positive), that could happen so due to use of -F recovery
option on `zpool import`, that supposed to try import pool at 
earlier
transaction group if there is some metadata corruption found.  It 
is
not supposed to work 100% and only a last resort.  Though may be 
that
assertion is just excessively strict for that specific recovery 
case.
If as you say pool can be imported and scrubbed on 13, then I'd 
expect

following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to 
the console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I 
can export it cleanly on the 13 system?


Why do you need to import without mounting file systems?  I think you
may actually wish them to be mounted to replay their ZILs.  Just use
-R option to mount file systems in some different place.


I get the errors shown at:
https://www.lerctr.org/~ler/14-mount-R-output.png

Should I worry?  Or do something(tm) here?


This looks weird, but may possibly depend on mount points topology,
whether /mnt is writable, etc.  What happen if you export it now and
try to import it in normal way on 14 without -F?


It crashes just after root mount (this is the boot pool and only pool on 
the system),

seeL
https://www.lerctr.org/~ler/14-BOOT-Crash.png


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Motin]

On 23.02.2022 22:01, Larry Rosenman wrote:

On 02/23/2022 8:58 pm, Alexander Motin wrote:

On 23.02.2022 21:52, Larry Rosenman wrote:

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that debugging
enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log records
(or false positive), that could happen so due to use of -F recovery
option on `zpool import`, that supposed to try import pool at earlier
transaction group if there is some metadata corruption found.  It is
not supposed to work 100% and only a last resort.  Though may be that
assertion is just excessively strict for that specific recovery case.
If as you say pool can be imported and scrubbed on 13, then I'd expect
following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to 
the console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I 
can export it cleanly on the 13 system?


Why do you need to import without mounting file systems?  I think you
may actually wish them to be mounted to replay their ZILs.  Just use
-R option to mount file systems in some different place.


I get the errors shown at:
https://www.lerctr.org/~ler/14-mount-R-output.png

Should I worry?  Or do something(tm) here?


This looks weird, but may possibly depend on mount points topology, 
whether /mnt is writable, etc.  What happen if you export it now and try 
to import it in normal way on 14 without -F?


--
Alexander Motin

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/23/2022 8:58 pm, Alexander Motin wrote:

On 23.02.2022 21:52, Larry Rosenman wrote:

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that debugging
enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log records
(or false positive), that could happen so due to use of -F recovery
option on `zpool import`, that supposed to try import pool at earlier
transaction group if there is some metadata corruption found.  It is
not supposed to work 100% and only a last resort.  Though may be that
assertion is just excessively strict for that specific recovery case.
If as you say pool can be imported and scrubbed on 13, then I'd 
expect

following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to 
the console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I can 
export it cleanly on the 13 system?


Why do you need to import without mounting file systems?  I think you
may actually wish them to be mounted to replay their ZILs.  Just use
-R option to mount file systems in some different place.


I get the errors shown at:
https://www.lerctr.org/~ler/14-mount-R-output.png

Should I worry?  Or do something(tm) here?


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Motin]

On 23.02.2022 21:52, Larry Rosenman wrote:

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that debugging
enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log records
(or false positive), that could happen so due to use of -F recovery
option on `zpool import`, that supposed to try import pool at earlier
transaction group if there is some metadata corruption found.  It is
not supposed to work 100% and only a last resort.  Though may be that
assertion is just excessively strict for that specific recovery case.
If as you say pool can be imported and scrubbed on 13, then I'd expect
following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to 
the console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I can 
export it cleanly on the 13 system?


Why do you need to import without mounting file systems?  I think you 
may actually wish them to be mounted to replay their ZILs.  Just use -R 
option to mount file systems in some different place.


--
Alexander Motin

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/23/2022 8:41 pm, Alexander Motin wrote:

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built
with INVARIANTS option.  On 13 you may just not have that debugging
enabled to hit the issue.  But that may be only a consequence.
Original problem I guess in possibly corrupted ZFS intent log records
(or false positive), that could happen so due to use of -F recovery
option on `zpool import`, that supposed to try import pool at earlier
transaction group if there is some metadata corruption found.  It is
not supposed to work 100% and only a last resort.  Though may be that
assertion is just excessively strict for that specific recovery case.
If as you say pool can be imported and scrubbed on 13, then I'd expect
following clean export should allow later import on 14 without -F.

On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to the 
console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


How can I import the pool withOUT it mounting the FileSystems so I can 
export it cleanly on the 13 system?



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Alexander Motin]

Hi Larry,

The panic you are getting is an assertion, enabled by kernel built with 
INVARIANTS option.  On 13 you may just not have that debugging enabled 
to hit the issue.  But that may be only a consequence.  Original problem 
I guess in possibly corrupted ZFS intent log records (or false 
positive), that could happen so due to use of -F recovery option on 
`zpool import`, that supposed to try import pool at earlier transaction 
group if there is some metadata corruption found.  It is not supposed to 
work 100% and only a last resort.  Though may be that assertion is just 
excessively strict for that specific recovery case.  If as you say pool 
can be imported and scrubbed on 13, then I'd expect following clean 
export should allow later import on 14 without -F.


On 23.02.2022 21:21, Larry Rosenman wrote:


've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to the 
console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.




--
Alexander Motin

ZFS PANIC: HELP.

[Larry Rosenman]

've got my main dev box that crashes on 14 with the screen shot at 
https://www.lerctr.org/~ler/14-zfs-crash.png.

Booting from a 13-REL USB installer it imports and scrubs.

Ideas?

I can either video conference with shared screen or give access to the 
console via my Dominion KVM.


Any help/ideas/etc welcome I really need to get this box back.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: Help wanted: volunteer yourselves in .github/CODEOWNERS

[Mark Linimon]

On Mon, May 31, 2021 at 05:25:03AM +, Poul-Henning Kamp wrote:
> They are enthusiastic FreeBSD users and potential future committers,
> and should be treated as such!

The same goes for non-committers and phabricator, IMHO.

mcl

Re: Help wanted: volunteer yourselves in .github/CODEOWNERS

[Poul-Henning Kamp]

Alan Somers writes:


> Strangers are submitting pull requests to our Github mirror, [...]

The are not "strangers".

They are enthusiastic FreeBSD users and potential future committers,
and should be treated as such!


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Help wanted: volunteer yourselves in .github/CODEOWNERS

[Warner Losh]

On Sun, May 30, 2021 at 8:17 PM Kubilay Kocak  wrote:

> On 31/05/2021 9:13 am, Alan Somers wrote:
> > Strangers are submitting pull requests to our Github mirror, but we
> rarely
> > pay attention.  I just added a .github/CODEOWNERS file to our repo to
> > automatically assign reviewers to PRs.  I based it off of the contents of
> > the current MAINTAINERS file.  But it's incomplete.  Please add yourself
> if:
> >
> > * You don't have a github account associated with your FreeBSD email
> > address.  I'm talking to you, adrian@, macklem@, and rrs@ .
> > * You are part of a team, like secteam@ or re@ .  You'll have to create
> the
> > team at https://github.com/orgs/freebsd/teams then you can add it to the
> > list.
> > * You previously signed up for Phabricator notifications with Herald, but
> > didn't sign up in MAINTAINERS.  I can't see everybody's Phabricator
> > assignments.
> > * You never signed up in MAINTAINERS before, but you really ought to
> > because you care deeply about some particular subsystem.
> >
> > -Alan
> >
>
> Thanks for this Alan.
>
> Bugmeister is (and has been for a while) also keen to finally solve the
> problem of better getting the right eyes on patches submitted to
> Bugzilla for particular code areas, which complements other areas of
> improvements in issue management, such as more and clearer components in
> Bugzilla for people to use.
>
> Ports has an explicit MAINTAINER line we use to automatically
> auto-assign and CC issues, it would be great to use CODEOWNERS for this,
> along with appropriate consistently declared MAINTAINER lines in
> specific component directories and/or Makefiles.
>
> I think this is a good time to raise the difficult question/issue of
> policy/guidelines around code maintainership and responsibilities around
> that, including:
>
> - Having one or more maintainers of tree areas/components
> - Maintainer review, approval and timeouts
> - Issue triage/management
>

Before I start, I'd like to note what we do today isn't working. We have a
lot of
intake points and it's hard to find things for developers. We need to do
something
different to help tame the chaos.

The src tree and the ports tree are somewhat different in terms of all
these issues.
Some parts of the tree require proper oversight by a small group of experts
(regardless
of timeout), while other parts of the tree need less oversight. Some parts
of the tree
you can get a good notion of who should get reports of bugs based on who
has made
recent changes (though API sweeps can skew the results). Other parts of the
tree the
changes are far enough in the past to be a poor judge.

I suspect that a combination of what we've done in the past, coupled with
some shifts
with roles as the project modernizes and liberalizes. Whatever we put into
place
will need to grow with us.

Finally, we've had a poor history of maintaining long lists of maintainers,
so I suspect
we'll need to have some kind of automation involved to keep things fresh
enough to
be useful.

Warner

Re: Help wanted: volunteer yourselves in .github/CODEOWNERS

[Kubilay Kocak]

On 31/05/2021 9:13 am, Alan Somers wrote:

Strangers are submitting pull requests to our Github mirror, but we rarely
pay attention.  I just added a .github/CODEOWNERS file to our repo to
automatically assign reviewers to PRs.  I based it off of the contents of
the current MAINTAINERS file.  But it's incomplete.  Please add yourself if:

* You don't have a github account associated with your FreeBSD email
address.  I'm talking to you, adrian@, macklem@, and rrs@ .
* You are part of a team, like secteam@ or re@ .  You'll have to create the
team at https://github.com/orgs/freebsd/teams then you can add it to the
list.
* You previously signed up for Phabricator notifications with Herald, but
didn't sign up in MAINTAINERS.  I can't see everybody's Phabricator
assignments.
* You never signed up in MAINTAINERS before, but you really ought to
because you care deeply about some particular subsystem.

-Alan



Thanks for this Alan.

Bugmeister is (and has been for a while) also keen to finally solve the 
problem of better getting the right eyes on patches submitted to 
Bugzilla for particular code areas, which complements other areas of 
improvements in issue management, such as more and clearer components in 
Bugzilla for people to use.


Ports has an explicit MAINTAINER line we use to automatically 
auto-assign and CC issues, it would be great to use CODEOWNERS for this, 
along with appropriate consistently declared MAINTAINER lines in 
specific component directories and/or Makefiles.


I think this is a good time to raise the difficult question/issue of 
policy/guidelines around code maintainership and responsibilities around 
that, including:


- Having one or more maintainers of tree areas/components
- Maintainer review, approval and timeouts
- Issue triage/management

Help wanted: volunteer yourselves in .github/CODEOWNERS

[Alan Somers]

Strangers are submitting pull requests to our Github mirror, but we rarely
pay attention.  I just added a .github/CODEOWNERS file to our repo to
automatically assign reviewers to PRs.  I based it off of the contents of
the current MAINTAINERS file.  But it's incomplete.  Please add yourself if:

* You don't have a github account associated with your FreeBSD email
address.  I'm talking to you, adrian@, macklem@, and rrs@ .
* You are part of a team, like secteam@ or re@ .  You'll have to create the
team at https://github.com/orgs/freebsd/teams then you can add it to the
list.
* You previously signed up for Phabricator notifications with Herald, but
didn't sign up in MAINTAINERS.  I can't see everybody's Phabricator
assignments.
* You never signed up in MAINTAINERS before, but you really ought to
because you care deeply about some particular subsystem.

-Alan

boot loader menu help missing "menu" option

[Dan Mack]

While debugging the issue with the console having display problems with 
some graphics cards, I noticed that in the help output from the boot 
loader (at the OK prompt):


 OK ?
 Available commands:
   rebootreboot the system
   heap  show heap usage
   chain chain load boot block from device
   ...
   vbe   vesa framebuffer mode management
OK

The way you get back to the bestie menu is by typing "menu" but that 
option is not in the help "?" output.


Just FYI - probably something simple no?

This is on tip of main / CURRENT.

Dan
___
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: Need some help with audio/sound (to get S/PDIF Toslink to work).

[blackfoxx]

Thank you.
I already read this thread while researching.
Doesn't help me, because not a single "Digital" output/device appears in 
my FreeBSD 13.0-CURRENT System:

pcm0:  on emu10kx0
pcm0: 
pcm1:  on emu10kx0
pcm2:  on emu10kx0
pcm3:  on emu10kx0
These 4 or 5 are just analog outputs/devices.
Maybe the digital (S/PDIF, Toslink) issn't recognized by the system?!
But I don't know how to "make" it recognized by FreeBSD.
With Devuan (ALSA) and Win10 (Creative Driver) everything is working 
fine there.
I also tried OSS, ALSA and PulseAudio with FreeBSD, but no chance to 
make it work.


Am 29.12.2020 um 11:55 schrieb fischerking1...@yahoo.co.jp:

https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/

___
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: Need some help with audio/sound (to get S/PDIF Toslink to work).

[fischerking1905]

https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/

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

Need some help with audio/sound (to get S/PDIF Toslink to work).

[blackfoxx]

Hi there.

I'm using FreeBSD (13.0-CURRENT) since 09/2020 at my Raspberry Pi 4B as 
Home-and-Web-Server-OS with Apache, PHP, SQLite etc... And it works like 
a charm!


Furthermore I'm trying to switch with my main workstation from Win10 to 
FreeBSD too. Because the more I'm working with FreeBSD, the more I 
realize that it's the only sane OS out there.
Now, I really would like to remove my Win10 Installation, but 
unfortunately I still have an issue with FreeBSD 13.0-CURRENT for which 
I can't find solutions, even after reading the whole handbook and 
searching the www for weeks:


I've got an "SoundBlaster Audigy Rx" Soundcard with "Creative E-MU 
CA10300" Chipset, using the BSDs "EMU10Kx" Kernel Module.
The mixer shows all in/outputs right and volume-control of all analog 
I/Os is working fine with my "Behringer MS40" Speakers and "Alienware 
TactX" Headset.
BUT the digital output (S/PDIF, Toslink) does NOT work. Even if I set 
dig1/dig2/dig3 and all other outputs to "100:100" within the mixer - 
still no sound via Toslink.
With Devuan (ALSA) or Win10 (native Creative Driver) it is working 
properly. So it can't be a hardware issue.
I also tried OSS, ALSA and PulseAudio with FreeBSD, searched the web for 
hours, tried this and that, but still no sound via Toslink...
(Fortunately) this is the only Hardware-Issue I have. But it is 
important to me to get S/PDIF Toslink to work!


I hope that someone around here can give me some hints, advice, solutions...

Regards, blackfoxx


My Hardware-Setup:
http://www.sysprofile.de/id182580


dmesg.boot:
[1] ---<>---
[1] Copyright (c) 1992-2020 The FreeBSD Project.
[1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
[1] The Regents of the University of California. All rights reserved.
[1] FreeBSD is a registered trademark of The FreeBSD Foundation.
[1] FreeBSD 13.0-CURRENT #0 : Sat Dec 26 23:08:09 UTC 2020
[1] FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.0-rc2-0-g414f32a9e86)

[1] WARNING: WITNESS option enabled, expect reduced performance.
[1] VT(efifb): resolution 1280x800
[1] FreeBSD: initialize and check features (__FreeBSD_version 1300133).
[1] CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3200.19-MHz K8-class CPU)
[1] Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7
[1]Features=0xbfebfbff
[1]Features2=0x1fbee3bf
[1] AMD Features=0x2c100800
[1] AMD Features2=0x1
[1] XSAVE Features=0x1
[1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
[1] TSC: P-state invariant, performance statistics
[1] real memory = 17179869184 (16384 MB)
[1] avail memory = 16491573248 (15727 MB)
[1] Event timer "LAPIC" quality 600
[1] ACPI APIC Table: 
[1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
[1] FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
[1] FreeBSD/SMP Online: 1 package(s) x 4 core(s)
[1] random: unblocking device.
[1] Firmware Warning (ACPI): 32/64X length mismatch in 
FADT/Pm1aEventBlock: 32/16 (20201113/tbfadt-748)
[1] Firmware Warning (ACPI): 32/64X length mismatch in 
FADT/PmTimerBlock: 32/24 (20201113/tbfadt-748)
[1] Firmware Warning (ACPI): Invalid length for FADT/Pm1aEventBlock: 16, 
using default 32 (20201113/tbfadt-850)
[1] Firmware Warning (ACPI): Invalid length for FADT/PmTimerBlock: 24, 
using default 32 (20201113/tbfadt-850)

[1] ioapic1  irqs 24-47
[1] ioapic0  irqs 0-23
[1] Launching APs: 2 1 3
[1] random: entropy device external interface
[1] WARNING: Device "kbd" is Giant locked and may be deleted before 
FreeBSD 13.0.

[1] kbd1 at kbdmux0
[1] 000.39 [4346] netmap_init netmap: loaded module
[1] [ath_hal] loaded
[1] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX 
platforms 440.100 Fri May 29 08:11:49 UTC 2020

[1] nexus0
[1] efirtc0: 
[1] efirtc0: registered as a time-of-day clock, resolution 1.00s
[1] cryptosoft0: 
[1] aesni0: 
[1] acpi0: 
[1] acpi0: Power Button (fixed)
[1] cpu0:  on acpi0
[1] atrtc0:  port 0x70-0x71,0x74-0x77 irq 8 on acpi0
[1] atrtc0: registered as a time-of-day clock, resolution 1.00s
[1] Event timer "RTC" frequency 32768 Hz quality 0
[1] attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
[1] Timecounter "i8254" frequency 1193182 Hz quality 0
[1] Event timer "i8254" frequency 1193182 Hz quality 100
[1] hpet0:  iomem 0xfed0-0xfed03fff on acpi0
[1] Timecounter "HPET" frequency 14318180 Hz quality 950
[1] Event timer "HPET" frequency 14318180 Hz quality 550
[1] Event timer "HPET1" frequency 14318180 Hz quality 440
[1] Event timer "HPET2" frequency 14318180 Hz quality 440
[1] Event timer "HPET3" frequency 14318180 Hz quality 440
[1] Event timer "HPET4" frequency 14318180 Hz quality 440
[1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
[1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
[1] acpi_button0:  on acpi0
[1] pcib0:  port 0xcf8-0xcff on acpi0
[1] pci0:  on pcib0
[1] pcib1:  at device 1.0 on pci0
[1] pci1:  on pcib1
[1] pcib2:  at device 1.1 on pci0
[1] pci2:  on pcib2
[1] xhci0:  

Re: on moving freebsd from svn to git; would this be of any help?

[Ulrich Spörlein]

On Fri, Sep 18, 2020 at 10:04 PM Ed Maste  wrote:
>
> On Fri, 18 Sep 2020 at 15:07, Chris  wrote:
> >
> > While contemplating a massive re-tooling job ahead to accommodate
> > any/all changes when freebsd fully lands in git. I ran across this[1][2]
> > and wondered if it may be of any assistance for the task of those
> > involved in the migration process @freebsd.
>
> It doesn't solve any of the problems we have now; the actual svn to
> git conversion via svn2git works fine. Open issues are with the svn
> repository / mirrors, and finishing up process documentation.
> > 1) http://catb.org/esr/reposurgeon/
> > 2) https://gitlab.com/esr/reposurgeon
> >
> > FTR I'm unaffiliated with the project. It just looked like it might be of
> > interest.

Thanks for bringing this up. I did look at reposurgeon quite a while ago
but considered it too much work to get the rules right, especially for the
CVS days of the project.

Cheers
Uli
___
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: on moving freebsd from svn to git; would this be of any help?

[Ed Maste]

On Fri, 18 Sep 2020 at 15:07, Chris  wrote:
>
> While contemplating a massive re-tooling job ahead to accommodate
> any/all changes when freebsd fully lands in git. I ran across this[1][2]
> and wondered if it may be of any assistance for the task of those
> involved in the migration process @freebsd.

It doesn't solve any of the problems we have now; the actual svn to
git conversion via svn2git works fine. Open issues are with the svn
repository / mirrors, and finishing up process documentation.
> 1) http://catb.org/esr/reposurgeon/
> 2) https://gitlab.com/esr/reposurgeon
>
> FTR I'm unaffiliated with the project. It just looked like it might be of
> interest.
>
> --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"
___
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"

on moving freebsd from svn to git; would this be of any help?

[Chris]

While contemplating a massive re-tooling job ahead to accommodate
any/all changes when freebsd fully lands in git. I ran across this[1][2]
and wondered if it may be of any assistance for the task of those
involved in the migration process @freebsd.

1) http://catb.org/esr/reposurgeon/
2) https://gitlab.com/esr/reposurgeon

FTR I'm unaffiliated with the project. It just looked like it might be of
interest.

--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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

On Tue, 27 Aug 2019 08:43:53 +0300
Toomas Soome  wrote:

> > On 27 Aug 2019, at 08:08, Warner Losh  wrote:
> >
> > On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran  > > wrote:
> >> On 8/26/19 5:22 AM, O. Hartmann wrote:
> >>
> >>>
> >>> the other thing is the weird Lenovo handling of the UEFI vars. The only
> >> way to
> >>> boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
> >>> everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi.
> >> Setting the
> >>> variable to contain EFI/BOOT/loader.efi failed as well as setting
> >>> EFI/FreeBSD/loader.efi.
> >>
> >>
> >> I've been suggesting FreeBSD should install the loader as
> >> \EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a
> >> different vendor's loader there), without much success. Hopefully this
> >> finding can cause us to reconsider.
> >>
> >
> > That's the first machine I've seen where you have to set the name like
> > that... there is a larger story here and we are getting incomplete reports
> > because it doesn't quite make sense yet...
> >
> > But there are enough reasons not to do that by default. For one thing, it
> > messes up rEFInd, or can. Windows doesn't install there. At most we should
> > prompt for older machines.  We shouldn't mortgage our future to cope with a
> > legacy we know will sunset soon...
> >
> > Warner
> >
>
> For me it is still confusing if this is path versus upper-lower capital
> chars.
>
> If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page
> 91), then the file name should also end with .EFI. (and yes, I know, that
> section is talking about removable media).
>
> Therefore the question is, does lenovo accept name like
> EFI/FREEBSD/LOADER.EFI? Or what form is used there for windows paths?

My initial report was a bit confusing due to the fact I used to have a loader
compiled on 12-STABLE with WITH_BEARSSL enabled. I also mixed up loader.efi
from CURRENT (from the recent USB boot drive image). Since the ESP is FAT12 (in
my case), I thought upper- or lowercase isn't relevant here - but it seems to
be. So I used lower case paths and filenames and in one case a mixture.

Since I now know what the problem caused initially, I can check whether the
path and/or filename's upper- or lowercase matters.

I have a strange feeling about this since the Lenovo E540 has a really annoying
firmware compared to those UEFI firmware we used to have with the upper class
models around here (for instance, annoying loud beeping although no-beep is
configured and so on ...).

>
> If we should or should not use EFI/BOOT path - perhaps the installer should
> prefer vendor path by default. But till there is confusion, there should be
> some notes in some documentation...
>
> rgds,
> toomas
> ___
> 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 22:34:21 +0300
Toomas Soome  schrieb:

> > On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Am Wed, 21 Aug 2019 22:14:46 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? 
> >> you should have
> >> fs0: or like for ESP.
> >> 
> >> rgds,
> >> toomas  
> > 
> > Hello,
> > 
> > I can't even stop to gain access to the shell; there is no timeframe to hit 
> > any key to
> > stop by and access the efi shell. 
> > 
> > Kind regards,
> > oh  
> 
> 
> hm? efi shell should be available from boot device menu, so you mean, you can 
> not even get
> into firmware setup?
> 
> rgds,
> toomas

Sorry,
I confused loader prompt and EFI shell.

I do not have a EFI shell on that type of laptop, not to know about it. I can 
access the
firmware setup and already performed a reset and switched back to default 
settings. No effect.

I just downloaded the newest CURRENT mem stick and extracted both boot1.efi and 
loader.efi and
installed those into the ESP as described, setting the efibootmgr env 
accordingly. Still the
same error.

It seems that there is indeed no EFI/UEFI shell. There are Lenovo specific EFI 
boot options,
like "diagnostics" and so on, if selected, the UEFI boots into a firmware 
embedded diagnostic
menu. I tried several from the list given via efibootmgr show -v, but there is 
no shell from
which I could access/boot an alternative loader.

How I'm supposed to achive the access to this EFI shell? I doubt that on the 
E540 (beware of
the E, it is not a L or T model) does have such a shell.

Regards,
oh 
> 
> >   
> >>   
> >>> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>> 
> >>> I ran into serious trouble booting several boxes off UEFI. On modern 
> >>> hardware,
> >>> the ESP is around 200 - 300 MB in size and usually I install
> >>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
> >>> older
> >>> hardware, specifically on a Lenovo E540 with latest available firmware 
> >>> (2.28),
> >>> which uses 12-STABLE and a ZFS-only installation, there seems no working 
> >>> loader
> >>> anymore!
> >>> The installation of the Laptop has been performed using 12.0-PRERELEASE 
> >>> on an
> >>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> >>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> >>> 
> >>> The ESP has been destroyed by accident. Now I tried to solve the problem 
> >>> by
> >>> installing a new ESP and the proper loader, assuming that /boot/loader.efi
> >>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision 
> >>> and
> >>> sompiled on the same platform (Intel Haswell) as the lost laptop's 
> >>> revison of
> >>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting 
> >>> up a
> >>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> >>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> >>> 
> >>> Installing the proper boot/loader.efi loader file from 12-STABLE 
> >>> (r351108) and
> >>> setting the EFI variable according the following steps:
> >>> 
> >>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is 
> >>> zroot)
> >>> Install then loader.efi either as BOOTx64.efi or loader.efi under
> >>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> >>> accordingly via
> >>> 
> >>> delete 000A first:
> >>> efibootmgr -B -b 000A
> >>> 
> >>> create the new efi boot var:
> >>> efibootmgr -a -b 000A -c -l 
> >>> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
> >>> FreeBSD
> >>> 
> >>> The result is a non booting system, the Lenovo firmware jumps immediately 
> >>> into
> >>> the menu for selecting a proper boot media.
> >>> 
> >>> The same happens with /boot/boot1.efi installed as loader.efi or 
> >>> BOOTx64.efi
> >>> shown above.
> >>> 
> >>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> >>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
> >>> system I
> >>> spoeke of above), then booting fails again, but this time with an error I 
> >>> watch
> >>> on so many boxes recently:
> >>> 
> >>> [...]
> >>> Ignoring Boot000a: Only one DP found
> >>> Trying ZFS pool
> >>> Setting currdev to zfs:zroot/ROOT/default:
> >>> 
> >>> Then the console freezes at that point and only RESET or POWER OFF is 
> >>> capable
> >>> of a revive.
> >>> 
> >>> What is wrong here? What am I missing?
> >>> 
> >>> Thanks in advance,
> >>> 
> >>> 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).
> >>> -BEGIN PGP SIGNATURE-
> >>> 
> >>> 

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 22:29:29 +
greg@unrelenting.technology schrieb:

> August 22, 2019 12:23 AM, "O. Hartmann"  wrote:
> 
> > Am Wed, 21 Aug 2019 15:58:24 -0500
> > Karl Denninger  schrieb:
> >   
> >> I would see if you can get REFIND loaded and use that.  I have a Lenovo
> >> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
> >> (e.g. Win10 and FreeBSD) easily.  
> > 
> > mmmhhh, Linux software to make FreeBSD boot? ;-)  
> 
> rEFInd is not "Linux software", I use it to get a nice menu to choose between 
> FreeBSD and
> Windows on my desktop. No Linux in sight. If anything, rEFInd has its roots 
> in Macs :)

My apologizes; when searching the net, the first "logo" I see is this silly 
penguine face. I'm
sorry about making such simple implications.

> 
> > This Lenovo firmware seems very reluctant or the efibootmgr doesn't operate 
> > properly on
> > setting variables: when trying to label the boot number (e.g. Boot000A) 
> > with "-L FreeBSD",
> > it is always set back to "Boot000A ATA HDD0". On other platforms, like 
> > Fujitsu servers or
> > even the cheap crap from ASRock a label once set is permenent until 
> > deleted.  
> 
> Many laptops just ignore the boot variables outright. My X240 is the same.
> I never switched to a proper efibootmgr setup on mine, I just have loader.efi 
> as bootx64.efi
> and that's it.

I tried copying loader.efi as bootx64.efi - but didn't help.
 
> >> If there's a way to get into the EFI shell on Lenovo's laptops from the
> >> BIOS during the boot I've not found it yet.  There's supposed to be on
> >> all EFI devices, but you know how "supposed to" works in many cases, 
> >> right?  
> 
> You can just download the EFI Shell from the internet, it's a normal .efi 
> executable you can
> "boot". Put it as efi/boot/bootx64.efi onto a USB flash drive and enjoy.

I'll give this a chance as soon I have hands on the workitem again.

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).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV4GZQAKCRA4N1ZZPba5
R56KAQDCWHc/QwWG7hT+uOG78KyB6z2KjPpzpvDWI5ZuUcm0RQEAzIjkfTwDm+V6
IUa2Tyiq8Y3Ce8Q8ohuFaCX838CcQQA=
=Hoa2
-END PGP SIGNATURE-
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Rebecca Cran]

> On Aug 26, 2019, at 11:43 PM, Toomas Soome  wrote:
> 
> For me it is still confusing if this is path versus upper-lower capital 
> chars. 
> 
> If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page 
> 91), then the file name should also end with .EFI. (and yes, I know, that 
> section is talking about removable media).
> 
> Therefore the question is, does lenovo accept name like 
> EFI/FREEBSD/LOADER.EFI? Or what form is used there for windows paths?
> 
> If we should or should not use EFI/BOOT path - perhaps the installer should 
> prefer vendor path by default. But till there is confusion, there should be 
> some notes in some documentation...

Being a FAT filesystem I don’t think upper/lower case matters.
Personally I think we should always install to the vendor path, and also 
install to EFI/BOOT if somebody else hasn’t already got files there.

— 
Rebecca 
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 27 Aug 2019, at 08:08, Warner Losh  wrote:
> 
> On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran  > wrote:
> 
>> On 8/26/19 5:22 AM, O. Hartmann wrote:
>> 
>>> 
>>> the other thing is the weird Lenovo handling of the UEFI vars. The only
>> way to
>>> boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
>>> everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi.
>> Setting the
>>> variable to contain EFI/BOOT/loader.efi failed as well as setting
>>> EFI/FreeBSD/loader.efi.
>> 
>> 
>> I've been suggesting FreeBSD should install the loader as
>> \EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a
>> different vendor's loader there), without much success. Hopefully this
>> finding can cause us to reconsider.
>> 
> 
> That's the first machine I've seen where you have to set the name like
> that... there is a larger story here and we are getting incomplete reports
> because it doesn't quite make sense yet...
> 
> But there are enough reasons not to do that by default. For one thing, it
> messes up rEFInd, or can. Windows doesn't install there. At most we should
> prompt for older machines.  We shouldn't mortgage our future to cope with a
> legacy we know will sunset soon...
> 
> Warner
> 

For me it is still confusing if this is path versus upper-lower capital chars. 

If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page 
91), then the file name should also end with .EFI. (and yes, I know, that 
section is talking about removable media).

Therefore the question is, does lenovo accept name like EFI/FREEBSD/LOADER.EFI? 
Or what form is used there for windows paths?

If we should or should not use EFI/BOOT path - perhaps the installer should 
prefer vendor path by default. But till there is confusion, there should be 
some notes in some documentation...

rgds,
toomas
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Rebecca Cran]

On 2019-08-26 23:08, Warner Losh wrote:
>
> That's the first machine I've seen where you have to set the name like
> that... there is a larger story here and we are getting incomplete reports
> because it doesn't quite make sense yet...
>
> But there are enough reasons not to do that by default. For one thing, it
> messes up rEFInd, or can. Windows doesn't install there. At most we should
> prompt for older machines.  We shouldn't mortgage our future to cope with a
> legacy we know will sunset soon...


Both Windows and Linux install \EFI\BOOT\BOOTx64.efi because that's the
default that gets run if there aren't any Boot variables.

And yes, Windows 10 does install there. On my system I have
/EFI/Boot/bootx64.efi and \EFI\Microsoft\{Boot,Recovery}, where
/EFI/Boot/bootx64.efi is the same binary as bootmgfw.efi.

I'm not convinced this is something that's about older systems, and that
will go away.


-- 
Rebecca Cran

___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Warner Losh]

On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran  wrote:

> On 8/26/19 5:22 AM, O. Hartmann wrote:
>
> >
> > the other thing is the weird Lenovo handling of the UEFI vars. The only
> way to
> > boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
> > everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi.
> Setting the
> > variable to contain EFI/BOOT/loader.efi failed as well as setting
> > EFI/FreeBSD/loader.efi.
>
>
> I've been suggesting FreeBSD should install the loader as
> \EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a
> different vendor's loader there), without much success. Hopefully this
> finding can cause us to reconsider.
>

That's the first machine I've seen where you have to set the name like
that... there is a larger story here and we are getting incomplete reports
because it doesn't quite make sense yet...

But there are enough reasons not to do that by default. For one thing, it
messes up rEFInd, or can. Windows doesn't install there. At most we should
prompt for older machines.  We shouldn't mortgage our future to cope with a
legacy we know will sunset 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Rebecca Cran]

On 8/26/19 5:22 AM, O. Hartmann wrote:



the other thing is the weird Lenovo handling of the UEFI vars. The only way to
boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi. Setting the
variable to contain EFI/BOOT/loader.efi failed as well as setting
EFI/FreeBSD/loader.efi.



I've been suggesting FreeBSD should install the loader as 
\EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a 
different vendor's loader there), without much success. Hopefully this 
finding can cause us to reconsider.



--
Rebecca Cran

___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

On Thu, 22 Aug 2019 08:58:55 +0300
Toomas Soome  wrote:

> > On 22 Aug 2019, at 06:04, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Am Wed, 21 Aug 2019 22:29:29 +
> > greg@unrelenting.technology schrieb:
> >   
> >> August 22, 2019 12:23 AM, "O. Hartmann"  wrote:
> >>   
> >>> Am Wed, 21 Aug 2019 15:58:24 -0500
> >>> Karl Denninger  schrieb:
> >>>   
> >>>> I would see if you can get REFIND loaded and use that.  I have a Lenovo
> >>>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
> >>>> (e.g. Win10 and FreeBSD) easily.
> >>> 
> >>> mmmhhh, Linux software to make FreeBSD boot? ;-)
> >> 
> >> rEFInd is not "Linux software", I use it to get a nice menu to choose
> >> between FreeBSD and Windows on my desktop. No Linux in sight. If anything,
> >> rEFInd has its roots in Macs :)  
> > 
> > My apologizes; when searching the net, the first "logo" I see is this silly
> > penguine face. I'm sorry about making such simple implications.
> >   
> >>   
> >>> This Lenovo firmware seems very reluctant or the efibootmgr doesn't
> >>> operate properly on setting variables: when trying to label the boot
> >>> number (e.g. Boot000A) with "-L FreeBSD", it is always set back to
> >>> "Boot000A ATA HDD0". On other platforms, like Fujitsu servers or even the
> >>> cheap crap from ASRock a label once set is permenent until deleted.
> >> 
> >> Many laptops just ignore the boot variables outright. My X240 is the same.
> >> I never switched to a proper efibootmgr setup on mine, I just have
> >> loader.efi as bootx64.efi and that's it.  
> > 
> > I tried copying loader.efi as bootx64.efi - but didn't help.
> >   
> >>>> If there's a way to get into the EFI shell on Lenovo's laptops from the
> >>>> BIOS during the boot I've not found it yet.  There's supposed to be on
> >>>> all EFI devices, but you know how "supposed to" works in many cases,
> >>>> right?
> >> 
> >> You can just download the EFI Shell from the internet, it's a normal .efi
> >> executable you can "boot". Put it as efi/boot/bootx64.efi onto a USB flash
> >> drive and enjoy.  
> > 
> > I'll give this a chance as soon I have hands on the workitem again.
> >   
> 
> The reason to try rEFInd and/or EFI shell is to see if we get extra error
> messages otherwise hidden by GUI.
> 
> In any case, to get to the root cause, we would need to start to insert more
> debug printouts and see what we will find. Once you are ready to go with it,
> you can poke me directly and then we can start…
> 
> rgds,
> toomas
> 

Hello.

I spent the weekend fiddling around with the settings and I found out two
things:

the most important: my brain is leaking "emory", means: I had the same issue
with an APU from PCengines because of enabling "WITH_BEARSSL" in /etc/src.conf
on the machines where we built the main OS. I did so on the laptop we spoke of
in this thread - and forgot about that fact.

the other thing is the weird Lenovo handling of the UEFI vars. The only way to
boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi. Setting the
variable to contain EFI/BOOT/loader.efi failed as well as setting
EFI/FreeBSD/loader.efi. 

I also had to delete the Boot000A variable - it seems Lenovo's UEFI
implementation uses fixed variable sets (as I realized when not being able to
name label of the variable Boot000A by something I've choosen). Boot000A is
always labeled "ATA HDD0", no matter what I've tried to set it to via option
"-L" of efibootmgr.

Kind regards,
oh 
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 22 Aug 2019, at 06:04, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Wed, 21 Aug 2019 22:29:29 +
> greg@unrelenting.technology schrieb:
> 
>> August 22, 2019 12:23 AM, "O. Hartmann"  wrote:
>> 
>>> Am Wed, 21 Aug 2019 15:58:24 -0500
>>> Karl Denninger  schrieb:
>>> 
>>>> I would see if you can get REFIND loaded and use that.  I have a Lenovo
>>>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
>>>> (e.g. Win10 and FreeBSD) easily.  
>>> 
>>> mmmhhh, Linux software to make FreeBSD boot? ;-)  
>> 
>> rEFInd is not "Linux software", I use it to get a nice menu to choose 
>> between FreeBSD and
>> Windows on my desktop. No Linux in sight. If anything, rEFInd has its roots 
>> in Macs :)
> 
> My apologizes; when searching the net, the first "logo" I see is this silly 
> penguine face. I'm
> sorry about making such simple implications.
> 
>> 
>>> This Lenovo firmware seems very reluctant or the efibootmgr doesn't operate 
>>> properly on
>>> setting variables: when trying to label the boot number (e.g. Boot000A) 
>>> with "-L FreeBSD",
>>> it is always set back to "Boot000A ATA HDD0". On other platforms, like 
>>> Fujitsu servers or
>>> even the cheap crap from ASRock a label once set is permenent until 
>>> deleted.  
>> 
>> Many laptops just ignore the boot variables outright. My X240 is the same.
>> I never switched to a proper efibootmgr setup on mine, I just have 
>> loader.efi as bootx64.efi
>> and that's it.
> 
> I tried copying loader.efi as bootx64.efi - but didn't help.
> 
>>>> If there's a way to get into the EFI shell on Lenovo's laptops from the
>>>> BIOS during the boot I've not found it yet.  There's supposed to be on
>>>> all EFI devices, but you know how "supposed to" works in many cases, 
>>>> right?  
>> 
>> You can just download the EFI Shell from the internet, it's a normal .efi 
>> executable you can
>> "boot". Put it as efi/boot/bootx64.efi onto a USB flash drive and enjoy.
> 
> I'll give this a chance as soon I have hands on the workitem again.
> 

The reason to try rEFInd and/or EFI shell is to see if we get extra error 
messages otherwise hidden by GUI.

In any case, to get to the root cause, we would need to start to insert more 
debug printouts and see what we will find. Once you are ready to go with it, 
you can poke me directly and then we can start…

rgds,
toomas

___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[greg]

August 22, 2019 12:23 AM, "O. Hartmann"  wrote:

> Am Wed, 21 Aug 2019 15:58:24 -0500
> Karl Denninger  schrieb:
> 
>> I would see if you can get REFIND loaded and use that.  I have a Lenovo
>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
>> (e.g. Win10 and FreeBSD) easily.
> 
> mmmhhh, Linux software to make FreeBSD boot? ;-)

rEFInd is not "Linux software", I use it to get a nice menu to choose between 
FreeBSD and Windows on my desktop. No Linux in sight. If anything, rEFInd has 
its roots in Macs :)

> This Lenovo firmware seems very reluctant or the efibootmgr doesn't operate 
> properly on
> setting variables: when trying to label the boot number (e.g. Boot000A) with 
> "-L FreeBSD", it
> is always set back to "Boot000A ATA HDD0". On other platforms, like Fujitsu 
> servers or even
> the cheap crap from ASRock a label once set is permenent until deleted.

Many laptops just ignore the boot variables outright. My X240 is the same.
I never switched to a proper efibootmgr setup on mine, I just have loader.efi 
as bootx64.efi and that's it.
 
>> If there's a way to get into the EFI shell on Lenovo's laptops from the
>> BIOS during the boot I've not found it yet.  There's supposed to be on
>> all EFI devices, but you know how "supposed to" works in many cases, right?

You can just download the EFI Shell from the internet, it's a normal .efi 
executable you can "boot". Put it as efi/boot/bootx64.efi onto a USB flash 
drive and enjoy.
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 15:58:24 -0500
Karl Denninger  schrieb:

> BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Am Wed, 21 Aug 2019 22:34:21 +0300
> > Toomas Soome  schrieb:
> >  
> > >> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >> Hash: SHA256
> > >>
> > >> Am Wed, 21 Aug 2019 22:14:46 +0300
> > >> Toomas Soome mailto:tso...@me.com>> schrieb:
> > >>     
> > >>> If you drop into efi shell, can you start efi/boot/bootx64.efi  
> > manually? you should have  
> > >>> fs0: or like for ESP.
> > >>>
> > >>> rgds,
> > >>> toomas    
> > >>
> > >> Hello,
> > >>
> > >> I can't even stop to gain access to the shell; there is no  
> > timeframe to hit any key to  
> > >> stop by and access the efi shell.
> > >>
> > >> Kind regards,
> > >> oh    
> >
> >  
> > > hm? efi shell should be available from boot device menu, so you  
> > mean, you can not even get  
> > > into firmware setup?  
> >  
> > > rgds,
> > > toomas  
> >
> > Sorry,
> > I confused loader prompt and EFI shell.
> >
> > I do not have a EFI shell on that type of laptop, not to know about
> > it. I can access the
> > firmware setup and already performed a reset and switched back to
> > default settings. No effect.
> >
> > I just downloaded the newest CURRENT mem stick and extracted both
> > boot1.efi and loader.efi and
> > installed those into the ESP as described, setting the efibootmgr env
> > accordingly. Still the
> > same error.
> >
> > It seems that there is indeed no EFI/UEFI shell. There are Lenovo
> > specific EFI boot options,
> > like "diagnostics" and so on, if selected, the UEFI boots into a
> > firmware embedded diagnostic
> > menu. I tried several from the list given via efibootmgr show -v, but
> > there is no shell from
> > which I could access/boot an alternative loader.
> >
> > How I'm supposed to achive the access to this EFI shell? I doubt that
> > on the E540 (beware of
> > the E, it is not a L or T model) does have such a shell.
> >
> > Regards,
> > oh  
> 
> I would see if you can get REFIND loaded and use that.  I have a Lenovo
> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
> (e.g. Win10 and FreeBSD) easily.

mmmhhh, Linux software to make FreeBSD boot? ;-)

> 
> I've not had trouble with 12.x on it, and I do use the
> geli-encrypted-aware loader.efi.

Until today I also did not have any trouble. In Novmeber 2018 I installed 
12-CURRENT (or
12-RC) with a ZFS filesystem on a new SSD and everything worked fine - until 
today, when I was
so insane to copy the most recent 12-STABLE loader.efi into the ESP and 
adjusted the efiboot
vartiable accordingly.  

This Lenovo firmware seems very reluctant or the efibootmgr doesn't operate 
properly on
setting variables: when trying to label the boot number (e.g. Boot000A) with 
"-L FreeBSD", it
is always set back to "Boot000A ATA HDD0". On other platforms, like Fujitsu 
servers or even
the cheap crap from ASRock a label once set is permenent until deleted.

> 
> If there's a way to get into the EFI shell on Lenovo's laptops from the
> BIOS during the boot I've not found it yet.  There's supposed to be on
> all EFI devices, but you know how "supposed to" works in many cases, right?
> 


I havn't tested all options available by setting the current boot number to 
those entries
predefined by Lenovo, but setting Boot0003 (I recall ...) gives a really funny 
diagnostics
menu with lots of options. Maybe there is more to discover ...

Thanks anyway, but I have to postpone the efforts until tomorrow evening ...
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).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV22VgAKCRA4N1ZZPba5
R2C/AP0WR1oKX/EpeRzDovQoeEbaSyVwg8PhTIaEciMwzEnLvwD9HJ83Czygd9Rd
kGM/24FRcYKDdJMD9ec46PQE38/UMgg=
=93bM
-END PGP SIGNATURE-
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 22 Aug 2019, at 00:07, Clay Daniels Jr.  wrote:
> 
> I would agree with Karl & Steffen about using rEFInd. It really gives you a
> lot more control of your computers boot. Take a look at Rod Smith's pages:
> http://www.rodsbooks.com/refind/
> 
> I use it to triple boot Windows 10, MX Linux, and FreeBSD.
> 
> Clay


rEFInd is fancy menu to start real boot loader, it really does not help if your 
boot loader is broken. In worst case, you can get fragmented memory from having 
rEFInd and native boot loader (depending on how stupid/buggy the firmware is).

rgds,
toomas

> 
> On Wed, Aug 21, 2019 at 3:59 PM Karl Denninger  wrote:
> 
>> BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Am Wed, 21 Aug 2019 22:34:21 +0300
>>> Toomas Soome  schrieb:
>>> 
>>>>> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
>>>>> 
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA256
>>>>> 
>>>>> Am Wed, 21 Aug 2019 22:14:46 +0300
>>>>> Toomas Soome mailto:tso...@me.com>> schrieb:
>>>>> 
>>>>>> If you drop into efi shell, can you start efi/boot/bootx64.efi
>>> manually? you should have
>>>>>> fs0: or like for ESP.
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I can't even stop to gain access to the shell; there is no
>>> timeframe to hit any key to
>>>>> stop by and access the efi shell.
>>>>> 
>>>>> Kind regards,
>>>>> oh
>>> 
>>> 
>>>> hm? efi shell should be available from boot device menu, so you
>>> mean, you can not even get
>>>> into firmware setup?
>>> 
>>>> rgds,
>>>> toomas
>>> 
>>> Sorry,
>>> I confused loader prompt and EFI shell.
>>> 
>>> I do not have a EFI shell on that type of laptop, not to know about
>>> it. I can access the
>>> firmware setup and already performed a reset and switched back to
>>> default settings. No effect.
>>> 
>>> I just downloaded the newest CURRENT mem stick and extracted both
>>> boot1.efi and loader.efi and
>>> installed those into the ESP as described, setting the efibootmgr env
>>> accordingly. Still the
>>> same error.
>>> 
>>> It seems that there is indeed no EFI/UEFI shell. There are Lenovo
>>> specific EFI boot options,
>>> like "diagnostics" and so on, if selected, the UEFI boots into a
>>> firmware embedded diagnostic
>>> menu. I tried several from the list given via efibootmgr show -v, but
>>> there is no shell from
>>> which I could access/boot an alternative loader.
>>> 
>>> How I'm supposed to achive the access to this EFI shell? I doubt that
>>> on the E540 (beware of
>>> the E, it is not a L or T model) does have such a shell.
>>> 
>>> Regards,
>>> oh
>> 
>> I would see if you can get REFIND loaded and use that.  I have a Lenovo
>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
>> (e.g. Win10 and FreeBSD) easily.
>> 
>> I've not had trouble with 12.x on it, and I do use the
>> geli-encrypted-aware loader.efi.
>> 
>> If there's a way to get into the EFI shell on Lenovo's laptops from the
>> BIOS during the boot I've not found it yet.  There's supposed to be on
>> all EFI devices, but you know how "supposed to" works in many cases, right?
>> 
>> --
>> Karl Denninger
>> k...@denninger.net <mailto:k...@denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>> 
>> 
>> 
> ___
> 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Clay Daniels Jr.]

I would agree with Karl & Steffen about using rEFInd. It really gives you a
lot more control of your computers boot. Take a look at Rod Smith's pages:
http://www.rodsbooks.com/refind/

I use it to triple boot Windows 10, MX Linux, and FreeBSD.

Clay

On Wed, Aug 21, 2019 at 3:59 PM Karl Denninger  wrote:

> BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Am Wed, 21 Aug 2019 22:34:21 +0300
> > Toomas Soome  schrieb:
> >
> > >> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >> Hash: SHA256
> > >>
> > >> Am Wed, 21 Aug 2019 22:14:46 +0300
> > >> Toomas Soome mailto:tso...@me.com>> schrieb:
> > >>
> > >>> If you drop into efi shell, can you start efi/boot/bootx64.efi
> > manually? you should have
> > >>> fs0: or like for ESP.
> > >>>
> > >>> rgds,
> > >>> toomas
> > >>
> > >> Hello,
> > >>
> > >> I can't even stop to gain access to the shell; there is no
> > timeframe to hit any key to
> > >> stop by and access the efi shell.
> > >>
> > >> Kind regards,
> > >> oh
> >
> >
> > > hm? efi shell should be available from boot device menu, so you
> > mean, you can not even get
> > > into firmware setup?
> >
> > > rgds,
> > > toomas
> >
> > Sorry,
> > I confused loader prompt and EFI shell.
> >
> > I do not have a EFI shell on that type of laptop, not to know about
> > it. I can access the
> > firmware setup and already performed a reset and switched back to
> > default settings. No effect.
> >
> > I just downloaded the newest CURRENT mem stick and extracted both
> > boot1.efi and loader.efi and
> > installed those into the ESP as described, setting the efibootmgr env
> > accordingly. Still the
> > same error.
> >
> > It seems that there is indeed no EFI/UEFI shell. There are Lenovo
> > specific EFI boot options,
> > like "diagnostics" and so on, if selected, the UEFI boots into a
> > firmware embedded diagnostic
> > menu. I tried several from the list given via efibootmgr show -v, but
> > there is no shell from
> > which I could access/boot an alternative loader.
> >
> > How I'm supposed to achive the access to this EFI shell? I doubt that
> > on the E540 (beware of
> > the E, it is not a L or T model) does have such a shell.
> >
> > Regards,
> > oh
>
> I would see if you can get REFIND loaded and use that.  I have a Lenovo
> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
> (e.g. Win10 and FreeBSD) easily.
>
> I've not had trouble with 12.x on it, and I do use the
> geli-encrypted-aware loader.efi.
>
> If there's a way to get into the EFI shell on Lenovo's laptops from the
> BIOS during the boot I've not found it yet.  There's supposed to be on
> all EFI devices, but you know how "supposed to" works in many cases, right?
>
> --
> Karl Denninger
> k...@denninger.net 
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
>
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Karl Denninger]

BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Am Wed, 21 Aug 2019 22:34:21 +0300
> Toomas Soome  schrieb:
>
> >> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Am Wed, 21 Aug 2019 22:14:46 +0300
> >> Toomas Soome mailto:tso...@me.com>> schrieb:
> >>   
> >>> If you drop into efi shell, can you start efi/boot/bootx64.efi
> manually? you should have
> >>> fs0: or like for ESP.
> >>>
> >>> rgds,
> >>> toomas  
> >>
> >> Hello,
> >>
> >> I can't even stop to gain access to the shell; there is no
> timeframe to hit any key to
> >> stop by and access the efi shell.
> >>
> >> Kind regards,
> >> oh  
>
>
> > hm? efi shell should be available from boot device menu, so you
> mean, you can not even get
> > into firmware setup?
>
> > rgds,
> > toomas
>
> Sorry,
> I confused loader prompt and EFI shell.
>
> I do not have a EFI shell on that type of laptop, not to know about
> it. I can access the
> firmware setup and already performed a reset and switched back to
> default settings. No effect.
>
> I just downloaded the newest CURRENT mem stick and extracted both
> boot1.efi and loader.efi and
> installed those into the ESP as described, setting the efibootmgr env
> accordingly. Still the
> same error.
>
> It seems that there is indeed no EFI/UEFI shell. There are Lenovo
> specific EFI boot options,
> like "diagnostics" and so on, if selected, the UEFI boots into a
> firmware embedded diagnostic
> menu. I tried several from the list given via efibootmgr show -v, but
> there is no shell from
> which I could access/boot an alternative loader.
>
> How I'm supposed to achive the access to this EFI shell? I doubt that
> on the E540 (beware of
> the E, it is not a L or T model) does have such a shell.
>
> Regards,
> oh

I would see if you can get REFIND loaded and use that.  I have a Lenovo
X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
(e.g. Win10 and FreeBSD) easily.

I've not had trouble with 12.x on it, and I do use the
geli-encrypted-aware loader.efi.

If there's a way to get into the EFI shell on Lenovo's laptops from the
BIOS during the boot I've not found it yet.  There's supposed to be on
all EFI devices, but you know how "supposed to" works in many cases, right?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/




smime.p7s
Description: S/MIME Cryptographic Signature

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Warner Losh]

On Wed, Aug 21, 2019 at 2:50 PM O. Hartmann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Am Wed, 21 Aug 2019 22:34:21 +0300
> Toomas Soome  schrieb:
>
> > > On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Am Wed, 21 Aug 2019 22:14:46 +0300
> > > Toomas Soome mailto:tso...@me.com>> schrieb:
> > >
> > >> If you drop into efi shell, can you start efi/boot/bootx64.efi
> manually? you should have
> > >> fs0: or like for ESP.
> > >>
> > >> rgds,
> > >> toomas
> > >
> > > Hello,
> > >
> > > I can't even stop to gain access to the shell; there is no timeframe
> to hit any key to
> > > stop by and access the efi shell.
> > >
> > > Kind regards,
> > > oh
> >
> >
> > hm? efi shell should be available from boot device menu, so you mean,
> you can not even get
> > into firmware setup?
> >
> > rgds,
> > toomas
> >
> > >
> > >>
> > >>> On 21 Aug 2019, at 20:58, O. Hartmann 
> wrote:
> > >>>
> > >>> -BEGIN PGP SIGNED MESSAGE-
> > >>> Hash: SHA256
> > >>>
> > >>> I ran into serious trouble booting several boxes off UEFI. On modern
> hardware,
> > >>> the ESP is around 200 - 300 MB in size and usually I install
> > >>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On
> some older
> > >>> hardware, specifically on a Lenovo E540 with latest available
> firmware (2.28),
> > >>> which uses 12-STABLE and a ZFS-only installation, there seems no
> working loader
> > >>> anymore!
> > >>> The installation of the Laptop has been performed using
> 12.0-PRERELEASE on an
> > >>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> > >>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> > >>>
> > >>> The ESP has been destroyed by accident. Now I tried to solve the
> problem by
> > >>> installing a new ESP and the proper loader, assuming that
> /boot/loader.efi
> > >>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same
> revision and
> > >>> sompiled on the same platform (Intel Haswell) as the lost laptop's
> revison of
> > >>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is
> setting up a
> > >>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X
> some Hex
> > >>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> > >>>
> > >>> Installing the proper boot/loader.efi loader file from 12-STABLE
> (r351108) and
> > >>> setting the EFI variable according the following steps:
> > >>>
> > >>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is
> zroot)
> > >>> Install then loader.efi either as BOOTx64.efi or loader.efi under
> > >>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> > >>> accordingly via
> > >>>
> > >>> delete 000A first:
> > >>> efibootmgr -B -b 000A
> > >>>
> > >>> create the new efi boot var:
> > >>> efibootmgr -a -b 000A -c -l
> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
> > >>> FreeBSD
> > >>>
> > >>> The result is a non booting system, the Lenovo firmware jumps
> immediately into
> > >>> the menu for selecting a proper boot media.
> > >>>
> > >>> The same happens with /boot/boot1.efi installed as loader.efi or
> BOOTx64.efi
> > >>> shown above.
> > >>>
> > >>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> > >>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper
> 12-STABLE system I
> > >>> spoeke of above), then booting fails again, but this time with an
> error I watch
> > >>> on so many boxes recently:
> > >>>
> > >>> [...]
> > >>> Ignoring Boot000a: Only one DP found
> > >>> Trying ZFS pool
> > >>> Setting currdev to zfs:zroot/ROOT/default:
> > >>>
> > >>> Then the console freezes at that point and only RESET or POWER OFF
> is capable
> > >>> of a revive.
> > >>>
> > >>> What is wrong here? What am I missing?
> > >>>
> > >>> Thanks in advance,
> > >>>
> [...]
>
> What does the message:
>
> Only one DP found
>
> mean? Obviously, "Trying ZFS pool - Setting currdev to
> zfs"zroot/ROOT/default:" indicates that
> the loader has already found its partition to bbot from, but why is it
> freezing/crashing then?
> No Ctrl-Alt-Del helps, only hard reset or power cycle brings the box back.
>

It means there was no explicit kernel specified and so the system is going
to guess which kernel (and which root) to use. The fact that you don't see
a kernel booting suggests it's unable to do so properly.

Warner


> 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).
> -BEGIN PGP SIGNATURE-
>
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2tQgAKCRA4N1ZZPba5
> R8PmAQCysRllIHaShJZOAQHy6YY2THQwRruzziJUY+zer/i/7QEAi/C68BgEJtuW
> mD2oPCsXJR8AO10XFDvO+uI8ugCV/wE=
> =ILkO
> -END PGP SIGNATURE-
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> 

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 22:34:21 +0300
Toomas Soome  schrieb:

> > On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Am Wed, 21 Aug 2019 22:14:46 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? 
> >> you should have
> >> fs0: or like for ESP.
> >> 
> >> rgds,
> >> toomas  
> > 
> > Hello,
> > 
> > I can't even stop to gain access to the shell; there is no timeframe to hit 
> > any key to
> > stop by and access the efi shell. 
> > 
> > Kind regards,
> > oh  
> 
> 
> hm? efi shell should be available from boot device menu, so you mean, you can 
> not even get
> into firmware setup?
> 
> rgds,
> toomas
> 
> >   
> >>   
> >>> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>> 
> >>> I ran into serious trouble booting several boxes off UEFI. On modern 
> >>> hardware,
> >>> the ESP is around 200 - 300 MB in size and usually I install
> >>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
> >>> older
> >>> hardware, specifically on a Lenovo E540 with latest available firmware 
> >>> (2.28),
> >>> which uses 12-STABLE and a ZFS-only installation, there seems no working 
> >>> loader
> >>> anymore!
> >>> The installation of the Laptop has been performed using 12.0-PRERELEASE 
> >>> on an
> >>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> >>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> >>> 
> >>> The ESP has been destroyed by accident. Now I tried to solve the problem 
> >>> by
> >>> installing a new ESP and the proper loader, assuming that /boot/loader.efi
> >>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision 
> >>> and
> >>> sompiled on the same platform (Intel Haswell) as the lost laptop's 
> >>> revison of
> >>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting 
> >>> up a
> >>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> >>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> >>> 
> >>> Installing the proper boot/loader.efi loader file from 12-STABLE 
> >>> (r351108) and
> >>> setting the EFI variable according the following steps:
> >>> 
> >>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is 
> >>> zroot)
> >>> Install then loader.efi either as BOOTx64.efi or loader.efi under
> >>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> >>> accordingly via
> >>> 
> >>> delete 000A first:
> >>> efibootmgr -B -b 000A
> >>> 
> >>> create the new efi boot var:
> >>> efibootmgr -a -b 000A -c -l 
> >>> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
> >>> FreeBSD
> >>> 
> >>> The result is a non booting system, the Lenovo firmware jumps immediately 
> >>> into
> >>> the menu for selecting a proper boot media.
> >>> 
> >>> The same happens with /boot/boot1.efi installed as loader.efi or 
> >>> BOOTx64.efi
> >>> shown above.
> >>> 
> >>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> >>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
> >>> system I
> >>> spoeke of above), then booting fails again, but this time with an error I 
> >>> watch
> >>> on so many boxes recently:
> >>> 
> >>> [...]
> >>> Ignoring Boot000a: Only one DP found
> >>> Trying ZFS pool
> >>> Setting currdev to zfs:zroot/ROOT/default:
> >>> 
> >>> Then the console freezes at that point and only RESET or POWER OFF is 
> >>> capable
> >>> of a revive.
> >>> 
> >>> What is wrong here? What am I missing?
> >>> 
> >>> Thanks in advance,
> >>> 
[...]

What does the message:

Only one DP found

mean? Obviously, "Trying ZFS pool - Setting currdev to zfs"zroot/ROOT/default:" 
indicates that
the loader has already found its partition to bbot from, but why is it 
freezing/crashing then?
No Ctrl-Alt-Del helps, only hard reset or power cycle brings the box back.

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).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2tQgAKCRA4N1ZZPba5
R8PmAQCysRllIHaShJZOAQHy6YY2THQwRruzziJUY+zer/i/7QEAi/C68BgEJtuW
mD2oPCsXJR8AO10XFDvO+uI8ugCV/wE=
=ILkO
-END PGP SIGNATURE-
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 22:34:21 +0300
Toomas Soome  schrieb:

> > On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Am Wed, 21 Aug 2019 22:14:46 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? 
> >> you should have
> >> fs0: or like for ESP.
> >> 
> >> rgds,
> >> toomas  
> > 
> > Hello,
> > 
> > I can't even stop to gain access to the shell; there is no timeframe to hit 
> > any key to
> > stop by and access the efi shell. 
> > 
> > Kind regards,
> > oh  
> 
> 
> hm? efi shell should be available from boot device menu, so you mean, you can 
> not even get
> into firmware setup?
> 
> rgds,
> toomas

Sorry,
I confused loader prompt and EFI shell.

I do not have a EFI shell on that type of laptop, not to know about it. I can 
access the
firmware setup and already performed a reset and switched back to default 
settings. No effect.

I just downloaded the newest CURRENT mem stick and extracted both boot1.efi and 
loader.efi and
installed those into the ESP as described, setting the efibootmgr env 
accordingly. Still the
same error.

It seems that there is indeed no EFI/UEFI shell. There are Lenovo specific EFI 
boot options,
like "diagnostics" and so on, if selected, the UEFI boots into a firmware 
embedded diagnostic
menu. I tried several from the list given via efibootmgr show -v, but there is 
no shell from
which I could access/boot an alternative loader.

How I'm supposed to achive the access to this EFI shell? I doubt that on the 
E540 (beware of
the E, it is not a L or T model) does have such a shell.

Regards,
oh 
> 
> >   
> >>   
> >>> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>> 
> >>> I ran into serious trouble booting several boxes off UEFI. On modern 
> >>> hardware,
> >>> the ESP is around 200 - 300 MB in size and usually I install
> >>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
> >>> older
> >>> hardware, specifically on a Lenovo E540 with latest available firmware 
> >>> (2.28),
> >>> which uses 12-STABLE and a ZFS-only installation, there seems no working 
> >>> loader
> >>> anymore!
> >>> The installation of the Laptop has been performed using 12.0-PRERELEASE 
> >>> on an
> >>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> >>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> >>> 
> >>> The ESP has been destroyed by accident. Now I tried to solve the problem 
> >>> by
> >>> installing a new ESP and the proper loader, assuming that /boot/loader.efi
> >>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision 
> >>> and
> >>> sompiled on the same platform (Intel Haswell) as the lost laptop's 
> >>> revison of
> >>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting 
> >>> up a
> >>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> >>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> >>> 
> >>> Installing the proper boot/loader.efi loader file from 12-STABLE 
> >>> (r351108) and
> >>> setting the EFI variable according the following steps:
> >>> 
> >>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is 
> >>> zroot)
> >>> Install then loader.efi either as BOOTx64.efi or loader.efi under
> >>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> >>> accordingly via
> >>> 
> >>> delete 000A first:
> >>> efibootmgr -B -b 000A
> >>> 
> >>> create the new efi boot var:
> >>> efibootmgr -a -b 000A -c -l 
> >>> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
> >>> FreeBSD
> >>> 
> >>> The result is a non booting system, the Lenovo firmware jumps immediately 
> >>> into
> >>> the menu for selecting a proper boot media.
> >>> 
> >>> The same happens with /boot/boot1.efi installed as loader.efi or 
> >>> BOOTx64.efi
> >>> shown above.
> >>> 
> >>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> >>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
> >>> system I
> >>> spoeke of above), then booting fails again, but this time with an error I 
> >>> watch
> >>> on so many boxes recently:
> >>> 
> >>> [...]
> >>> Ignoring Boot000a: Only one DP found
> >>> Trying ZFS pool
> >>> Setting currdev to zfs:zroot/ROOT/default:
> >>> 
> >>> Then the console freezes at that point and only RESET or POWER OFF is 
> >>> capable
> >>> of a revive.
> >>> 
> >>> What is wrong here? What am I missing?
> >>> 
> >>> Thanks in advance,
> >>> 
> >>> 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).
> >>> -BEGIN PGP SIGNATURE-
> >>> 

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Steffen Nurpmeso]

O. Hartmann wrote in <20190821145234.6fe455b4@freyja>:
 |I ran into serious trouble booting several boxes off UEFI. On modern \
 |hardware,
 |the ESP is around 200 - 300 MB in size and usually I install
 |/efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On \
 |some older
 |hardware, specifically on a Lenovo E540 with latest available firmware \
 |(2.28),
 |which uses 12-STABLE and a ZFS-only installation, there seems no working \
 |loader
 |anymore!
 |The installation of the Laptop has been performed using 12.0-PRERELEASE \
 |on an
 |Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
 |/efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.

It may be that the Lenovo BIOS/firmware searches for that specific
Microsoft location

  EFI/Microsoft/Boot/bootmgfw.efi

Onto which i radically (according to docu) moved refind_x64.efi:

  #?0|kent:~# ll /mnt/EFI/Microsoft/Boot/bootmg*
  -rwxr-xr-x 1 root root 1453056 Sep 14  2018 
/mnt/EFI/Microsoft/Boot/bootmgr.efi
  -rwxr-xr-x 1 root root 1469752 Mar 21 17:43 
/mnt/EFI/Microsoft/Boot/bootmgfw.efi.safe
  -rwxr-xr-x 1 root root  208776 Mar 21 17:43 
/mnt/EFI/Microsoft/Boot/bootmgfw.efi

and that now finds its normal installation (etc.), simply copied
via cp(1):

  #?0|kent:~# ll /mnt/EFI/refind/
  total 260
  drwxr-xr-x 2 root root   4096 Mar 21 17:13 drivers_x64
  -rwxr-xr-x 1 root root 208776 Mar 21 17:14 refind_x64.efi
  drwxr-xr-x 3 root root   8192 Mar 21 17:18 icons
  drwxr-xr-x 2 root root   4096 Apr  8 13:39 vars
  drwxr-xr-x 5 root root   4096 Apr  8 13:39 ..
  -rwxr-xr-x 1 root root  32233 Apr 16 22:55 refind.conf
  drwxr-xr-x 5 root root   4096 Apr 16 22:55 .

  ...
 |What is wrong here? What am I missing?

Maybe that helps.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 21 Aug 2019 22:14:46 +0300
Toomas Soome  schrieb:

> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you 
> should have
> fs0: or like for ESP.
> 
> rgds,
> toomas

Hello,

I can't even stop to gain access to the shell; there is no timeframe to hit any 
key to stop by
and access the efi shell. 

Kind regards,
oh

> 
> > On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > I ran into serious trouble booting several boxes off UEFI. On modern 
> > hardware,
> > the ESP is around 200 - 300 MB in size and usually I install
> > /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
> > older
> > hardware, specifically on a Lenovo E540 with latest available firmware 
> > (2.28),
> > which uses 12-STABLE and a ZFS-only installation, there seems no working 
> > loader
> > anymore!
> > The installation of the Laptop has been performed using 12.0-PRERELEASE on 
> > an
> > Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> > /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> > 
> > The ESP has been destroyed by accident. Now I tried to solve the problem by
> > installing a new ESP and the proper loader, assuming that /boot/loader.efi
> > (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
> > sompiled on the same platform (Intel Haswell) as the lost laptop's revison 
> > of
> > the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
> > lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> > numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> > 
> > Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) 
> > and
> > setting the EFI variable according the following steps:
> > 
> > mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
> > Install then loader.efi either as BOOTx64.efi or loader.efi under
> > /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> > accordingly via
> > 
> > delete 000A first:
> > efibootmgr -B -b 000A
> > 
> > create the new efi boot var:
> > efibootmgr -a -b 000A -c -l 
> > /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
> > FreeBSD
> > 
> > The result is a non booting system, the Lenovo firmware jumps immediately 
> > into
> > the menu for selecting a proper boot media.
> > 
> > The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
> > shown above.
> > 
> > In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> > if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
> > system I
> > spoeke of above), then booting fails again, but this time with an error I 
> > watch
> > on so many boxes recently:
> > 
> > [...]
> > Ignoring Boot000a: Only one DP found
> > Trying ZFS pool
> > Setting currdev to zfs:zroot/ROOT/default:
> > 
> > Then the console freezes at that point and only RESET or POWER OFF is 
> > capable
> > of a revive.
> > 
> > What is wrong here? What am I missing?
> > 
> > Thanks in advance,
> > 
> > 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).
> > -BEGIN PGP SIGNATURE-
> > 
> > iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
> > R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
> > fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
> > =3img
> > -END PGP SIGNATURE-
> > ___
> > 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"



- -- 
O. Hartmann

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

iHQEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2b/AAKCRA4N1ZZPba5
R+DDAP9LN8SDMDm/0ybGw+TBqczvS+m51n0DMYEqMZxTsikIFgD46rrBkm4zpKH5
BDk3pkVT+h7MH8ghESa7XfhFGg3pCg==
=/Hm2
-END PGP SIGNATURE-
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Wed, 21 Aug 2019 22:14:46 +0300
> Toomas Soome mailto:tso...@me.com>> schrieb:
> 
>> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you 
>> should have
>> fs0: or like for ESP.
>> 
>> rgds,
>> toomas
> 
> Hello,
> 
> I can't even stop to gain access to the shell; there is no timeframe to hit 
> any key to stop by
> and access the efi shell. 
> 
> Kind regards,
> oh


hm? efi shell should be available from boot device menu, so you mean, you can 
not even get into firmware setup?

rgds,
toomas

> 
>> 
>>> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> I ran into serious trouble booting several boxes off UEFI. On modern 
>>> hardware,
>>> the ESP is around 200 - 300 MB in size and usually I install
>>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
>>> older
>>> hardware, specifically on a Lenovo E540 with latest available firmware 
>>> (2.28),
>>> which uses 12-STABLE and a ZFS-only installation, there seems no working 
>>> loader
>>> anymore!
>>> The installation of the Laptop has been performed using 12.0-PRERELEASE on 
>>> an
>>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
>>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
>>> 
>>> The ESP has been destroyed by accident. Now I tried to solve the problem by
>>> installing a new ESP and the proper loader, assuming that /boot/loader.efi
>>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
>>> sompiled on the same platform (Intel Haswell) as the lost laptop's revison 
>>> of
>>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
>>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
>>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
>>> 
>>> Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) 
>>> and
>>> setting the EFI variable according the following steps:
>>> 
>>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
>>> Install then loader.efi either as BOOTx64.efi or loader.efi under
>>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
>>> accordingly via
>>> 
>>> delete 000A first:
>>> efibootmgr -B -b 000A
>>> 
>>> create the new efi boot var:
>>> efibootmgr -a -b 000A -c -l 
>>> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
>>> FreeBSD
>>> 
>>> The result is a non booting system, the Lenovo firmware jumps immediately 
>>> into
>>> the menu for selecting a proper boot media.
>>> 
>>> The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
>>> shown above.
>>> 
>>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
>>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
>>> system I
>>> spoeke of above), then booting fails again, but this time with an error I 
>>> watch
>>> on so many boxes recently:
>>> 
>>> [...]
>>> Ignoring Boot000a: Only one DP found
>>> Trying ZFS pool
>>> Setting currdev to zfs:zroot/ROOT/default:
>>> 
>>> Then the console freezes at that point and only RESET or POWER OFF is 
>>> capable
>>> of a revive.
>>> 
>>> What is wrong here? What am I missing?
>>> 
>>> Thanks in advance,
>>> 
>>> 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).
>>> -BEGIN PGP SIGNATURE-
>>> 
>>> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
>>> R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
>>> fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
>>> =3img
>>> -END PGP SIGNATURE-
>>> ___
>>> 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 
>> "
> 
> 
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iHQEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2b/AAKCRA4N1ZZPba5
> R+DDAP9LN8SDMDm/0ybGw+TBqczvS+m51n0DMYEqMZxTsikIFgD46rrBkm4zpKH5
> BDk3pkVT+h7MH8ghESa7XfhFGg3pCg==
> =/Hm2
> -END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list

HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

I ran into serious trouble booting several boxes off UEFI. On modern hardware,
the ESP is around 200 - 300 MB in size and usually I install
/efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older
hardware, specifically on a Lenovo E540 with latest available firmware (2.28),
which uses 12-STABLE and a ZFS-only installation, there seems no working loader
anymore!
The installation of the Laptop has been performed using 12.0-PRERELEASE on an
Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
/efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.

The ESP has been destroyed by accident. Now I tried to solve the problem by
installing a new ESP and the proper loader, assuming that /boot/loader.efi
(taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
sompiled on the same platform (Intel Haswell) as the lost laptop's revison of
the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
numer. -b 000A is usually denoted/labeld with "ATA HDD0".

Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) and
setting the EFI variable according the following steps:

mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
Install then loader.efi either as BOOTx64.efi or loader.efi under
/mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
accordingly via

delete 000A first:
efibootmgr -B -b 000A

create the new efi boot var:
efibootmgr -a -b 000A -c -l /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
FreeBSD

The result is a non booting system, the Lenovo firmware jumps immediately into
the menu for selecting a proper boot media.

The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
shown above.

In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE system I
spoeke of above), then booting fails again, but this time with an error I watch
on so many boxes recently:

[...]
Ignoring Boot000a: Only one DP found
Trying ZFS pool
Setting currdev to zfs:zroot/ROOT/default:

Then the console freezes at that point and only RESET or POWER OFF is capable
of a revive.

What is wrong here? What am I missing?

Thanks in advance,

oh
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you 
should have fs0: or like for ESP.

rgds,
toomas

> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I ran into serious trouble booting several boxes off UEFI. On modern hardware,
> the ESP is around 200 - 300 MB in size and usually I install
> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older
> hardware, specifically on a Lenovo E540 with latest available firmware (2.28),
> which uses 12-STABLE and a ZFS-only installation, there seems no working 
> loader
> anymore!
> The installation of the Laptop has been performed using 12.0-PRERELEASE on an
> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> 
> The ESP has been destroyed by accident. Now I tried to solve the problem by
> installing a new ESP and the proper loader, assuming that /boot/loader.efi
> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
> sompiled on the same platform (Intel Haswell) as the lost laptop's revison of
> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> 
> Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) and
> setting the EFI variable according the following steps:
> 
> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
> Install then loader.efi either as BOOTx64.efi or loader.efi under
> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> accordingly via
> 
> delete 000A first:
> efibootmgr -B -b 000A
> 
> create the new efi boot var:
> efibootmgr -a -b 000A -c -l /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} 
> -L
> FreeBSD
> 
> The result is a non booting system, the Lenovo firmware jumps immediately into
> the menu for selecting a proper boot media.
> 
> The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
> shown above.
> 
> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE system 
> I
> spoeke of above), then booting fails again, but this time with an error I 
> watch
> on so many boxes recently:
> 
> [...]
> Ignoring Boot000a: Only one DP found
> Trying ZFS pool
> Setting currdev to zfs:zroot/ROOT/default:
> 
> Then the console freezes at that point and only RESET or POWER OFF is capable
> of a revive.
> 
> What is wrong here? What am I missing?
> 
> Thanks in advance,
> 
> 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).
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
> R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
> fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
> =3img
> -END PGP SIGNATURE-
> ___
> 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"

HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran into serious trouble booting several boxes off UEFI. On modern hardware,
the ESP is around 200 - 300 MB in size and usually I install
/efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older
hardware, specifically on a Lenovo E540 with latest available firmware (2.28),
which uses 12-STABLE and a ZFS-only installation, there seems no working loader
anymore!
The installation of the Laptop has been performed using 12.0-PRERELEASE on an
Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
/efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.

The ESP has been destroyed by accident. Now I tried to solve the problem by
installing a new ESP and the proper loader, assuming that /boot/loader.efi
(taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
sompiled on the same platform (Intel Haswell) as the lost laptop's revison of
the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
numer. -b 000A is usually denoted/labeld with "ATA HDD0".

Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) and
setting the EFI variable according the following steps:

mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
Install then loader.efi either as BOOTx64.efi or loader.efi under
/mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
accordingly via

delete 000A first:
efibootmgr -B -b 000A

create the new efi boot var:
efibootmgr -a -b 000A -c -l /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
FreeBSD

The result is a non booting system, the Lenovo firmware jumps immediately into
the menu for selecting a proper boot media.

The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
shown above.

In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE system I
spoeke of above), then booting fails again, but this time with an error I watch
on so many boxes recently:

[...]
Ignoring Boot000a: Only one DP found
Trying ZFS pool
Setting currdev to zfs:zroot/ROOT/default:

Then the console freezes at that point and only RESET or POWER OFF is capable
of a revive.

What is wrong here? What am I missing?

Thanks in advance,

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).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
=3img
-END PGP SIGNATURE-
___
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: Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)

[Ali Abdallah]

On Wed, Sep 12, 2018 at 4:19 AM, Graham Perrin 
wrote:

> On 25/08/2018 09:32, Ali Abdallah wrote:
> > Isn't Intel supposed to be working on a native drm driver for FreeBSD?
> >
> > https://bwidawsk.net/blog/index.php/2018/06/i965-
> compiler-architecture-from-2015/
> …
>
> Not that I can see.
>
> A more recent blog post <https://bwidawsk.net/blog/
> index.php/2018/06/freebsd-work-week-2/> mentions "Help i915 drm-next-kmod
> work".
>

I saw that post already, It also mentions "Create native Intel graphics
driver."


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

Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)

[Graham Perrin]

On 25/08/2018 09:32, Ali Abdallah wrote:
> Isn't Intel supposed to be working on a native drm driver for FreeBSD?
>
> https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/
…

Not that I can see. 

A more recent blog post 
<https://bwidawsk.net/blog/index.php/2018/06/freebsd-work-week-2/> mentions 
"Help i915 drm-next-kmod work".

HTH

___
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 panic: Need help debugging

[lr x]

Hi!

I can get the kernel to panic when I try to run virtualbox (selecting the
amd64 ubuntu iso and attaching to virtual machine and starting it up.).

The kernel:
12.0-ALPHA3 FreeBSD 12.0-ALPHA3 #0 r338359: Wed Aug 29 21:49:53 EDT
2018 someone@somebox:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Virtualbox was installed with pkg install virtualbox-ose

I have access to the crash dump, but running with kgdb does not reveal more
information. I found a reference to the panic string:
https://reviews.freebsd.org/D4197 .  I could find that the panic string is
indeed printed in the malloc_dbg function in the /sys/kern/kern_malloc.c
file. How can I trace this further to understand why the kernel lands in
such a situation?

Thanks!

Here are the contents of the info.last file and kgdb invocation on the
crash dump.

# cat /var/crash/info.last
Dump header from device: /dev/ada0p4
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 937099264
  Blocksize: 512
  Compression: none
  Dumptime: Sat Sep  1 22:50:57 2018
  Hostname: somebox
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 12.0-ALPHA3 #0 r338359: Wed Aug 29 21:49:53 EDT
2018
someone@somebox:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  Panic String: malloc: called with spinlock or critical section held
  Dump Parity: 274387030
  Bounds: 3
  Dump Status: good


root@somebox:/usr/src # kgdb -n 3
<..snip..>
Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address= 0x80a851ab8
fault code= supervisor read data, protection violation
instruction pointer= 0x20:0x8354b2e4
stack pointer= 0x28:0xfe008ced1200
frame pointer= 0x28:0xfe008ced1200
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 1792 (VirtualBox)
Uptime: 48m52s
(ada0:ahcich2:0:0:0): spin-down
Dumping 893 out of 16221
MB:..2%..11%..22%..31%..42%..51%..61%..72%..81%..92%



#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1383
1383CPU_SET_ATOMIC(cpu, _cpus);

(kgdb) bt
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1383
#1  0x811d1484 in ipi_nmi_handler () at
/usr/src/sys/x86/x86/mp_x86.c:1341
#2  0x8105d889 in trap (frame=0x82057db0) at
/usr/src/sys/amd64/amd64/trap.c:206
#3  0x8103baad in nmi_calltrap () at
/usr/src/sys/amd64/amd64/exception.S:776
#4  0x811c1f76 in cpu_idle (busy=) at
/usr/src/sys/x86/x86/cpu_machdep.c:489
Previous frame inner to this frame (corrupt stack?)
___
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: Help USB keyboard trouble

[Alex V. Petrov]

The result of my new research:
In Frenzy (livecd on FreeBSD 6.1), the keyboard works fine.
In the system console(current), when connecting to my problem keyboard,
the output is working, and keyboard input is not. And after disabling
the keyboard input does not work.

09.05.2018 14:08, Hans Petter Selasky пишет:
> On 05/09/18 05:52, Alex V. Petrov wrote:
>> The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print
>> "A" when connected, as if the "a" key is pressed.
>> But in Windows and Linux keyboard work normaly.
>>
>> In log:
>>
>> May  9 10:43:38 alex kernel: ugen2.3:  at usbus2
>> May  9 10:43:38 alex kernel: ukbd0 on uhub6
>> May  9 10:43:38 alex kernel: ukbd0: > 2.00/1.00, addr 3> on usbus2
>> May  9 10:43:38 alex kernel: kbd2 at ukbd0
>> May  9 10:43:38 alex kernel: ukbd1 on uhub6
>> May  9 10:43:38 alex kernel: ukbd1: > 2.00/1.00, addr 3> on usbus2
>> May  9 10:43:38 alex kernel: kbd3 at ukbd1
>> ^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay
>>
>>   9 10:43:46 alex kernel: ugen2.3:  at usbus2
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd0: detached
>> May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd1: detached
>>
> 
> Hi,
> 
> Can you show the output from:
> 
> usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc
> 
> And also have a look at:
> 
> usbdump -i usbus2 -f 3 -vvv -s 65536
> 
> --HPS

-- 
-
Alex.
___
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: Help USB keyboard trouble

[Hans Petter Selasky]

On 06/15/18 08:45, Alex V. Petrov wrote:

Hans Petter!
What can you say about my problem?



Hi,

I didn't have time to look into this.

--HPS
___
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: Help USB keyboard trouble

[Alex V. Petrov]

Hans Petter!
What can you say about my problem?

09.05.2018 18:31, Alex V. Petrov пишет:
> 09.05.2018 14:08, Hans Petter Selasky пишет:
>> On 05/09/18 05:52, Alex V. Petrov wrote:
>>> The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print
>>> "A" when connected, as if the "a" key is pressed.
>>> But in Windows and Linux keyboard work normaly.
>>>
>>> In log:
>>>
>>> May  9 10:43:38 alex kernel: ugen2.3:  at usbus2
>>> May  9 10:43:38 alex kernel: ukbd0 on uhub6
>>> May  9 10:43:38 alex kernel: ukbd0: >> 2.00/1.00, addr 3> on usbus2
>>> May  9 10:43:38 alex kernel: kbd2 at ukbd0
>>> May  9 10:43:38 alex kernel: ukbd1 on uhub6
>>> May  9 10:43:38 alex kernel: ukbd1: >> 2.00/1.00, addr 3> on usbus2
>>> May  9 10:43:38 alex kernel: kbd3 at ukbd1
>>> ^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay
>>>
>>>   9 10:43:46 alex kernel: ugen2.3:  at usbus2
>>> (disconnected)
>>> May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3
>>> (disconnected)
>>> May  9 10:43:46 alex kernel: ukbd0: detached
>>> May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3
>>> (disconnected)
>>> May  9 10:43:46 alex kernel: ukbd1: detached
>>>
>>
>> Hi,
>>
>> Can you show the output from:
>>
>> usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc
>>
>> And also have a look at:
>>
>> usbdump -i usbus2 -f 3 -vvv -s 65536
>>
>> --HPS
>>
>> BTW: We have a list specifically for USB problems: freebsd-...@freebsd.org
>>
> 
> ugen2.3:  at usbus2, cfg=0 md=HOST spd=FULL (12Mbps)
> pwr=ON (100mA)
> 
>   bLength = 0x0012
>   bDescriptorType = 0x0001
>   bcdUSB = 0x0200
>   bDeviceClass = 0x  
>   bDeviceSubClass = 0x
>   bDeviceProtocol = 0x
>   bMaxPacketSize0 = 0x0040
>   idVendor = 0x0c45
>   idProduct = 0x0820
>   bcdDevice = 0x0100
>   iManufacturer = 0x0001  
>   iProduct = 0x0002  
>   iSerialNumber = 0x  
>   bNumConfigurations = 0x0001
> 
> 
>  Configuration index 0
> 
> bLength = 0x0009
> bDescriptorType = 0x0002
> wTotalLength = 0x003b
> bNumInterfaces = 0x0002
> bConfigurationValue = 0x0001
> iConfiguration = 0x  
> bmAttributes = 0x00a0
> bMaxPower = 0x0032
> 
> Interface 0
>   bLength = 0x0009
>   bDescriptorType = 0x0004
>   bInterfaceNumber = 0x
>   bAlternateSetting = 0x
>   bNumEndpoints = 0x0001
>   bInterfaceClass = 0x0003  
>   bInterfaceSubClass = 0x0001
>   bInterfaceProtocol = 0x0001
>   iInterface = 0x  
> 
>   Additional Descriptor
> 
>   bLength = 0x09
>   bDescriptorType = 0x21
>   bDescriptorSubType = 0x11
>RAW dump:
>0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x4f,
>0x08 | 0x00
> 
>  Endpoint 0
> bLength = 0x0007
> bDescriptorType = 0x0005
> bEndpointAddress = 0x0081  
> bmAttributes = 0x0003  
> wMaxPacketSize = 0x0008
> bInterval = 0x0008
> bRefresh = 0x
> bSynchAddress = 0x
> 
> Interface 1
>   bLength = 0x0009
>   bDescriptorType = 0x0004
>   bInterfaceNumber = 0x0001
>   bAlternateSetting = 0x
>   bNumEndpoints = 0x0001
>   bInterfaceClass = 0x0003  
>   bInterfaceSubClass = 0x0001
>   bInterfaceProtocol = 0x0002
>   iInterface = 0x  
> 
>   Additional Descriptor
> 
>   bLength = 0x09
>   bDescriptorType = 0x21
>   bDescriptorSubType = 0x11
>RAW dump:
>0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x71,
>0x08 | 0x00
> 
>  Endpoint 0
> bLength = 0x0007
> bDescriptorType = 0x0005
> bEndpointAddress = 0x0082  
> bmAttributes = 0x0003  
> wMaxPacketSize = 0x0040
> bInterval = 0x0001
> bRefresh = 0x
> bSynchAddress = 0x
> 
> 
> 
> 
> 18:27:21.923619 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
>  frame[0] WRITE 8 bytes
>    00 05 03 00 00 00 00 00  -- -- -- -- -- -- -- --  ||
>  flags 0x50 
>  status 0xea3a3
> 
> 18:27:21.925027 usbus2.3
> DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>  frame[0] WRITE 8 bytes
>  flags 0x50 
>  status 0xca3a1
> 
> 18:27:21.925048 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0
>  frame[0] WRITE 0 bytes
>  flags 0x10 
>  status 0xca0a3
> 
> 18:27:21.927027 usbus2.3
> DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>  frame[0] WRITE 0 bytes
>  flags 0x10 
>  status 0xea0a1
> 
> 18:27:21.941516 usbus2.3 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
>  frame[0] WRITE 8 bytes
>    80 06 00 01 00 00 08 00  -- -- -- -- -- -- -- --  ||
>  frame[1] READ 8 bytes
>  flags 0x10 
>  status 0xea1a3
> 
> 18:27:21.943021 usbus2.3
> DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0
>  frame[0] WRITE 8 bytes
>  frame[1] READ 8 bytes
>  

Re: Help USB keyboard trouble

[Alex V. Petrov]

09.05.2018 14:08, Hans Petter Selasky пишет:
> On 05/09/18 05:52, Alex V. Petrov wrote:
>> The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print
>> "A" when connected, as if the "a" key is pressed.
>> But in Windows and Linux keyboard work normaly.
>>
>> In log:
>>
>> May  9 10:43:38 alex kernel: ugen2.3:  at usbus2
>> May  9 10:43:38 alex kernel: ukbd0 on uhub6
>> May  9 10:43:38 alex kernel: ukbd0: > 2.00/1.00, addr 3> on usbus2
>> May  9 10:43:38 alex kernel: kbd2 at ukbd0
>> May  9 10:43:38 alex kernel: ukbd1 on uhub6
>> May  9 10:43:38 alex kernel: ukbd1: > 2.00/1.00, addr 3> on usbus2
>> May  9 10:43:38 alex kernel: kbd3 at ukbd1
>> ^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay
>>
>>   9 10:43:46 alex kernel: ugen2.3:  at usbus2
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd0: detached
>> May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3
>> (disconnected)
>> May  9 10:43:46 alex kernel: ukbd1: detached
>>
> 
> Hi,
> 
> Can you show the output from:
> 
> usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc
> 
> And also have a look at:
> 
> usbdump -i usbus2 -f 3 -vvv -s 65536
> 
> --HPS
> 
> BTW: We have a list specifically for USB problems: freebsd-...@freebsd.org
> 

ugen2.3:  at usbus2, cfg=0 md=HOST spd=FULL (12Mbps)
pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x  
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0c45
  idProduct = 0x0820
  bcdDevice = 0x0100
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001


 Configuration index 0

bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x003b
bNumInterfaces = 0x0002
bConfigurationValue = 0x0001
iConfiguration = 0x  
bmAttributes = 0x00a0
bMaxPower = 0x0032

Interface 0
  bLength = 0x0009
  bDescriptorType = 0x0004
  bInterfaceNumber = 0x
  bAlternateSetting = 0x
  bNumEndpoints = 0x0001
  bInterfaceClass = 0x0003  
  bInterfaceSubClass = 0x0001
  bInterfaceProtocol = 0x0001
  iInterface = 0x  

  Additional Descriptor

  bLength = 0x09
  bDescriptorType = 0x21
  bDescriptorSubType = 0x11
   RAW dump:
   0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x4f,
   0x08 | 0x00

 Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0081  
bmAttributes = 0x0003  
wMaxPacketSize = 0x0008
bInterval = 0x0008
bRefresh = 0x
bSynchAddress = 0x

Interface 1
  bLength = 0x0009
  bDescriptorType = 0x0004
  bInterfaceNumber = 0x0001
  bAlternateSetting = 0x
  bNumEndpoints = 0x0001
  bInterfaceClass = 0x0003  
  bInterfaceSubClass = 0x0001
  bInterfaceProtocol = 0x0002
  iInterface = 0x  

  Additional Descriptor

  bLength = 0x09
  bDescriptorType = 0x21
  bDescriptorSubType = 0x11
   RAW dump:
   0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x71,
   0x08 | 0x00

 Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0082  
bmAttributes = 0x0003  
wMaxPacketSize = 0x0040
bInterval = 0x0001
bRefresh = 0x
bSynchAddress = 0x




18:27:21.923619 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   00 05 03 00 00 00 00 00  -- -- -- -- -- -- -- --  ||
 flags 0x50 
 status 0xea3a3

18:27:21.925027 usbus2.3
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 flags 0x50 
 status 0xca3a1

18:27:21.925048 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0
 frame[0] WRITE 0 bytes
 flags 0x10 
 status 0xca0a3

18:27:21.927027 usbus2.3
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 0 bytes
 flags 0x10 
 status 0xea0a1

18:27:21.941516 usbus2.3 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 01 00 00 08 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 8 bytes
 flags 0x10 

Re: Help USB keyboard trouble

[Hans Petter Selasky]

On 05/09/18 05:52, Alex V. Petrov wrote:

The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print
"A" when connected, as if the "a" key is pressed.
But in Windows and Linux keyboard work normaly.

In log:

May  9 10:43:38 alex kernel: ugen2.3:  at usbus2
May  9 10:43:38 alex kernel: ukbd0 on uhub6
May  9 10:43:38 alex kernel: ukbd0:  on usbus2
May  9 10:43:38 alex kernel: kbd2 at ukbd0
May  9 10:43:38 alex kernel: ukbd1 on uhub6
May  9 10:43:38 alex kernel: ukbd1:  on usbus2
May  9 10:43:38 alex kernel: kbd3 at ukbd1
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay
  9 10:43:46 alex kernel: ugen2.3:  at usbus2
(disconnected)
May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3 (disconnected)
May  9 10:43:46 alex kernel: ukbd0: detached
May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3 (disconnected)
May  9 10:43:46 alex kernel: ukbd1: detached



Hi,

Can you show the output from:

usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc

And also have a look at:

usbdump -i usbus2 -f 3 -vvv -s 65536

--HPS

BTW: We have a list specifically for USB problems: freebsd-...@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"

Help USB keyboard trouble

[Alex V. Petrov]

The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print
"A" when connected, as if the "a" key is pressed.
But in Windows and Linux keyboard work normaly.

In log:

May  9 10:43:38 alex kernel: ugen2.3:  at usbus2
May  9 10:43:38 alex kernel: ukbd0 on uhub6
May  9 10:43:38 alex kernel: ukbd0:  on usbus2
May  9 10:43:38 alex kernel: kbd2 at ukbd0
May  9 10:43:38 alex kernel: ukbd1 on uhub6
May  9 10:43:38 alex kernel: ukbd1:  on usbus2
May  9 10:43:38 alex kernel: kbd3 at ukbd1
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay
 9 10:43:46 alex kernel: ugen2.3:  at usbus2
(disconnected)
May  9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3 (disconnected)
May  9 10:43:46 alex kernel: ukbd0: detached
May  9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3 (disconnected)
May  9 10:43:46 alex kernel: ukbd1: detached
-- 
-
Alex.
___
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: freebsd-update: to a specific patch level - help please? [PATCH]

[Derek (freebsd lists)]

On 18-03-24 10:26 AM, Derek wrote:

On 18-03-23 06:44 AM, Kurt Jaeger wrote:

To be clear, *I've included a link to a patch to freebsd-update
in my initial post, and the help I'm looking for: is to get this
functionality added as a feature so others can benefit.*  It
works for me already, and I've already benefited.


Please submit this in a PR, and post the PR number here, I'll 
work to

get this in the tree.



PR is 226893



FYI - Just awaiting any kind of feedback on the PC.  Won't be 
starting anything until then.


Derek
___
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: freebsd-update: to a specific patch level - help please? [PATCH]

[Derek]

On 18-03-23 06:44 AM, Kurt Jaeger wrote:

Hi!


To be clear, *I've included a link to a patch to freebsd-update
in my initial post, and the help I'm looking for: is to get this
functionality added as a feature so others can benefit.*  It
works for me already, and I've already benefited.

(I'm happy to flesh it out, and document it properly, but I'm
very hesitant to spend the time doing it in detail and submitting
a PR if I'm doing this in isolation, and nobody wants it.


Please submit this in a PR, and post the PR number here, I'll work to
get this in the tree.



PR is 226893


Thanks!
Derek
___
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: freebsd-update: to a specific patch level - help please? [PATCH]

[Kurt Jaeger]

Hi!

> To be clear, *I've included a link to a patch to freebsd-update 
> in my initial post, and the help I'm looking for: is to get this 
> functionality added as a feature so others can benefit.*  It 
> works for me already, and I've already benefited.
> 
> (I'm happy to flesh it out, and document it properly, but I'm 
> very hesitant to spend the time doing it in detail and submitting 
> a PR if I'm doing this in isolation, and nobody wants it. 

Please submit this in a PR, and post the PR number here, I'll work to
get this in the tree.

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
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: freebsd-update: to a specific patch level - help please? [PATCH]

[Derek (freebsd lists)]

On 18-03-21 05:24 PM, Rainer Duffner wrote:

Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) <48225...@razorfever.net>:

Hi!

I was surprised when using freebsd-update, that there was no way to specify a 
patch level.


AFAIK, the usual answer to these kinds of requests is: „Run your own 
freebsd-update server“.

Mirroring one of the existing ones is AFAIK neither guaranteed to work nor 
desired by the current „administration“.



Thanks for your thoughts.

To be clear, *I've included a link to a patch to freebsd-update 
in my initial post, and the help I'm looking for: is to get this 
functionality added as a feature so others can benefit.*  It 
works for me already, and I've already benefited.


(I'm happy to flesh it out, and document it properly, but I'm 
very hesitant to spend the time doing it in detail and submitting 
a PR if I'm doing this in isolation, and nobody wants it. 
Perhaps the silence on the thread is already a good indicator of 
the appetite, although I fear it's my ability to sell it or 
myself properly.)


Structurally, "run your own freebsd-update server" is a wasteful 
solution for a single (or much larger set of) default install(s). 
 It makes a lot of sense for custom installations.  For what 
should be the default approach: repeatable - version controlled - 
installations with the support of the FreeBSD project, it would 
seem that having freebsd-update support patch levels would be a 
far more efficient net use of people's time than the alternatives.


(I was debating both running an update server, or running 
"behind" a hacked up mirror as well, and in fact, I feel patching 
freebsd-update was a great investment, for n=1.)



It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see 
packaged base and you can probably mirror those packages and snapshot the 
directory at any point in time.
And/Or it’s just easier to create these base-packages yourselves vs. running 
your own freebsd-update server.



This is a good point, and perhaps why it's not worth putting more 
time into this.


I appreciate your feedback.

Thanks!
Derek

___
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: freebsd-update: to a specific patch level - help please?

[Rainer Duffner]

> Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) 
> <48225...@razorfever.net>:
> 
> Hi!
> 
> I was surprised when using freebsd-update, that there was no way to specify a 
> patch level.



AFAIK, the usual answer to these kinds of requests is: „Run your own 
freebsd-update server“.

Mirroring one of the existing ones is AFAIK neither guaranteed to work nor 
desired by the current „administration“.

I’ve contemplated doing both, but never had enough heart-ache to do it and 
never thought the pay-off would be greater than the potential problems.

It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see 
packaged base and you can probably mirror those packages and snapshot the 
directory at any point in time.
And/Or it’s just easier to create these base-packages yourselves vs. running 
your own freebsd-update server.






___
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-update: to a specific patch level - help please?

[Derek (freebsd lists)]

Hi!

I was surprised when using freebsd-update, that there was no way 
to specify a patch level.


In my day to day, I need to ensure security patches are applied.

I also need to assess the impact of patches, and ensure 
consistency (ie. versions) in my environments.  This can take time.


Here's a story for context, please feel free to skip:

  We are planning to cut our 10.3-RELEASE infrastructure over to 
11.1-RELEASE before the end of the month, because it's EoL in 
April.  We updated and cut over our production load balancer 
March 6th (and patted ourselves on the back for being ahead of 
schedule), and within less than 12 hours, updated our backup load 
balancers.  Unfortunately, we're now on ever so slightly 
different versions (-p6/-p7), and we're not affected by the -p7 
problems.  This makes my eye twitch slightly, especially when -p7 
was the first patch of 2018.


  Now we need to upgrade our application servers, that are 
running our trusted code, and -p8 comes out.


  I'm nervous about just applying -p8, but I definitely want to 
upgrade to 11.1-RELEASE asap.


  After assessing the impact of -p8 on our infrastructure, I 
feel the security risk is relatively low in the short term (and 
we've waited this long anyway), but I feel the probability of 
introducing unintended side-effects is high, and want some time 
to test and asses.


/story

It would seem to me, for repeatable environments, that binary 
updates from FreeBSD that can be pinned to specific version are 
highly desireable.


I've gone ahead and created a patch for my use here:

https://github.com/derekmarcotte/freebsd/commit/009015a7dda5d1f1c46f4706c222614f17fb535c

(there's a 10.3-specific one here:
https://github.com/derekmarcotte/freebsd/commit/458879f36ae984add0ff525fb6c2765fcf1fba67
)

I'd be happy to open a PR, and to iterate and improve on this 
PoC, but if there's no support from the project, I'll keep it to 
myself.


I guess what I'm asking is, for these reasons, is anyone willing 
to work with me (in mentorship+commit bits) to add this feature 
(maybe not this particular implementation) to freebsd-update?


Thanks!
Derek


___
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: need help using ng_patch to modify src/dst packets or alternative way

[Eugene Grosbein]

17.12.2017 17:59, Sami Halabi wrote:

> Hi Eugene,
> I'm looking for a solution for IP traffic. in linux iptables its possible but 
> I couldn't find freebsd way yet.
> bkuncr soulution works for tcp only.

Then, you need to realize that for every packet, you need to change (translate)
both of source IP address from 10.1.1.2 to 1.1.1.1 and destination IP address
from 10.1.1.1 to X.X.X.X. This is called network address translation and,
in fact, you need NAT. But not ordinary "simple" NAT that translates
only source address in outgoing packets (and destination in incoming replies)
but double or "binat" to translate destination address in outgoing packets too
(and source address in corresponding replies).

This is possible to do with two instances of "ipfw nat" (or natd) for single 
external destination
but not for arbitrary number of external destinations.

They say, "pf(4)" packet filter can perform "binat" properly.
I have not tried that. You should start reading its documentation.
___
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: need help using ng_patch to modify src/dst packets or alternative way

[Sami Halabi]

Hi Eugene,
I'm looking for a solution for IP traffic. in linux iptables its possible
but I couldn't find freebsd way yet.
bkuncr soulution works for tcp only.

Thanks for the hint though,

Sami

בתאריך 17 בדצמ׳ 2017 11:29 AM,‏ "Eugene Grosbein" <eu...@grosbein.net> כתב:

> 17.12.2017 14:52, Sami Halabi пишет:
> > hi,
> >
> > Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to
> talk
> > to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip using
> > one of my public IPs say 1.1.1.1.
>
> If you need this just for single or several tcp ports, easiest way
> is to use any of port forwarders/bouncers like this:
>
> pkg install bounce
> bounce -a 10.1.1.1 -b 1.1.1.1 -p 443 X.X.X.X 443
>
>
>
___
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"

need help using ng_patch to modify src/dst packets or alternative way

[Sami Halabi]

hi,

Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to talk
to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip using
one of my public IPs say 1.1.1.1.

I'm trying to modify packets to passthrough to a local IP.
I have a box that a specific IP is routed to it.. say 1.1.1.1
in my bce0 i don't have that ip configured but i have my public IP that say
2.2.2.2 that 1.1.1.1 is routed to it.
i configured 10.1.1.1/24 in bce0, my target box is 10.1.1.2/24.
i tried the following inside ngctl:

mkpeer ipfw: patch 300 in
name ipfw:300 src_dst_chg
msg src_dst_chg: setconfig { count=2 csum_flags=1 ops=[  { mode=1
value=0x0a010101 length=4 offset=3 }  { mode=1 value=0x0a010102 length=4
offset=4 } ] }

in my box(10.1.1.1) i did:
sysctl net.inet.ip.fw.one_pass=0
/sbin/ipfw add 50 netgraph 300 ip from any to any to 1.1.1.1

then i do simple ping from outside box
i see the packets arrive on my 160 rule
but never leaves the box..

I would at least see packeta flow one direction to 10.1.1.2 and then that
need another ipfw and netgraph opposite rule.

If you have alternative way I'm happy to try...


Help much appreciated...
Sami
___
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"