kernel boot.
>
> As workaround I already have kld_list+="uhid" in /etc/rc.conf. But IMHO
> it some regression.
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
that
usb devices was not detected at this time.
Anyone experience it?
Thanks
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Working fine!
Thanks for fast fix.
Justin Hibbits escreveu (sexta, 17/05/2024 à(s)
13:57):
> On Fri, 17 May 2024 11:09:00 +0100
> Nuno Teixeira wrote:
>
> > Hello,
> >
> > tpm kernel module fails to load starting on main from May 9.
> > Updated today and same
for bhyve/Win11.
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
t dialog uses --mixedform, and restarts the script on
> > error, which it looks like is what you observe.
>
> Thanks for pointing that out, Jessica. I'll wait for the next 15
> snapshot and will check.
>
> I'm not sure about a good way to test it on a running system instead.
>
> --
> Renato Botelho
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
!
Dimitry Andric escreveu (terça, 30/04/2024 à(s) 18:45):
> On 30 Apr 2024, at 14:26, Nuno Teixeira wrote:
> >
> > I'm lost on build failure of audio/amsynth (updated to version 1.13.3)
> on recent main.
> > Thre strange thing is if I use llvm from ports, USES+=llvm, it fail
__fs
{ namespace filesystem {
|
^
mv -f src/.deps/amsynth-AudioOutput.Tpo src/.deps/amsynth-AudioOutput.Po
1 error generated.
---
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
Backup server is https://www.rsync.net/ (free 500GB for FreeBSD
developers).
Nuno Teixeira escreveu (quarta, 10/04/2024 à(s)
13:39):
> With base stack I can complete restic check successfully
> downloading/reading/checking all files from a "big" remote compressed
>
ing backup to check its
integrity.
Maybe someone could do a restic test to check if this is reproducible.
Thanks,
escreveu (quarta, 10/04/2024 à(s) 13:12):
>
>
> > On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
> >
> > Hello all,
> >
> > @ current 1500018
: connection lost
Connection continues UP.
Cheers,
escreveu (quinta, 28/03/2024 à(s) 15:53):
> > On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
> >
> > Hello all!
> >
> > Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
> (amd64)!
&g
(...)
initial_turbo
https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking
Nuno Teixeira escreveu (domingo, 31/03/2024 à(s)
19:59):
> Hello,
>
> If you got a fan in your rpi4 box, you could try to overclock it.
> If not, there is a funcionality i
ncreasing some of the USB timings (hw.usb.timings.*) but
> this didn't seem to have any effect. is there anything else i could try
> that might affect this, or is this perhaps a known issue?
>
> thanks, lexi.
>
--
Nuno Teixeira
FreeBSD Committer (ports)
be the right tool for this, but I'm super unfamiliar
> with
> > > > > them, and I can't find any docs on them.
> > > > >
> > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent
> to
> > > > > what's happening here?
> > >
* rack 38
---
It would be so nice that we can have a sysctl tunnable for this patch
so we could do more tests without recompiling kernel.
Thanks all!
Really happy here :)
Cheers,
Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) 20:26
() routine from
> userret(), in order to avoid tons of timer interrupts and context switches.
> To test this theory, you could apply a patch like:
It's affecting overall system performance, bonnie was just a way to
get some numbers to compare.
Tomorrow I will test patch.
Thanks!
--
tl.
> I have CCed Drew and Randall, who know much more about HPTS and might have
> follow up questions. I'll bring the issue up in the FreeBSD transport call
> next Thursday.
>
> What hardware are you using?
Laptop:
Legion 5-15IMH05 (Lenovo) - Type 82AU
Thanks!
--
Nuno Teixeira
FreeBSD Committer (ports)
eel the entire OS is
being slow, without errors, just slow.
- Approx. results as test [2]
Nuno Teixeira
FreeBSD Committer (ports)
2982us 338us3072us1135us 591us3236us
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
te to bring
the rack stack with all its fixes in.
Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
--
Nuno Teixeira
FreeBSD Committer (ports)
, used by RACK and BBR.
As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
tcphpts.ko as I am seing in my rpi4 right now.
I'm testing it and check its performance.
I will test again on my amd64 laptop and run more tests too.
--
Nuno Teixeira
FreeBSD Committer (ports)
IC that could lead to my slow
opearations problem
> options TCP_RACK
Don't think I need this one as I will use kernel module instead of
building it in kernel.
Resuming I only need to add:
options TCPHPTS
Is this correct?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
(sábado, 16/03/2024 à(s) 09:40):
>
> On Sat, 16 Mar 2024 09:41:13 +0100
> tue...@freebsd.org wrote:
>
> > > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
> > >
> > > Hello all,
> > >
> > > On a laptop i7/16MB ram, desktop use and port t
Followed man tcp_rack:
loader.conf:
tcp_rack_load="YES"
sysctl.conf:
net.inet.tcp.functions_default=rack
poudriere have restricted access to network, usually for fetch distfiles.
escreveu (sábado, 16/03/2024 à(s) 08:41):
>
> > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote
of option.
> >
> > It's not a typo, both spellings work, cf. config(5).
> Thank you very much for the hint. I did not know this. I wrote
> option in the article (for whatever reason) and tested the
> configs using options...
>
> Best regards
> Michael
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@freebsd.org
>
--
Nuno Teixeira
FreeBSD Committer (ports)
; RACK stack.
>
> Please let me know if you have any questions.
>
> Best regards
> Michael
>
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
ill continue to
> find headers there that should be found in
> $STAGE_ROOT/common/usr/include and thus revert Makefile.depend changes.
> We added a mechanism to allow triggering auto-clean of stage tree when such
> changes are made.
>
> --sjg
>
--
Nuno Teixeira
FreeBSD Committer (ports)
(...)
-ansi == Same as -std=c89
So it seems correct to remove it when -std=c99 is used.
Nuno Teixeira escreveu no dia sexta, 29/12/2023 à(s)
12:03:
>
>
>
> I think we have two options:
>> 1. Build the ports with a C version of at least C99.
>>
>
> - Adding U
l"
Fix build.
Notes:
Adding USE_CSTD=c99 doesn't fix build by itself like we seen on some ports
that were fixed by it.
Something have changed from current 157 to 158.
> 2. Remove the inline from tcp_[gs]et_flags().
>
> Best regards
> Michael
> > --
&g
et/tcp.h:88:8: error: unknown type name 'inline'
88 | static inline void
|^
3 errors generated.
###
Any clues?
--
Nuno Teixeira
FreeBSD Committer (ports)
Dec 2023, at 13:22, Nuno Teixeira wrote:
> >
> > On every current upgrade I update efi/freebsd/loader.efi (amd64) and
> efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi.
> > For safety reasons I always have a copy of last running loader by
> appending &quo
if needed.
Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi
-> /boot/loader.efi ?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello all,
Maybe not the best mailing to ask it but...
How do you update BIOS without Windows since most brands only have bios
software to windows?
I'm about to buy a new pc without windows license and I'm looking for
brands that have bios-cli that work in FreeBSD.
Thanks,
--
Nuno Teixeira
esystem state for clean... done
---
Thanks!
Nuno Teixeira escreveu no dia sábado, 14/10/2023 à(s)
12:22:
> Hello all,
>
> I did try updating BETA1 -> BETA2, BETA2 -> BETA3, ..., BETA5 -> RC1 in
> poudriere:
>
> `poudriere jail -u -j JAIL -t 14.0-RC1`
>
> All f
o install the downloaded upgrades, run
"/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK install".
Installing updates... done.
No updates are available to install.
Run '/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK fetch' first.
[00:11:17] Error: Fail to upgrade system
---
Any clues?
Thanks,
here:
>
> https://people.freebsd.org/~pi/logs/pou-fail.txt
> (short, only 1550 bytes)
>
> I have:
>
> 140 14.0-BETA2 amd64 http2023-09-16 08:20:01 /pou/jails/140
>
> with
>
> /usr/local/bin/poudriere installed by package
> poudriere-devel-3.3.99.20220831
>
> --
> p...@freebsd.org +49 171 3101372 Now what ?
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
==
>
> begin hostapd-wlan0.conf
> interface=wlan0
> ctrl_interface=/var/run/hostapd-wlan0
> ctrl_interface_group=wheel
> ssid=[redacted]
> wpa=2
> wpa_passphrase=[redacted]
> wpa_key_mgmt=WPA-PSK
> wpa_pairwise=CCMP
> end hostapd-wlan0.conf
>
&
domingo, 2/07/2023
à(s) 08:57:
> On Sun, 02 Jul 2023 14:41:55 +0900 (JST)
> Yasuhiro Kimura wrote:
>
> > From: Nuno Teixeira
> > Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required
> by "pkg" and others
> > Date: Sun, 2 Jul 2023 0
à(s)
09:15:
> Nuno Teixeira wrote on
> Date: Sun, 02 Jul 2023 05:22:48 UTC :
>
> > I'm returning to current and installed from
> > 20230622-b95d2237af40-263748-bootonly.iso
> > <
> https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-CU
t days with llvm15->llvm16,
openssl3, etc.
My question is when can I do a delete-old{-libs}?
I'm thinking building pkgs with a updated current on poudriere and then
clean up libs?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
(...)
Trying :
`zpool set feature@block_cloning=disabled zroot`:
cannot set property for 'zroot': property 'feature@block_cloning' can only
be set to 'disabled' at creation time
Nuno Teixeira escreveu no dia quarta, 12/04/2023 à(s)
13:57:
> Hello all,
>
> at current 3fdb40d1befe a
t; present
> > .=
> > >
> > > >>>>>=20
> > > >>>>> I rememeber now really scraed that there was a HEADSUP in the
> list re
> > g=
> > > ard
> > > >>> ing
> > > >>>>> some serious ZFS
> > > >>>>> problems - I didn't find it right now.
> > > >>>>>=20
> > > >>>>> Thanks in advance,
> > > >>>>>=20
> > > >>>=20
> > > >>> That's fallout from the new block cloning feature, adding the
> author
> > > >>>=20
> > > >>=20
> > > >> Thanks.
> > > >>=20
> > > >> As of this moment, all systems with the newest kernel and the new
> ZFS op
> > t=
> > > ion=20
> > > >> enabled, crash -
> > > >> the reason is mostly in different ZFS datasets. I guess there is
> no way
> > b
> > > =
> > > ack
> > > >> once this faulty
> > > >> option is enabled?
> > > >=20
> > > > I've run a test on a scratch pool here, first without
> block_cloning=20
> > > > enabled, then with. There was no corruption when block_cloning was=20
> > > > disabled. There was corruption when block_cloning was enabled.
> > > >=20
> > > > I don't know of any way to revert back nor is there any way to fix
> or=20
> > > > recover the corrupted blocks.
> > >
> > > Is the corruption still present after EXDEV fixes?
> >
> > Yes and no.
> >
> > Yes, there is corruption when block_cloning is enabled.
> >
> > There is no corruption when block_cloning is disabled.
>
> I should add some detail to this.
>
> The corruption experienced when block cloning is disabled was fixed by:
>
> - eb1feadc201a
> - e2d997d1cbb9
> - d012836fb616 (specifically this commit)
> - 20be1b4fc4b7
>
> When block_cloning is enabled, the pool is corrupted. This has not been
> fixed.
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: https://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> e^(i*pi)+1=0
>
>
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
Fixed at
https://cgit.freebsd.org/ports/commit/?id=fb22e1c2e3653558065ffa0509c3c020834723db
Thanks all,
Nuno Teixeira escreveu no dia sexta, 24/03/2023 à(s)
11:15:
> I'm thinking in the best plan to patch port.
> What about patch it for OSVERSION < 14 that will fix 12 and 13 and wh
swap.h, it was a minefield of what can or can't be defined in the
> face
> of existing use.
>
> Warner
>
>
>> A+
>>
>> Paul
>>
>>
>>
>>
>>
--
Nuno Teixeira
FreeBSD Committer (ports)
. You could likely put that into the
> port.
>
> In releng/13 there is also infiniband/byteswap.h that does:
>
> #include
> #include
>
> #define bswap_16bswap16
> #define bswap_32bswap32
> #define bswap_64bswap64
>
> otis
>
> —
> Juraj Lutter
> o...@freebsd.org
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
t; On Fri, Mar 24, 2023, 9:23 AM Nuno Teixeira wrote:
>
>> Hello all,
>>
>> I'm getting a file not found on 12 and 13 compiling net/sflowtool latest
>> update:
>> It compile fine on 14.
>>
>> I've searched 14 src and found:
>> ---
>> ./in
l.c
sflowtool.c:32:10: fatal error: 'byteswap.h' file not found
#include
^~~~
1 error generated.
*** [sflowtool.o] Error code 1
---
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello Gary,
Thanks for the hint, I will try it.
I've forgot to mention a PR about it:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263620
Thanks,
Gary Jennejohn escreveu no dia terça, 7/03/2023 à(s) 15:11:
> On Tue, 7 Mar 2023 13:47:53 +
> Nuno Teixeira wrote:
>
>
all reinstall
===> Creating some important subdirectories
===> Starting chrooted make in /tmp/beinstall.6sMgsC/mnt...
cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
directory
make: don't know how to make deinstall. Stop
---
Any hints?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
hex filename
22977071 1848409 4437760 29263240 0x1be8588 kernel.full
cd: /usr/ports/graphics/drm-kmod: No such file or directory
---
Any hint?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Sorry, wrong post!
Nuno Teixeira escreveu no dia quarta, 2/11/2022 à(s)
21:44:
> Hello,
>
> From
> https://lists.freebsd.org/archives/freebsd-ports/2022-August/002476.html
>
> ---
> With both FLANG and MLIR:
> (...)
> [13:49:55] [01] [13:49:17] Finished devel/llvm13
ISCV.td
> llvm-tblgen -gen-instr-info -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d
> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-emitter -I /usr/sr
Considering that morse could use same beep dsp code, instead of
repeating dsp code inside morse, why not use a dsp library or
something so that morse could use it without duplicating code?
Hans Petter Selasky escreveu no dia sábado, 29/10/2022
à(s) 19:22:
> On 10/29/22 20:18, Nuno Teixe
> Technically you could symlink the two - yes.
Can't understand how, what do I missing?
Hans Petter Selasky escreveu no dia sábado, 29/10/2022
à(s) 19:11:
> On 10/29/22 17:44, Nuno Teixeira wrote:
> > Hello Hans,
> >
> > A few days ago I tried beep and it remembered m
15:36, Nuno Teixeira wrote:
> > Hello,
> >
> > unixcw is what I was looking for.
> > I think I will include it in some scripts just for fun :)
> >
> > I've started with base morse because it was nice if it can be updated to
> > play on dsp too.
> >
>
/10/2022 à(s) 14:01:
> On Fri, Oct 28, 2022 at 07:36:02PM +0100, Nuno Teixeira wrote:
> > Hello all,
> >
> > Is there any way to get sound from morse(6) without speaker(4) device?
>
> Any reason you can't just use unixcw from ports ?
> Or would ebook2cw be better fo
Hello all,
Is there any way to get sound from morse(6) without speaker(4) device?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
---
Cheers
Daniel Tameling escreveu no dia sábado,
24/09/2022 à(s) 14:47:
> On Wed, Sep 21, 2022 at 12:08:38PM +0100, Nuno Teixeira wrote:
> > Summary: Using bectl for upgrades
> >
> > RELEASE=Whatever
> > > bectl create ${RELEASE}
> > > bectl mount ${RELEASE}
>
the pkg rebuild.
>
> In the generic case I prefer to stay safe and keep the libs until I
> validated that nothing uses them anymore. That's the reason why I made
> the delete-old-libs functionality separate from delete-old already in
> the initial implementation.
>
> Bye,
> A
Hi Paul,
Really nice! I will test it soon.
Cheers
Paul Mather escreveu no dia quarta, 21/09/2022
à(s) 00:17:
> On Sep 20, 2022, at 6:19 PM, Alan Somers wrote:
>
> > On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira
> wrote:
> >>
> >> Hello to all,
> >&g
(...)
maybe:
> yes | make DESTDIR=${BASEDIR} delete-old delete-old-libs
Nuno Teixeira escreveu no dia quarta, 21/09/2022 à(s)
00:09:
> Hi Alan,
>
> This general procedure works just as well if you're upgrading from source,
>> too.
>>
>> sudo make DESTDIR=$
update -D $BASEDIR
Need to find how to execute:
`make delete-old delete-old-libs` since $BASEDIR don't have /usr/src
Thanks
--
Nuno Teixeira
FreeBSD Committer (ports)
..
if a problem happens, reboot default from BE loader
---
if everything fine destroy default and rename test to default
> bectl destroy -o default
> bectl rename test default
repeat on next upgrade
Don't know if a faster way exists with chroot or bectl jail...
Any hints appreciated.
Than
commit it.
Thanks to all and specially thanks to @emaste,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hi,
Yes I understand it now! It's because I patched kernel for PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>
Thanks and sorry for the noise,
Michael Gmelin escreveu no dia sexta, 26/08/2022 à(s)
18:03:
>
>
> On 26. Aug 2022, at 18:55, Nuno Teixeira wrote
Hello to all,
Today I updated and uname -a shows main-n257625-587649902329-dirty.
Why is showing -dirty?
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hi all!
patch ready and tested at PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>
Cheers,
Jung-uk Kim escreveu no dia quinta, 25/08/2022 à(s)
21:24:
> On 22. 8. 25., Nuno Teixeira wrote:
> > Hi!
> >
> > `pciconf -l | grep ^hdac`:
> > ---
---
(LENOVO_VENDORID 0x17aa)
maybe:
#define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ?
Jung-uk Kim escreveu no dia quinta, 25/08/2022 à(s)
20:15:
> On 22. 8. 25., Nuno Teixeira wrote:
> > ** Same config were imported from D30333
&
** Same config were imported from D30333
<https://reviews.freebsd.org/D30333> for Legion 5 AMD, PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>for Intel version
Nuno Teixeira escreveu no dia quinta, 25/08/2022 à(s)
19:59:
> Hello,
>
> I have Lenovo Le
bsd.org/bugzilla/show_bug.cgi?id=265632>
for Legion 5 AMD:
(sys/dev/sound/pci/hda/hdac.h)
---
#define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
---
How do I found id for Intel version so I can submit a patch?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
@ main-n257521-97be6fced7db
Clean boot without warnings.
OK.
Thanks,
Nuno Teixeira escreveu no dia quinta, 18/08/2022 à(s)
12:04:
> Forgot to send a screenshot
> <https://people.freebsd.org/~eduardo/logs/boot%4020220817.JPG> for
> loader.efi @ main-n257458-ef8b872301c5
> (
reebsd/loader.efi
/boot/efi//efi/freebsd/loader.efi )
Someone talked about this warnings earlier:
---
Attempted extraction of recovery data from stadard superblock: failed
Attempt to find boot zone recovery data: failed
(...)
---
But it boots ok.
Cheers,
Nuno Teixeira escreveu no dia quarta, 17/08/20
*** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
^^^^
Nuno Teixeira escreveu no dia quarta, 17/08/2022 à(s)
19:14:
> Hi,
>
> And it's done:
> ---
> Boot0007* FreeBSD-14
> HD(1
--
But I choosed "efi" instead of "EFI"...
Thanks all for helping me understand it!
Cheers,
Warner Losh escreveu no dia terça, 16/08/2022 à(s) 18:19:
>
>
> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira wrote:
>
>> Hi Toomas,
>>
>> For better O
Hello to all!
Today I found a new thing that might be interesting:
Windows Subsystem for Linux or WSL (url here
<https://docs.microsoft.com/en-us/windows/wsl/>)
I've didn't tried it yet but it makes me think if there are some advantages
if WS were available to FreeBSD.
Cheers,
--
Nuno Te
oot it backup old boot like
/boot/kernel -> /boot/kernel.old?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
`cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`
In this example we have a /boot/efi mount by the system, "/dev/XXXpN on
/boot/efi (msdosfs, local)".
What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is necessary
to backup and update it too?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
zfs mount zroot/ROOT/default
> 6. copy usb loader to zroot:
> cp /boot/loader /mnt/boot/loader
>
>
> i'd recommend just using boot environments, it's much easier and is
> specifically what they are for :)
>
> -pete
>
> --
> Pete wrightp...@nomadlogic.org
> @nomadlogicLA
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
e to wait a little more and see if people that use ifwwifi
driver do some tests on ipv6.
Thanks,
Shawn Webb escreveu no dia sábado, 13/08/2022
à(s) 21:21:
> On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> > Hello,
> >
> > Due to ISP changes I was force
, 13/08/2022 à(s) 18:50:
> Hi,
>
> > On 12 Aug 2022, at 13:00, Nuno Teixeira wrote:
> >
> > Hi Merek,
> >
> >> If you are connecting to IPv6 only WLAN than you can probably either
> >> disable DHCP (if the RDNSS is provided for this network):
> &
Hi Larry,
boot off a memstick?
>
Yes, that's it.
With it we can mount efi partition and use bkp efi file by renaming it.
I forgot that efi boot is restricted to use bootx64.efi (amd64) and my
though was looking for a command to load bootx64.efi.old avoiding use of a
memstick (e.g.).
I've tested
ame the bootx64.old to bootx64.efi
>
> and/or put it in a different directory that EFI can see
>
>
> On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
>
> I'm searching without success to load a bkp loader in case of boot failure.
>
> Upgrade process willl be like:
> ---
> mo
.old.
Could you tell me what you did to solve your boot?
Thanks
Yasuhiro Kimura escreveu no dia sexta, 12/08/2022 à(s)
18:45:
> From: Nuno Teixeira
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
>
> > Hello Yasu,
>
D-14-CURRENT-amd64-20220813-boot-hangup.png
>
> If I restore previous loader file (that is, loader.efi of
> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> system boots successfully.
>
> Best Regards.
>
> ---
> Yasuhiro Kimura
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
Hi Merek,
If you are connecting to IPv6 only WLAN than you can probably either
> disable DHCP (if the RDNSS is provided for this network):
> ifconfig_wlan0="WPA up"
> or install dhcp client capable of acquiring DHCPv6 lease and use it
> instead of standard dhclient(8) from the base which doesn't
T
---
@1ffd352bc25b
(e) what you can do is enable more wpa_supplicant logging; I often use
> wpa_supplicant_flags="-sdd" in /etc/rc.conf which will log to syslog
> instead
> of the debug file but it'll increase debugging a lot (and warning, it
> may also log keying material).
>
Ok.
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
="inet6 accept_rtadv"
ifconfig_wlan0="WPA SYNCDHCP"
rtsold_enable="YES"
---
but wpa_supplicant doesn't connect after trying for some seconds.
How do I obtain more details to help showing my problem?
I've tried "wpa_supplicant_flags="-f /var/log/wpa.log&qu
Hi Shawn,
Thanks for let me know about iwlwifi driver status.
I will post at freebsd-wireless mailing soon about it.
Cheers,
Nuno Teixeira
Shawn Webb escreveu no dia segunda, 1/08/2022
à(s) 18:10:
> On Mon, Aug 01, 2022 at 01:05:07AM +0100, Nuno Teixeira wrote:
> > Hello,
> >
escreveu no dia segunda, 1/08/2022 à(s) 13:15:
>
> On Sun, Jul 31, 2022, 21:05 Nuno Teixeira wrote:
>
>> Hello,
>>
>> I'm trying to setup a failover mode ethernet/wireless as shown in
>> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-
create_args_wlan0="country PT"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 DHCP"
---
Any ideas of what's wrong?
BTW, no kernel dump and I have dumpdev="AUTO" in /etc/rc.conf...
Thanks in advance,
Nuno Teixeira
ch_str = "as=1 seq=0";
break;
case 33:
patch_str = "as=1 seq=15";
break;
}
---
Cheers,
Nuno Teixeira
Hello Bjoern!
Thanks a lot for ultra fast fix! It's working ok.
Cheers
Bjoern A. Zeeb escreveu no dia sábado, 30/07/2022 à(s)
15:33:
> On Sat, 30 Jul 2022, Bjoern A. Zeeb wrote:
>
> > On Fri, 29 Jul 2022, Nuno Teixeira wrote:
> >
> >> Correction, it
Correction, it include old dmesg messages:
link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
Cheers
Nuno Teixeira escreveu no dia sexta, 29/07/2022 à(s)
21:36:
>
>
> -- Forwarded message -----
&
op_mode iwlmvm
iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351
iwlwifi0: Detected RF HR B3, rfid=0x10a100
iwlwifi0: base HW address: 6c:6a:77:df:09:21
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
---
Cheers,
Nuno Teixeira
Hello Dimitry!
Thanks for the tips. zfs upgraded, bootcode updated and system working fine.
Cheers,
Nuno Teixeira
Dimitry Andric escreveu no dia sábado, 16/07/2022 à(s)
17:17:
> On 16 Jul 2022, at 18:09, Nuno Teixeira wrote:
> > I'm about to upgrade zfs pool and I need to know th
2 freebsd-swap (4.0G)
8923136 1991485440 3 freebsd-zfs (950G)
2000408576 648- free - (324K)
---
Handbook says:
gpart bootcode -p /boot/boot1.efifat -i 1 ada1
Should I use:
gpart bootcode -p /boot/boot1.efifat -i 1 nvd0p1 ?
Thanks,
Nuno Teixeira
What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?
Masachika ISHIZUKA escreveu no dia domingo,
12/06/2022 à(s) 09:03:
> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
> warnings:
> > ---
> > ACPI Warning: Firmware issue:
Hello,
I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:
---
ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?
Thanks in advance,
Nuno Teixeira
Same here:
---
kldxref /boot/testing
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
failed to read progbits
ef_read_entry failed
*** Signal 11
Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1
Stop.
make[2]: stopped in
Same here:
kldxref /boot/kernel
failed to read progbits
But kernel failed to install. I will include log tomorrow, I'm doing a
clean build with /usr/obj/.. deleted.
Michael Butler via freebsd-current escreveu
no dia quinta, 21/10/2021 à(s) 20:14:
> Well this is different .. I did a full
Maybe that formula is choosing large fonts related with a 15' laptop
1920x1080
res for my taste. It remembers me older bsd versions when booting
But I'm happy knowing that I can change it.
Thanks very much,
Nuno Teixeira
Tomoaki AOKI escreveu no dia terça, 6/07/2021
à(s) 14:55:
> And I
1 - 100 of 123 matches
Mail list logo
