Re: vfs.zfs.min_auto_ashift and OpenZFS

[Ed Maste]

On Sun, 6 Sep 2020 at 22:26, Matthew Macy  wrote:
>
> This long since been fixed. Note that Ryan built working installer images 
> during the CFT.

Yep, thanks for the note and sorry for the false alarm; it was a local
issue and I've closed the PR.
___
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: vfs.zfs.min_auto_ashift and OpenZFS

[Matthew Macy]

On Sun, Sep 6, 2020 at 17:08 Ed Maste  wrote:

> On Fri, 1 May 2020 at 20:20, Matthew Macy  wrote:
>
> >
>
> > OpenZFS doesn't have the same ashift optimization logic that FreeBSD
>
> > has. It's something that needs to be resolved before the code can be
>
> > integrated downstream.
>
>
>
> Note that our installer tries to set the min_auto_ashift when ZFS is
>
> selected - I've submitted PR 249157 to track that.
>
> This long since been fixed. Note that Ryan built working installer images
during the CFT.
-M
___
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: Is pkg site forbidden by brower?

[Mark Linimon]

On Sun, Sep 06, 2020 at 03:05:49PM -0400, Yoshihiro Ota wrote:
> Do you own pkg sites?

Only portmgr@ does that.  So this matter can only be resolved by a
discussion between portmgr@ and clusteradm@.

mcl
___
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: vfs.zfs.min_auto_ashift and OpenZFS

[Ed Maste]

On Fri, 1 May 2020 at 20:20, Matthew Macy  wrote:
>
> OpenZFS doesn't have the same ashift optimization logic that FreeBSD
> has. It's something that needs to be resolved before the code can be
> integrated downstream.

Note that our installer tries to set the min_auto_ashift when ZFS is
selected - I've submitted PR 249157 to track that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Is pkg site forbidden by brower?

[Michael Gmelin]

> On 6. Sep 2020, at 21:09, Yoshihiro Ota  wrote:
> 
> On Sun, 6 Sep 2020 14:47:00 +0200
> Michael Gmelin  wrote:
> 
>> 
>> 
 On 6. Sep 2020, at 12:00, Niclas Zeising  
 wrote:
>>> 
>>> 〓On 2020-09-06 09:00, grarpamp wrote:
> On 9/6/20, Kevin Oberman  wrote:
> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
>> Is "403 Forbidden" an intended response for a brower access to
>> http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
>> 
>> I used to see available packages with a brower and decided which one to
>> use.
 Some more people have noted this change
 as breaking tool scripts, etc.
 And useful meta files are unfortunately now invisible:
 packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig
 If someone want to block the '/.../All/' dir full of pkgs,
 maybe, but do not block any other part of the hier.
>>> 
>>> The reason that folder listing was disabled on the package download sites 
>>> is that it used too
>>> much resources.  For every hit on those URLs, the web server had to 
>>> dynamically generate the
>>> folder listing, and send it.  This caused DDoS-like scenarios, where these 
>>> were hit repeatedly,
>>> which caused problems for legitimate traffic.  Since the relevant 
>>> information is available in
>>> the txz files above, and also on freshports, and since pkg have no need for 
>>> directory listing,
>>> it was disabled.
>>> 
>> 
>> Is this part of why pkg repos are performing so much better recently? I‘m 
>> quite happy about
>> that :)
>> 
>> If there’s a use case for having access to this information, we could simply 
>> provide it through a
>> static index.html that’s recreated every time the directory changes.
>> 
>> Cheers,
>> Michael
> 
> Michael,
> 
> Do you own pkg sites?

Unfortunately not, but you could ask clusteradm@ about that.

Cheers,
Michael

> 
> I like the idea of creating static index.html file as there are modules with 
> version numbers and also modules with multiple version numbers.
> Brower helps to find which versions are available, for example.
> 
> Regards,
> Hiro
> ___
> 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: Is pkg site forbidden by brower?

[Yoshihiro Ota]

On Sun, 6 Sep 2020 14:47:00 +0200
Michael Gmelin  wrote:

> 
> 
> > On 6. Sep 2020, at 12:00, Niclas Zeising  
> > wrote:
> > 
> > 〓On 2020-09-06 09:00, grarpamp wrote:
> >>> On 9/6/20, Kevin Oberman  wrote:
> >>> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
>  Is "403 Forbidden" an intended response for a brower access to
>  http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
>  
>  I used to see available packages with a brower and decided which one to
>  use.
> >> Some more people have noted this change
> >> as breaking tool scripts, etc.
> >> And useful meta files are unfortunately now invisible:
> >> packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig
> >> If someone want to block the '/.../All/' dir full of pkgs,
> >> maybe, but do not block any other part of the hier.
> > 
> > The reason that folder listing was disabled on the package download sites 
> > is that it used too
> > much resources.  For every hit on those URLs, the web server had to 
> > dynamically generate the
> > folder listing, and send it.  This caused DDoS-like scenarios, where these 
> > were hit repeatedly,
> > which caused problems for legitimate traffic.  Since the relevant 
> > information is available in
> > the txz files above, and also on freshports, and since pkg have no need for 
> > directory listing,
> > it was disabled.
> > 
> 
> Is this part of why pkg repos are performing so much better recently? I‘m 
> quite happy about
> that :)
> 
> If there’s a use case for having access to this information, we could simply 
> provide it through a
> static index.html that’s recreated every time the directory changes.
> 
> Cheers,
> Michael

Michael,

Do you own pkg sites?

I like the idea of creating static index.html file as there are modules with 
version numbers and also modules with multiple version numbers.
Brower helps to find which versions are available, for example.

Regards,
Hiro
___
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: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[marco]

On Sun, Sep 06, 2020 at 11:58:23AM -0400, you (Ryan Moeller) sent the following 
to [freebsd-current] :
> 
> 
> The git hashes are the most unambiguous way to see what you have. The 
> svn log shows the last vendor update for zfs brought it to fd20a81b, and 
> the most recent version of the port is at 6fe3498ca.
> 
> For the port I have hijacked zfs --version to show the git hash in the 
> version string, but the base zfs does not do this, so it is not as easy 
> to determine at runtime there.

Nice, wasn't aware the port supported zfs --version to show the git hashes.
Would definitely be nice for base ZFS to also support it at runtime.

-- 
Marco van Lienen -- FreeBSD enthusiast
https://keybase.io/scarcry , GnuPG id: 8580E6CB
"The Tuck Pendleton machine...zero defects."
___
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: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[Ryan Moeller]

On 9/6/20 11:49 AM, marco wrote:

On Sun, Sep 06, 2020 at 10:22:33AM -0400, you (Ryan Moeller) sent the following 
to [freebsd-current] :

I switched back to base ZFS whilst on r364030 and upgraded to r365336 and 
deinstalled
openzfs and openzfs-kmod for now.
ZFS in base nicely auto-imported both zroot and backup pools for the 1st
time.

I need to update the port, it's a little behind what's in base now.

Thanks Ryan

How does one verify which version of OpenZFS is actually in base?
sysutils/openzfs{-kmod} has/have 20200821, UPDATING has the 20200824 listing.
I can't find any version reference of OpenZFS in base from svn log
either.



The git hashes are the most unambiguous way to see what you have. The 
svn log shows the last vendor update for zfs brought it to fd20a81b, and 
the most recent version of the port is at 6fe3498ca.


For the port I have hijacked zfs --version to show the git hash in the 
version string, but the base zfs does not do this, so it is not as easy 
to determine at runtime there.


-Ryan

___
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: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[marco]

On Sun, Sep 06, 2020 at 10:22:33AM -0400, you (Ryan Moeller) sent the following 
to [freebsd-current] :
> 
> > I switched back to base ZFS whilst on r364030 and upgraded to r365336 and 
> > deinstalled
> > openzfs and openzfs-kmod for now.
> > ZFS in base nicely auto-imported both zroot and backup pools for the 1st
> > time.
> 
> I need to update the port, it's a little behind what's in base now.

Thanks Ryan

How does one verify which version of OpenZFS is actually in base?
sysutils/openzfs{-kmod} has/have 20200821, UPDATING has the 20200824 listing.
I can't find any version reference of OpenZFS in base from svn log
either.

-- 
Marco van Lienen -- FreeBSD enthusiast
https://keybase.io/scarcry , GnuPG id: 8580E6CB
"The Tuck Pendleton machine...zero defects."
___
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: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[Ryan Moeller]

On 9/6/20 5:16 AM, marco wrote:

On Sat, Sep 05, 2020 at 12:02:58AM +0100, you (Graham Perrin) sent the 
following to [freebsd-current] :

FYI 


I switched back to base ZFS whilst on r364030 and upgraded to r365336 and 
deinstalled
openzfs and openzfs-kmod for now.
ZFS in base nicely auto-imported both zroot and backup pools for the 1st
time.


I need to update the port, it's a little behind what's in base now.

-Ryan

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

DRM Report 2020-08-31

[Emmanuel Vadot]

 Hello all,

 Time for a report on DRM progress.

 I've updated the drm-devel-ports to be in sync (minus a few patches)
to Linux v5.4.62, the latest LTS release.
 The Linux default for PSR (Panel Self Refresh) and Power Well was
modified for FreeBSD, meaning that PSR is always off and power well is
always on. Both defaults don't work well on FreeBSD, the PSR issue is
the biggest one as when activated on certain hardware the console only
refresh every 30 seconds or so and since I don't have the hardware to
reproduce the issue it's better to just switch it off for now. The
power well issue manifest when using an hdmi monitor, this cause a
large numbers of message to be printed on the console and also on
certain hardware hdmi audio won't come back after display is put to
sleep. Both issues are likely due to some missing pieces in the
LinuxKPI framework but I'm unsure which for now.
 I think that it's almost time to have drm-devel-kmod content put in
drm-current-kmod, I plan to open a review during next week.

 I'm still working on making live usb image that will automate a lot of
test and generate a report that users can paste directly on a wiki page
but in the mean time I've generated two images for users to test the
current state of affairs of drm drivers on their hardware without
needing to install freebsd current + packages etc ...

 This first one is just FreeBSD current + ports head.
 The only customization on the ports are the VAAPI and VDPAU option to
graphics/mesa-dri.

 The second one contains modification to the base tree and the
drm-devel-ports to have the backlight subsystem built
(https://reviews.freebsd.org/D26250 and child revisions).
 The TLDR on backlight is that you don't need acpi_video or
intel-backlight to control your screen backlight anymore, simply use
backlight(8). This should work on all Intel or AMD laptops while other
ways (acpi_video or intel-backlight) don't always works. I intend to
commit this next week.
 The -devel image also have hw.amdgpu.exp_hw_support set to 1 so users
of Renoir GPU might have a chance that it works.
 It also have mesa 20.2-rc4 which is needed for AMD Navi and Renoir.

 Both images autoload i915kms and amdgpu at startup, this cause
problems on Intel machine with an AMD discret gpu and I will look into
this during next week (only found out this weekend when testing on one
of my laptop that have such a configuration).

 They also contains two short video files (ten seconds of Big Buck
Bunny in 2016p and native resolution) that could be used to test that
gpu decoding is working (both mpv and vlc are included in this image).

 The root user don't have a password and there is a 'freebsd' user
without password too.
 For Xorg users only twm is included, for Wayland users sway is
included. Both X and Wayland work out of the box by either typing
'startx' or 'sway' at the console.

 Both glxinfo/glxgears and vkcube-xlib

 There is NO NVidia drivers, we don't have nouveau ported and the
NVidia drivers have their own DRM implementation so I'm not interested
in it.

 As a reminder :

 The i915kms driver support up to Ice Lake/Gen 11 (maybe Tiger Lake but
I don't think that hardware is out yet).
 The amdgpu driver supports every GCN-based architectures, from
Southern Island (Radeon HD 7000) to Navi (RX 5000). And Renoir is
experimental in 5.4 so it need hw.amdgpu.exp_hw_support to be set to 1
at loader prompt or in loader.conf.
 The radeonkms supports older (<2012, up to Northern Island/HD 5000)
AMD/ATI GPUs.

 Links for the images :
 http://wopr.blih.net/drm-live-20200906.img.xz
 http://wopr.blih.net/drm-live-devel-20200906.img.xz

 They are both ~500MB compressed and 3GB uncompressed (with ~400MB free
on the disk if you want to install more packages).
 I'll post the receipe for building them next week after a cleanup.

 glxinfo and glxgears are present to test gpu acceleration and
vkcube-xlib/vkcube-wayland to test Vulkan.

 What I'm most interested in the result of testing this image is kernel
panic at boot or unsupported hardware (relevant hardware so >= 2012).
In that case a issue at https://github.com/freebsd/drm-kmod/ would be
the best thing to do.

 I'm also interested in AMD users telling me if they use the
mesa-dri option VDPAU, I can't make it work with my system (but mpv
-vo=gpu works perfectly).

-- 
Emmanuel Vadot 
___
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: Is pkg site forbidden by brower?

[Michael Gmelin]

> On 6. Sep 2020, at 12:00, Niclas Zeising  wrote:
> 
> On 2020-09-06 09:00, grarpamp wrote:
>>> On 9/6/20, Kevin Oberman  wrote:
>>> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
 Is "403 Forbidden" an intended response for a brower access to
 http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
 
 I used to see available packages with a brower and decided which one to
 use.
>> Some more people have noted this change
>> as breaking tool scripts, etc.
>> And useful meta files are unfortunately now invisible:
>> packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig
>> If someone want to block the '/.../All/' dir full of pkgs,
>> maybe, but do not block any other part of the hier.
> 
> The reason that folder listing was disabled on the package download sites is 
> that it used too much resources.  For every hit on those URLs, the web server 
> had to dynamically generate the folder listing, and send it.  This caused 
> DDoS-like scenarios, where these were hit repeatedly, which caused problems 
> for legitimate traffic.  Since the relevant information is available in the 
> txz files above, and also on freshports, and since pkg have no need for 
> directory listing, it was disabled.
> 

Is this part of why pkg repos are performing so much better recently? I‘m quite 
happy about that :)

If there’s a use case for having access to this information, we could simply 
provide it through a static index.html that’s recreated every time the 
directory changes.

Cheers,
Michael


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

Re: Is pkg site forbidden by brower?

[Niclas Zeising]

On 2020-09-06 09:00, grarpamp wrote:

On 9/6/20, Kevin Oberman  wrote:

On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:

Is "403 Forbidden" an intended response for a brower access to
http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?

I used to see available packages with a brower and decided which one to
use.


Some more people have noted this change
as breaking tool scripts, etc.

And useful meta files are unfortunately now invisible:
packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig

If someone want to block the '/.../All/' dir full of pkgs,
maybe, but do not block any other part of the hier.


The reason that folder listing was disabled on the package download 
sites is that it used too much resources.  For every hit on those URLs, 
the web server had to dynamically generate the folder listing, and send 
it.  This caused DDoS-like scenarios, where these were hit repeatedly, 
which caused problems for legitimate traffic.  Since the relevant 
information is available in the txz files above, and also on freshports, 
and since pkg have no need for directory listing, it was disabled.


I would suggest using freshports.org, which has information on which 
version of a package is available for the various FreeBSD versions and 
architectures, both in the latest and the quarterly branch.





How can I find distributions like "latest", "release_X", etc?


Yes, there does not appear to be any docs enumerating all
the available live names for use in PACKAGESITE url.
Reopening the above dirs would be self documenting.


I am not sure what you are looking for here.  Can you explain the use 
case, what are you trying to accomplish?




The name for the term in  position of /${ABI}//All/...
might be "REPOSITORY_ROOT" or "repo-path" or simply "repository",
but it does not seem defined for users in pkg or pkg.conf manpages.
"distribution" is unlikely the correct term, "branch" might be
a useful connotation regarding ports source tree.


Once again, I'm not sure what you are looking for.  Have you looked at 
the manual for pkg.conf, which is fairly extensive and have several 
examples.





Does https://pkg-status.freebsd.org/builds?jailname=121amd64 have what you
want?


Those names don't correspond 1:1 to anything on pkg.freebsd.org.


Actually, they do. You can see both the ports tree built (default for 
top of the ports tree, and quarterly for the quarterly branch), as well 
as architecture and FreeBSD version.  You can even see exactly which svn 
revision is used.





I can't believe that there is no way to see a log of failed builds,
but I can only see the new failures and no information on previous builds.


Pkg buildlogs are a separate issue.
They should be available for browsing, same as kernel, base...


Build logs are available, but not all of them are available over IPv4, 
since IPv4 addresses are scarce.  If you open a specific builder, you 
can see a list of new failures, and links to the build logs.  There are 
also links to previous builds, so that you can compare, and find earlier 
failures.


Regards
--
Niclas
___
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: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[marco]

On Sat, Sep 05, 2020 at 12:02:58AM +0100, you (Graham Perrin) sent the 
following to [freebsd-current] :
> >
> FYI 
> 

I switched back to base ZFS whilst on r364030 and upgraded to r365336 and 
deinstalled
openzfs and openzfs-kmod for now.
ZFS in base nicely auto-imported both zroot and backup pools for the 1st
time.

-- 
Marco van Lienen -- FreeBSD enthusiast
https://keybase.io/scarcry , GnuPG id: 8580E6CB
"The Tuck Pendleton machine...zero defects."
___
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: Fatal trap 18 on boot after OpenZFS import

[Tomoaki AOKI]

Filed PR.
Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import

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


On Fri, 4 Sep 2020 22:03:01 +0900
Tomoaki AOKI  wrote:

> Hi.
> 
> Encountering boot failure with fatal trap 18 on boot,
> happening at (maybe) just before init() starts. Possibly on
> root remount by kernel or zpool import by rc.d script.
> The last revision tried is r365316 (r364788 is the last tried
> clean rebuild).
> 
> The last health revision is r364744, just before actual switch
> to OpenZFS. amd64 on ThinkPad P52 (Core i7-8750H) w/descrete nvidia GPU.
> 
> r364751 with diff of r364777 and r364788 (to successfully built
> Without unrelated-to-OpenZFS changes) fails.
> 
> Any suggestions and fixes are appreciated.
> 
> 
> Trap screen is something like below (text attached),
> typed up from relatively clear photo, so could be some typo.
> 
> This is shown just after usual kernel startup outputs.
> boot1.efi (as EFI/bootx64.efi on ESP) starts /boot/loader.efi
> properly, and loader.efi seems to boot kernel properly.
> 
> As even single user shell selection doesn't appear, loader.efi
> is of r364744. But they works even if I proceeded irregular
> process,
> 
>   1)Update src tree
>   2)Clean obj tree
>   3)buildworld
>   4)etcupdate -p
>   5)buildkernel
>   6)installkernel
>   7)shutdown to single user WITHOUT reboot  <- Irregular!
>   8)installworld
>   9)etcupdate
>  10)rebuild src/sys-dependent ports (kmods, nvidia-driver, ...)
>  11)reboot
> 
> loader.efi looks doing its job and panics after kernel startup ends.
> Needless to say, rolling back to r364744 state from stable/12 on nvd0
> Fixes the issue.
> 
> Regards.
> 
> =
> 
> Fatal trap 18: integer divide fault while in kernel mode
> cpuid = 2; apic id = 02
> instruction pointer = 0x20:0x82bfa320
> stack pointer   = 0x28:0xfe00e20c6900
> frame pointer   = 0x28:0xfe00e20c6960
> 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 = 27 (vdev_open)
> trap number = 18
> panic: integer divide fault
> cpuid = 2
> time = 16
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe00e20c6610 vpanic() at vpanic+0x182/frame fe00e20c6660
> panic() at panic+0x43/frame fe00e20c66c0
> trap_fatal() at trap_fatal+0x387/frame fe00e20c6720
> trap() at trap+0x8e/frame fe00e20c6830
> calltrap() at calltrap+0x8/frame fe00e20c6830
> --- trap 0x12, rip = 0x82bfa320, rsp = 0xfe00e20c6900, rbp
> = 0xfe00e20c6960 --- zio_wait() at zio_wait+0x60/frame
> 0xfe00e20c6960 vdev_open() at vdev_open+0x74d/frame
> 0xfe00e20c69c0 vdev_open_child() at vdev_open_child+0x1e/frame
> 0xfe00e20c69e0 taskq_run() at taskq_run+0x1f/frame
> 0xfe00e20c6a00 taskqueue_run_locked() at
> taskqueue_run_locked+0x181/frame 0xfe00e20c6a80
> taskqueue_thread_loop() at taskqueue_thread_loop+0x118/frame
> 0xfe00e20c6ab0 fork_exit() at fork_exit+0x7d/frame
> 0xfe00e20c6af0 fork_trampoline() at fork_trampoline+0xe/frame
> 0xfe00e20c6af0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 27 tid 100570 ]
> Stopped at  kdb_enter+0x37: movq$0,0x1091556(%rip)
> db> 
> 
> =
> 
> Additional info:
>  *Clean build with killing CPUTYPE from command line and
>   make.conf (so should be equivalent with nocona) didn't help.
> 
>  *Clean build with commenting out WITH_KERNEL_RETPOLINE line
>   and WITH_RETPOLINE line in src.conf didn't help.
> 
>  *Combination of the above two didn't help, too (at r364788).
> 
>  *There are two root pools in different physical drive.
>   stable/12 on nvd0 (primary) and head on ada0 (secondary).
> 
>  *GENERIC-NODEBUG based (added options CAM_IOSCHED_DYNAMIC)
>   kernel.
> 
> -- 
> Tomoaki AOKI


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

Re: Is pkg site forbidden by brower?

[grarpamp]

On 9/6/20, Kevin Oberman  wrote:
> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
>> Is "403 Forbidden" an intended response for a brower access to
>> http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
>>
>> I used to see available packages with a brower and decided which one to
>> use.

Some more people have noted this change
as breaking tool scripts, etc.

And useful meta files are unfortunately now invisible:
packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig

If someone want to block the '/.../All/' dir full of pkgs,
maybe, but do not block any other part of the hier.

>> How can I find distributions like "latest", "release_X", etc?

Yes, there does not appear to be any docs enumerating all
the available live names for use in PACKAGESITE url.
Reopening the above dirs would be self documenting.

The name for the term in  position of /${ABI}//All/...
might be "REPOSITORY_ROOT" or "repo-path" or simply "repository",
but it does not seem defined for users in pkg or pkg.conf manpages.
"distribution" is unlikely the correct term, "branch" might be
a useful connotation regarding ports source tree.

> Does https://pkg-status.freebsd.org/builds?jailname=121amd64 have what you
> want?

Those names don't correspond 1:1 to anything on pkg.freebsd.org.

> I can't believe that there is no way to see a log of failed builds,
> but I can only see the new failures and no information on previous builds.

Pkg buildlogs are a separate issue.
They should be available for browsing, same as kernel, base...
___
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"