Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Hi Andrey, With your patch applied I don't have the symptoms of 'hanging' tcp connections anymore. Thanks for looking into it. Regards, Ronald. *Van:* "Andrey V. Elsukov" *Datum:* donderdag, 12 december 2024 09:53 *Aan:* freebsd-current@freebsd.org *Onderwerp:* R

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On 11.12.2024 16:25, Ronald Klop wrote: I did a bisect of commits and my finding is that commit 347dd053 on 2024-11-29 is the cause. "tcp: add TH_AE capabilities to ppp and pf" https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9 The commit before (0fc7bdc978)

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop wrote: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > > > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I firs

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Am Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop schrieb: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > > > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Op 09-12-2024 om 19:24 schreef Juraj Lutter: On 9 Dec 2024, at 19:19, FreeBSD User wrote: Am Tue, 10 Dec 2024 02:27:10 +0900 Tomoaki AOKI schrieb: My apology for topposting. The host I first realised the problems is updated on an almost daily basis and the issue reported started last wee

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > > Am Tue, 10 Dec 2024 02:27:10 +0900 > Tomoaki AOKI schrieb: > > My apology for topposting. > > The host I first realised the problems is updated on an almost daily basis > and the issue > reported started last weekend. > > A possible candi

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Mon, 9 Dec 2024 17:45:14 +0100 FreeBSD User wrote: > Am Mon, 9 Dec 2024 21:43:14 +0900 > Tomoaki AOKI schrieb: > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > Juraj Lutter wrote: > > > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > > > Hi, > > > > > > > > I can reproduce your

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Am Mon, 9 Dec 2024 21:43:14 +0900 Tomoaki AOKI schrieb: > On Mon, 9 Dec 2024 11:09:14 +0100 > Juraj Lutter wrote: > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > Hi, > > > > > > I can reproduce your error. > > > > > > A cronjob which does a scp to another server didn't work

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Mon, 9 Dec 2024 11:09:14 +0100 Juraj Lutter wrote: > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > Hi, > > > > I can reproduce your error. > > > > A cronjob which does a scp to another server didn't work anymore. When I go > > back to the previous BE it works fine again. > > Ipfw

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

> On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > Hi, > > I can reproduce your error. > > A cronjob which does a scp to another server didn't work anymore. When I go > back to the previous BE it works fine again. > Ipfw disable firewall also makes the scp work. > > Scp also seems to work f

(ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

enabled=0 security.mac.ipacl.ipv6=0 security.mac.ipacl.ipv4=0 # net.bpf.optimize_writers=1 # net.inet.ip.fw.verbose=1 #net.inet.ip.fw.verbose_limit=10 net.inet.ip.fw.dyn_keep_states=1 Van: FreeBSD User Datum: 6 december 2024 03:47 Aan: freebsd-current@freebsd.org, freebsd-i...@freebsd.org Onderwerp: Re: HELP! fetch

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

dyn_keep_states=1 > > Van: FreeBSD User > Datum: 6 december 2024 03:47 > Aan: freebsd-current@freebsd.org, freebsd-i...@freebsd.org > Onderwerp: Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv > failure: > Operation timed out > > > > >

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Might be useful to share your ipfw config. Van: FreeBSD User Datum: 6 december 2024 03:47 Aan: freebsd-current@freebsd.org, freebsd-i...@freebsd.org Onderwerp: Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Am Thu, 5 Dec 2024 17:33:54 +0100

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Thu, 5 Dec 2024 16:55:00 +0100 Daniel Tameling wrote: > On Thu, Dec 05, 2024 at 11:51:03AM +0100, FreeBSD User wrote: > > On Wed, 04 Dec 2024 17:20:39 + > > "Dave Cottlehuber" wrote: > > > > Thank you very much for responding! > > > > > On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Thu, Dec 05, 2024 at 11:51:03AM +0100, FreeBSD User wrote: > On Wed, 04 Dec 2024 17:20:39 + > "Dave Cottlehuber" wrote: > > Thank you very much for responding! > > > On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote: > > > On most recent CURRENT (on some boxes of ours, not all) fetch/git s

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Wed, 04 Dec 2024 17:20:39 + "Dave Cottlehuber" wrote: Thank you very much for responding! > On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote: > > On most recent CURRENT (on some boxes of ours, not all) fetch/git seem > > to be stuck > > forever fetching tarballs from ports, fetching Emai

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote: > On most recent CURRENT (on some boxes of ours, not all) fetch/git seem > to be stuck > forever fetching tarballs from ports, fetching Emails via claws-mail > (TLS), opening > websites via librewolf and firefox or pulling repositories via git. >

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

In short, I do not know the reason; only noting that had seen earlier. Recreating from https://lists.freebsd.org/archives/freebsd-current/2024-December/006778.html ... On 20241203, FreeBSD User wrote ... CURRENT: FreeBSD 15.0-CURRENT #1 main-n273978-b5a8abe9502e: Mon Dec 2 23:11:07 CET 2024 a

HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On most recent CURRENT (on some boxes of ours, not all) fetch/git seem to be stuck forever fetching tarballs from ports, fetching Emails via claws-mail (TLS), opening websites via librewolf and firefox or pulling repositories via git. CURRENT: FreeBSD 15.0-CURRENT #1 main-n273978-b5a8abe9502e: M

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

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

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

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

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

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

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

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'

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

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

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

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

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

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 o

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

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 unde

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

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

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

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

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

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 pk

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

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

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

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

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

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

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 upda

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

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 minima

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

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.

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

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 testin

Realtek rtw89 - in main - help request (fwd)

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

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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:

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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 handle

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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}@RE

Re: ZFS PANIC: HELP.

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 -

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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 dat

Re: ZFS PANIC: HELP.

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 eve

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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 an

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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 >

Re: ZFS PANIC: HELP.

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.

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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 he

Re: ZFS PANIC: HELP.

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 asser

Re: ZFS PANIC: HELP.

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 mo

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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

Re: ZFS PANIC: HELP.

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.

Re: ZFS PANIC: HELP.

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 t

Re: ZFS PANIC: HELP.

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.

'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

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

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

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.

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

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 s

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

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 i

Help wanted: volunteer yourselves in .github/CODEOWNERS

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

boot loader menu help missing "menu" option

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

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

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

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

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

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,

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

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 fo

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

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

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

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

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

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 handli

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

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

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

uot;, > > 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 sa

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

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

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

> 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

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

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

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

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 n

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

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/

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

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

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

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

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

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.

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

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

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

iple 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

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

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

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

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:

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

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

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

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

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

-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

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

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,

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

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

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

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

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

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), w

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

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 mo

  1   2   3   4   5   6   7   8   9   10   >