On Sat, 7 Sep 2024 21:31:21 -0600
Warner Losh wrote:
> On Sat, Sep 7, 2024, 9:16 PM Tomoaki AOKI wrote:
>
> > On Sat, 7 Sep 2024 19:38:47 -0700
> > Mark Millard wrote:
> >
> > > void wrote on
> > > Date: Sat, 07 Sep 2024 17:27:00 UTC :
> > &g
On Sat, 7 Sep 2024 19:52:53 -0700
Mark Millard wrote:
> Tomoaki AOKI wrote on
> Date: Sun, 08 Sep 2024 01:54:28 UTC :
>
> > On Sun, 8 Sep 2024 02:01:02 +0100
> > void wrote:
> >
> > > On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote:
> >
shows, but not using the 2 example's ada0 notation.
>
> > 2. Name: vtbd0p2
> > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200)
> > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-swap
> > 3. Name: vtbd0p3
> > efimedia: HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000)
> > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-zfs
> > 1. Name: vtbd0
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
FYI:
boot1.efi works with ZFS. gptboot.efi is basically the one which
stripped ZFS-related codes from boot1.efi.
And IIUC, boot1.efi shares most codes with loader.efi (except for its
own FS module wrapper as a consumer, implemented for UFS and ZFS).
It would be deleted in the future (that is your plan, Warner?),
but currently still usable.
--
Tomoaki AOKI
On Sun, 8 Sep 2024 02:01:02 +0100
void wrote:
> On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote:
>
> >Can it be in reverse?
> >
> >I've not read (even if it's already provided somewhere or attached) the
> >vmrun.sh script, but isn't
that
>>In such a case, you might need something like:
>>
>># cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi
>
>and the error is gone!!! TYVM
in another mail in this thread [1].
This could mean that efi/freebsd/loader.efi in ESP is not called by
the UEFI firmware and efi/BOOT/efi/bootx64.efi is used instead.
[1]
https://lists.freebsd.org/archives/freebsd-current/2024-September/006372.html
--
Tomoaki AOKI
pdated
automatically. This causes what you're experiencing.
Unfortunately, how loader.efi should be installed in ESP depends on the
environment it is installed. Old or buggy UEFI firmware could force you
installing it as, for example for amd64, BOOT/EFI/BOOTx64.EFI in ESP to
work, but usually BOOT/FreeBSD/loader.efi would work if UEFI boot
manager is properly configured for it.
Some would need ESP on all drives and keep all of them in sync.
Yes, hard to automate properly for every possible situations,
unlike /boot/.
--
Tomoaki AOKI
I've recently found this thread on forums.freebsd.org. [1]
[1]
https://forums.freebsd.org/threads/new-system-hardware-supported.93574/
--
Tomoaki AOKI
via /boot/loader.conf[.loal]
alltogether easily makes boot to crash on module loads.
A few of examples related: Bug 277967 [1], Bug 277364 [2],
Bug 277827 [3]
You would find much, much more on forums.freebsd.org.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277967
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277364
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277827
--
Tomoaki AOKI
On Fri, 12 Jul 2024 14:35:15 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
> On 12/07/2024 11:56, Tomoaki AOKI wrote:
> > On Fri, 12 Jul 2024 10:20:19 +0200
> > Miroslav Lachman <000.f...@quip.cz> wrote:
>
> [..]
>
> >> Something similar ha
anyone is interested.
>
> - John
Hi! Thanks for popping in. As others already commented, this is a long
awaited feature.
As I've already raised a white flag to port darwin implementation,
maybe I cannot help on coding, but I'd be happy to test once something
to test is available.
# I tried years ago with a bit of hope that the darwin code could be almost
# a drop-in replacement, but it was clearly beyond me. Too many macros to
# look for actual codes to see what for, functions etc which were incompatible
# with FreeBSD SMB1 implementation.
--
Tomoaki AOKI
o Teixeira
> FreeBSD UNIX: Web: https://FreeBSD.org
Just a FYI:
commit 40d951bc5932deb87635f5c1780a6706d0c7c012, amd64 boots fine for
me. So commits after 02d15215cef2a28f1865e6ad5b19f18af1398b8b caused
the problem, maybe.
Regards.
--
Tomoaki AOKI
On Tue, 02 Apr 2024 08:53:15 -0700
Chris wrote:
> On 2024-04-02 04:32, Tomoaki AOKI wrote:
> > On Tue, 02 Apr 2024 00:42:23 -0700
> > Chris wrote:
> >
> >> On 2024-04-01 22:51, Kevin Oberman wrote:
> >> > On Mon, Apr 1, 2024 at 3:05 PM Chris wro
ff830f7000 22cc hconf.ko
> >> 261 0x830fa000 2260 pflog.ko
> >> 271 0x830fd00056540 pf.ko
> >> 281 0x83154000 3560 fdescfs.ko
> >>
> >>
> >> Thanks!
> >>
> >> --Chri
> >
> >
> > I have a T16 and ran into that issue. It may be that BIOS changes have
> > broken things, but I found that, by default, the F keys control volume,
> > screen brightness, and many other things. I can use Fn+F[1-12] to perform
> > traditional function key functions. I found that bios has an option to make
> > the traditional functions the default which is how I am running today and
> > have since shortly after I purchased the computer. One I set that BIOS
> > option, everything worked "properly". I now use Fn+F[1-12] to adjust volume
> > and screen brightness. I hope to get mute to work, but I need to figure out
> > which event is set when Fn+F1 is pressed to write trivial devd support for
> > it.
> Well, I can't explain it. I set everything up in the BIOS to work
> "traditionally"
> and everything worked fine up until the upgrade. Where everything went
> "south"
> in the Fn department. But since you mentioned it. I thought I'd review the
> settings
> and sure enough, the Function key settings had changed. I have no
> explanation. I
> haven't been to the BIOS settings since initial setup. But only that setting
> was
> changed. I can't thank you enough for mentioning this, Kevin. I *really*
> appreciate
> your taking the time to reply!
So I was correct. ;-)
> > BTW, if you have not found it, Fn+K is screen lock. Most everything on my
> > T16 now works with FreeBSD CURRENT.
> Thanks. That was the first thing I looked for when I got it. I can't live w/o
> the scrollock. Took me a bit. But I found it too. :)
Another datapoint.
Even on Lenovo ThinkPad series, the alternative ScrLk is different.
On my ThinkPad P52, Non-existent ScrLk is mapped to Fn+B, not Fn+K.
You should better reading provided PDF manual closely before ordering
next time. Lenovo provides it relatively early for ThinkPads.
>
> Thanks again! :)
>
--
Tomoaki AOKI
000 3560 fdescfs.ko
Are you sure your function keys are actually function keys?
Not sure your IdeaPad is, but some Lenovo notebooks are configured
function keys as special (mute, radio,...) keys by default and needs to
configure in UEFI firmware to switch to function keys.
If it's the case, Fn+Alt+F2 would switch to vty1.
--
Tomoaki AOKI
d" timestamp to
> > prevent it being called over and over and over on workloads which are
> > syscall heavy.
> >
> > Note that for non-casual users of hpts (like Netflix, with hundreds of
> > thousands of TCP connections managed by hpts), this call is a huge win, so
> > I think we'd prefer that it remain in some form.
> >
> > Drew
Controlled via RW or RWTUN sysctl/tunable?
--
Tomoaki AOKI
On Sun, 19 Nov 2023 04:01:01 +0900
Tomoaki AOKI wrote:
> On Sat, 18 Nov 2023 09:50:43 +0100
> tue...@freebsd.org wrote:
>
> > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
> > >
> > > On Fri, 17 Nov 2023 18:51:05 +0100
> > > tue...@freebsd.org
contains
full sets (or selected pkgs) would be nice for specific cases that
hybrid media doesn't boot (maybe because of broken or too old BIOS).
> --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX:Web: https://FreeBSD.org
> > NTP: Web: https://nwtime.org
> > e^(i*pi)+1=0
> >
> > Pardon the typos. Small keyboard in use.
--
Tomoaki AOKI
On Sun, 14 Jan 2024 16:13:06 -0800
Mark Millard wrote:
> On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote:
>
> > On Sun, 14 Jan 2024 10:53:34 -0800
> > Mark Millard wrote:
> >
> >> On Jan 14, 2024, at 08:39, Olivier Certner wrote:
> >>
> >>
x27;t keep(current default)
2: Keep last one (default before 15.0)
by hand, or via installer configuration or additional scripts.
Of course, existing installations should not be affected.
--
Tomoaki AOKI
347K Buf,
3490M Free ARC: 3183M Total, 393M MFU, 2102M MRU, 2980K Anon, 34M
Header, 643M Other 1826M Compressed, 3471M Uncompressed, 1.90:1 Ratio
Swap: 64G Total, 12G Used, 53G Free, 18% Inuse
--
Tomoaki AOKI
ave positive functionality nowadays.
Anyway, we should have time to discuss whether it should be done or not
until upcoming stable/15 branch. stable/14 is already here and it
wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point
to introduce this, unlike discussion about vi and ee on forums.
--
Tomoaki AOKI
d the file after it was last modified) and also
> > provided a coarse-grained update (capped to daily, which is a reasonable
> > compromise) to the atime.
> >
>
> I like that compromise. It will miss a lot, but that 'miss' results in
> atime being good to only about
On Mon, 8 Jan 2024 10:35:03 -0600
Kyle Evans wrote:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> >> wrote:
> >>
> >>&
. action "chgrpy u2f ..." };.
Some hase more items in it, though.
So it should be in ports to adapt for latest products more quickly than
in base, I think.
--
Tomoaki AOKI
On Thu, 4 Jan 2024 12:49:03 -0700
Warner Losh wrote:
> On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
>
> > Tomoaki AOKI wrote:
> >
> > >
> > > Or create database (key-value store would be sufficient) storing commit
> > > order (like r*
ther database would be neeed. If the database can contain 2
value for 1 key, it would be suitable for you to store the assigned
time in UTC as "when it is committed to FreeBSD master repo".
Just a thought.
Regards.
--
Tomoaki AOKI
les under /etc/newsyslog.conf.d
and/or /usr/local/etc/newsyslog.conf.d?
If so, just moving default one to /etc/defaults would help, I think,
like at commit d105b00084a533f41a1277d08cfacb15062d9b50 [1].
[1]
https://cgit.freebsd.org/src/commit/?id=d105b00084a533f41a1277d08cfacb15062d9b50
Regards.
--
Tomoaki AOKI
On Fri, 22 Dec 2023 12:17:15 -0700
Warner Losh wrote:
> On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote:
>
> >
> >
> > > On 22. Dec 2023, at 11:09, Mark Millard wrote:
> > >
> > > Tomoaki AOKI wrote on
> > > Date: Thu, 21 Dec 2023 23
On Fri, 22 Dec 2023 16:15:42 +0200
Toomas Soome wrote:
>
>
> > On 22. Dec 2023, at 16:07, Konstantin Belousov wrote:
> >
> > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote:
> >>
> >>
> >>> On 22. Dec 2023, at 11:09, Ma
On Fri, 22 Dec 2023 12:02:54 +0200
Toomas Soome wrote:
> > On 22. Dec 2023, at 11:54, Mark Millard wrote:
> >
> > On Dec 22, 2023, at 01:36, Toomas Soome wrote:
> >>
> >>
> >>
> >>> On 22. Dec 2023, at 11:09, Mark Millard wrote:
&g
to
> > /boot/efi/efi/freebsd?
> >
> > At the moment I think installworld would not write 'through' such a
> > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to
> > /boot/loader.efi, unlinking any previous /boot/loader.efi.
> >
> > That said, it would be nice to have some sort of semi-official way of
> > upgrading the real EFI loader through installworld. It would probably
> > require some top-level Makefile magic.
> >
> > -Dimitry
> >
> >
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
--
Tomoaki AOKI
nd a repro case yet but it has locked up a few times
> the past two weeks.
>
> -pete
>
>
> --
> Pete Wright
> p...@nomadlogic.org
If I myself encounter this kind of problem ON BARE METAL HARDWARE,
I would usually suspect
*Overheating caused hang of NVMe controller or PCI bridge on SSD, or
*Unstable physical connection (bad contact)
first.
--
Tomoaki AOKI
On Sat, 25 Nov 2023 12:16:49 -0800
David Wolfskill wrote:
> On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote:
> > Hi.
> >
> > Not tested, but does upgrading to commit ed88eef140a1 [1] and later
> > help? (I'm still at commit 5d4f897f88ed
).
>
> Information about the machine(s) & update history may be found at
> https://www.catwhisker.org/~david/FreeBSD/history/ in case that's
> of use. (This includes a copy of /var/run/dmesg.boot from the last
> successful verbose boot, which was from yesterday.)
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> The notion that anyone would perceive a need to "make neo-Nazis
> look bad" is about as absurd as perceiving a need to "hydrate" water.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
--
Tomoaki AOKI
On Sat, 18 Nov 2023 09:50:43 +0100
tue...@freebsd.org wrote:
> > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
> >
> > On Fri, 17 Nov 2023 18:51:05 +0100
> > tue...@freebsd.org wrote:
> >
> >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote:
&g
mory: 0 bytes
No errors occured.
Switch back to freebsd (default) without unmounting:
1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
Leaked memory: 0 bytes
No errors occured.
Unmount and remount the smbfs share:
1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
Leaked memory: 0 bytes
No errors occured.
Regards.
--
Tomoaki AOKI
or
'The userland or kernel shall not unload the "kernel" module.'
.
The original SUMMARY could be read as, in meaning, 'The userland or
kernel shall not unload *.ko.'
*.ko is sometimes called as "kernel module", although it stants for
"kernel object".
--
Tomoaki AOKI
n't work once the kernel boots.
> >
>
> Considering that none of the current FreeBSD versions work I suspect
> that you'll have to flash the previous BIOS version to get a working
> system again.
>
> --
> Gary Jennejohn
Or check in detail for defaults on BIOS (UEFI firmware) settings
changes. Hopefully, these are usually described in readme or update
notes or something alike. If any, try reverting back to the previous
defaults except you intentionally changed on previous BIOS.
Sometimes BIOS vendors change their BIOS defaults to something FreeBSD
dislikes.
--
Tomoaki AOKI
ilname \
-m src=/usr/src`
and didn't yet encountered problems on updating poudriere jail.
This way, poudriere uses pre-built objects under /usr/obj as default.
Regards.
--
Tomoaki AOKI
On Tue, 26 Sep 2023 15:19:46 -0700
Cy Schubert wrote:
> In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
> Tomoaki
> AOKI writes:
> > On Tue, 26 Sep 2023 15:48:50 +0200
> > Marek Zarychta wrote:
> >
> > > W dniu 26.09.2023 oÂ
with git
hash. For example, if I `git log HEAD` with regular user and the local
repo is pulled by root, it fails. No special configuration is done.
% git log HEAD
fatal: detected dubious ownership in repository at '/usr/src'
To add an exception for this directory, call:
git config --global --add safe.directory /usr/src
--
Tomoaki AOKI
may alreay know of, but easily forgotton, values set to WITH_foo
and/or WITHOUT_bar does not have any meaning. Just the variable is set
or not is checked. I've bitten by something alike before.
--
Tomoaki AOKI
to run a buildworld with
> WITHOUT_CLEAN, e.g.:
>
> make -DWITHOUT_CLEAN -j buildworld
>
> That should rebuild all things that need rebuilding without doing excessive
> cleaning, and from there you can attempt to installworld again.
>
> -Dimitry
--
Tomoaki AOKI
}
Regards.
On Mon, 18 Sep 2023 09:26:56 -0400
Alexander Motin wrote:
> block_cloning feature is marked as READONLY_COMPAT. It should not
> require any special handling from the boot code.
>
> On 18.09.2023 07:22, Tomoaki AOKI wrote:
> > Really OK?
> >
> >
> > tunable does not even exist anywhere outside of FreeBSD base tree, I'd
> > propose to give this code another try here too. I see no point to
> > have it disabled at least in main unless somebody needs time to run
> > some specific tests first.
--
Tomoaki AOKI
BSD
> /boot/efi/EFI/FREEBSD/loader.efi
> /boot/efi/EFI/BOOT
> /boot/efi/EFI/BOOT/bootaa64.efi
>
> There may well be only:
>
> EFI/BOOT/bootaa64.efi
>
> for all I know.
>
> >From an amd64 context:
>
> # find /boot/efi/EFI/ -print
> /boot/efi/EFI/
> /boot/efi/EFI/FREEBSD
> /boot/efi/EFI/FREEBSD/loader.efi
> /boot/efi/EFI/BOOT
> /boot/efi/EFI/BOOT/bootx64.efi
>
> There may well be only:
>
> EFI/BOOT/bootx64.efi
>
> for all I know.
>
> (I set things up to have the EFI capitalization
> so that referencing efi/ vs. EFI/ in my context
> is unique for the mount point. vs. the msdosfs
> directory.)
>
> ===
> Mark Millard
> marklmi at yahoo.com
--
Tomoaki AOKI
d zsh is `exec`'ed from tcsh.
if ( -X zsh && -f ~/.Use_zsh ) exec zsh
--
Tomoaki AOKI
nored: 335 Fetched: 0
> Tobuild: 33800 Time: 00:30:41
>
>
> So 414 and and still building.
>
> More later. (It may be a while.)
>
> ===
> Mark Millard
> marklmi at yahoo.com
Would it planned to be MFC'ed to stable/14, and then releng/14.0 once
MFV'ed to main?
Regards.
--
Tomoaki AOKI
st/004194.html
[2]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004208.html
[3]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004210.html
--
Tomoaki AOKI
rg/releases/14.0R/schedule/
>
> Regards,
> Ronald.
>
> Van: Tomoaki AOKI
> Datum: vrijdag, 18 augustus 2023 00:00
> Aan: freebsd-current@freebsd.org
> Onderwerp: Status for zfs upgrade?
> >
> > Hi.
> >
> > Creation of stable/14 is planned at Aug.18
I've happened to cover
> your case vs. not.
>
> ===
> Mark Millard
> marklmi at yahoo.com
Just a FYI:
www/chromium built fine (stable/13, though) with poudriere.
RAM is 32GB and 64GB single dedicated swap partition on SSD.
Using ports-mgmt/poudriere-devel.
No ccache used.
In /usr/local/etc/poudriere.conf,
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes
The line below is kept commented out.
#TMPFS_LIMIT=8
On main (booted from different physical drive on the same PC), I don't
use poudriere[-devel], but www/chromium (previous version) built fine
using ports-mgmt/pkg_replace. The size of /tmp (swap-backed tmpfs) is
not limited (means at maximum of 64GB).
--
Tomoaki AOKI
y for those who use boot0 to
> revert back to 9600 in that case.
Not read the diff though, if the baud rate is re-initialized in boot1
or later (including btx, loader, kernel and userland) and handshake
again, most of the boot process and later would run at 115200 bps.
--
Tomoaki AOKI
On Tue, 15 Aug 2023 21:39:56 +0900
Tomoaki AOKI wrote:
> On Tue, 15 Aug 2023 08:35:01 +0200
> Matthias Apitz wrote:
>
> >
> > The port www/firefox stops to build in congigure phase with:
> >
> > DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-w
t should depend on devel/llvm13 and use it, if base
llv/clang is NOT 13.
> Thanks
> matthias
>
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
--
Tomoaki AOKI
if disabling TSO as documeted on the commit
message?
CC'ing kbowling@, who committed all (I could find on cgit)
e1000/em-related bits between the timeframe of 1. and 2.
[1]
https://cgit.freebsd.org/src/commit/?id=f1b5488f7bba7f25a57750f87cbcbccbd5b9d16b
--
Tomoaki AOKI
gi?id=270041
>
> Oh nice! How I have missed this BZ report, this will get my 14-CURRENT
> hosts up to date, thanks for sharing.
Maybe because it was once closed. :-)
Now it's reopened. Feel free to pop in and report your result there.
Applied the uploaded patch, or increased ulimit in poudriere.conf.
Update OK or not.
--
Tomoaki AOKI
PG key: http://www.unixarea.de/key.pub
Reopened as original reporter. ;-)
I myself is no longer bitten again, as I've raised ulimit in
/usr/local/etc/poudriere.conf.
CC'ing kai@ here, who committed the latest actual "update" to 5.15.8.
Unfortunately, bugzilla picks the maintainer (and automatically mails
to) from ports Makefile. So kde@ is picked as maintainer here.
--
Tomoaki AOKI
ection is "stay there until someone who can
construct new build environment pops in". This could happen here and
there, unfortunately.
For example,
*Consider python27 and required py-* as bootstrapping tool.
*Build python27 and required py-* everytime the port is built
and cleanup afterwards, INSIDE PORTS WORKDIR.
*python27 and required py-* are listed in distinfo of each port which
requires python27 on build time only.
would allow lang/python27 to be deleted, if possible.
>
> Cheers,
> -Enji
--
Tomoaki AOKI
On Fri, 11 Aug 2023 15:27:46 +0200
Dag-Erling Smørgrav wrote:
> Tomoaki AOKI writes:
> > This can help new installation using release tarballs (official or
> > locally built) or upgrading with overwriting using said tarballs, but
> > how does freebsd-update?
>
> f
e K&R
codes, if proper options are set. This is how ALL computer languages
SHALL BE.
[1]
https://github.com/naftaliharris/tauthon/commit/52473e14e93366e02cf0b63b4c7fd952420e5ee3
--
Tomoaki AOKI
On Thu, 10 Aug 2023 16:08:26 +0200
Dag-Erling Smørgrav wrote:
> Tomoaki AOKI writes:
> > Yes. But if bsdinstall and freebsd-update automatically bootstrap
> > etcupdate if not yet done, newbies and casual users wouldn't be bitten.
>
> https://cgit.
On Thu, 10 Aug 2023 03:15:43 -0700 (PDT)
"Jeffrey Bouquet" wrote:
> On Thu, 10 Aug 2023 06:32:14 +0900, Tomoaki AOKI
> wrote:
>
> > On Wed, 9 Aug 2023 05:50:05 -0700
> > David Wolfskill wrote:
> >
> > > On Wed, Aug 09
On Wed, 9 Aug 2023 05:50:05 -0700
David Wolfskill wrote:
> On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote:
> > ...
> >
> > Please correct me if I'm missing something.
> > I use source update for years and not using bsdinstall nor
> > freebsd
Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Please correct me if I'm missing something.
I use source update for years and not using bsdinstall nor
freebsd-update.
Does bsdinstall (and/or freebsd-update) create the first current tree
for etcupdate, if not yet exists?
This would be most confusing and harmful point of etcupdate.
When I first tried etcupdate, I didn't noticed that I needed
`etcupdate extract -B` BEFORE UPDATING src tree.
Without this, etcupdate cannot detect what should be updated, even if a
plenty of updates are required.
At the moment, I must use mergemaster, and after that, `etcupdate
extract -B` for next run.
I think bsdinstall can create current tree, which is turned over to old
tree on actual run, for etcupdate.
So do freebsd-update. It would be able to create current tree JUST
BEFORE INSTALLING UPDATE.
I was helped by mergemaster, but after it completely retires, features
above should be mandatory.
--
Tomoaki AOKI
On Tue, 8 Aug 2023 17:02:32 +0300
Konstantin Belousov wrote:
> On Tue, Aug 08, 2023 at 10:46:12PM +0900, Tomoaki AOKI wrote:
> > On Tue, 8 Aug 2023 15:38:46 +0300
> > Konstantin Belousov wrote:
> >
> > > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wro
On Tue, 8 Aug 2023 15:38:46 +0300
Konstantin Belousov wrote:
> On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote:
> > On Sun, 6 Aug 2023 12:55:07 +0300
> > Konstantin Belousov wrote:
> >
> > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrot
On Sun, 6 Aug 2023 12:55:07 +0300
Konstantin Belousov wrote:
> On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote:
> > On Wed, 23 Feb 2022 01:30:28 +0200
> > Konstantin Belousov wrote:
> >
> > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin w
s://lists.freebsd.org/archives/freebsd-users-jp/2023-July/000205.html
[2]
https://www.intel.com/content/www/us/en/products/sku/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz/specifications.html
[3] https://en.wikipedia.org/wiki/Alder_Lake
[4] https://www.bee-link.com/eq12-n100-clone-1-82615581
Regards.
--
Tomoaki AOKI
script requiring ports-mgmt/pkg_replace.
Edit it to use whatever you want.
If you're using poudriere[-devel], it should rebuild everything.
I don't use poudriere on main, as it should force me tooo many full
rebuilds than on stable/* branches.
If letting poudriere to rebuild everythi
trickily close
> > to 14 to be mucking with this...
> >
> > Warner
> >
>
>
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
--
Tomoaki AOKI
ted 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
> bit unexpected.
>
> Thanks very much for raising the point!
>
> bob prohaska
Maybe that's it.
As you chose "theirs all" (maybe theirs-full?), conflicted files
(include /etc/master.passwd) are overwritten by brand-new default ones.
You should choose "(e) edit" and manually merge them correctly.
--
Tomoaki AOKI
U, it most likely has a 64bit efi
> implementation.
Exactly. I'd found the info while discussing with the reporter on
freebsd-uses-jp ML at Intel site.
Note that neither boot1.efi nor loader.efi shipped with FreeBSD i386
distribution couldn't boot kernel successfully (built but not working).
So I have no objection for discontinueing the support.
> > Shipped with "Windows 8.1 with Bing (32bit)" installed.
>
> Probably a good choice to use a 32 bit OS on a machine
> with only 2GB as there is no need for a 64 bit pointer.
> This pretty much applies to any machine with 4GB or
> less of memory
IIRC, I've read somewhere describing that ASUS EeeBook X205TA has 32bit
UEFI to boot 32bit Windoze, and supports 32bit UEFI boot only.
I've found folowing pages now, different pages I read ATM, though.
https://github.com/filirnd/x205ta
https://forums.linuxmint.com/viewtopic.php?t=380177
>
> >
> > [1]
> > https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-March/001728.html
> >
> > [2]
> > https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-April/001746.html
> >
> >
> > --
> > Tomoaki AOKI]
> >
> >
>
> --
> Rod Grimes rgri...@freebsd.org
>
--
Tomoaki AOKI
> > these are popular and very much robust, I'm open to learning about it.
>
> I just noticed that it was asked several times in the last few months
> trying to use FreeBSD on not-so-modern and rather exotic hardware; I
> don't think we really need that support, but I simply wasn't aware of
> efi32 status before this commit, hence I asked :)
Just a FYI.
A subscriber (not me) tried ASUS EeeBook X205TA (manufactured "2015-04")
through Mar.18, 2021 to Apr.13, 2021 without luck on freebsd-usrs-jp ML
(in Japanese, started from [1], [2] for April).
Atom CPU Z3735F @1.33GHz, 2GB RAM
Shipped with "Windows 8.1 with Bing (32bit)" installed.
[1]
https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-March/001728.html
[2]
https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-April/001746.html
--
Tomoaki AOKI]
ine, Zap Putin.
Just FYI:
Attached is the sh script I've been using for years to apply/revert
multiple patches at once, basically for patches uploaded on bugzilla.
I know it's far from perfect, but maybe handy for casual users who have
any problem with genuine base or ports and needs
rrect time output
> even though I live in Germany and the correct value would be either
> Europe/Berlin or CET.
>
> My laptop, which still has the old tzcode installed, did not exhibit
> that weird error.
>
> --
> Gary Jennejohn
Do you have /etc/wall_cmos_clock?
Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC.
A blank file (just `touch`ed to create) is enough.
IIUC, your laptop has it, but your tower has none.
--
Tomoaki AOKI
?
> - Leave it as is. After the patch that allows mountd to run in
> a vnet prison, MNT_EXPORTED will be set in fsflags, but the
> priv_check() call will just return 0. (A little overhead,
> but otherwise no semantics change.)
>
> rick
--
Tomoaki AOKI
ity of
> California at Berkeley. Those two and others also ran experiments on a
> secure email offering from TrustCor named MsgSafe.io. They found that
> contrary to MsgSafe’s public claims, emails sent through its system
> were not end-to-end encrypted and could be read by the company.
>
> McPherson said the various technology experts had not used the
> right version or had not configured it properly. -WaPo
>
> In a previous case which illustrates the importance of trusting
> root-level authorities - a security company controlled by the United
> Arab Emirates, DarkMatter, applied in 2019 to have top-level root
> authority from their status as an intermediate authority with less
> independence. The request followed revelations that DarkMatter had
> hacked dissidents and even some Americans - after which Mozilla denied
> it root power.
>
>
> "Received email from DDNS no-IP, they offering free TrustCor Standard
> DV SSL certificate."
> "Free, comes complete with spyveillance and exploit, lol."
> "Imagine that even the most trusted CA's are actually rogue!"
>
>
--
Tomoaki AOKI
On Tue, 22 Nov 2022 19:13:18 +0100
Gary Jennejohn wrote:
> On Wed, 23 Nov 2022 01:16:55 +0900
> Tomoaki AOKI wrote:
>
> > On Tue, 22 Nov 2022 09:47:10 -0600 (CST)
> > Dan Mack wrote:
> >
> > > On Tue, 22 Nov 2022, Alexander Kabaev wrote:
> > >
&g
ncy driver. If so, does setting
> > dev.hwpstate_intel.0.epp=0 make any difference ?
> >
>
> Yes, I have four of those, set to 50 by default. Let me try.
>
> --HPS
FYI: I habitally run below manually (as root) when I'm on AC powerline.
sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
sysctl ${OID}=0 ; done
--
Tomoaki AOKI
r Kabaev
> >
>
> Thank you Alexander, I did not know this. I'll USL (use-the-source-luke)
> :-)
>
> Dan
Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg
to live longer. For example, recommended value by iwlwifi team is
1146880. Much larger than default.
Note that this is actually a tunable and can be set only on boot time.
--
Tomoaki AOKI
on Bugzilla via commit logs on main (pointed by markj@)
instead of Differential Revision on Phablicator.
Phab shouldn't know about branches other than main this case.
On Bugzilla, we can see each of them MFC'ed to stable/13 with second
commit-hook.
--
Tomoaki AOKI
; #mdroot_name="/boot/root.img" # Path to a file containing the image.
> #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device.
> …
>
> —
> Mira
>
> > On 19 Nov 2022, at 21:58, Tomoaki AOKI wrote:
> >
> > IIUC, rootd
fine on freebsd 12.1, but on freebsd 12.3 this does
> > not work and generates error message:
> >
> > Can’t determine root device
> >
> >
> > When I use this option with value “/dev/md0” or “md0” (even with this
> > option commented out), so the machine boots correctly without any error.
> >
> > I think you want vfs.root.mountfrom= instead of rootdev= here.
> >
> > Warner
> >
> > —
> > Mira
>
--
青木 知明 [Tomoaki AOKI]
w.cpu.0 | grep cx
> >
> > Your system may provide other Cx possibilities, and ging to a lower
> > number (e.g. C1) means less power-saving but faster response from the
> > CPU (I do not expect that this is causing the issue you have).
> >
> >> Any advice on where to look?
> >
> > Potential sysctl to play with to change "interactivity detection" in ULE:
> > https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html
> >
> > Bye,
> > Alexander.
> >
>
--
Tomoaki AOKI
t;
> > > Louis
> >
> > If you are using Gnome, Gnome suspends the machine after 20 minutes if
> > there is no mouse or keyboard activity. I went into settings, but there is
> > no way to adjust this feature. Some web searching brought me to this page:
> >
> > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22
> >
> > Apparently the 20-minute suspend was made unchangable (at least not without
> > changing the source code for Gnome and rebuilding it).
> > Apparently this change was made to comply with EU power regulations.
> > Anyway, this ruled out Gnome for me.
> >
> > Kirk McKusick
>
--
Tomoaki AOKI
dding new zpool feature(s) to main and if the loader
> was ready for them yet. If not: Later adding an entry for
> the loader being ready for the feature(s).
+1.
> > It's when you enable something on the zpool that you can run into trouble,
> > but that's true independent of upgrade :)
> >
> > Warner
> > Modulo bugs, try test systems first, etc. Of course.
> >
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>
--
Tomoaki AOKI
can always boot with
all features enabled.
So changes to zpool would be able to OS independent except the header
defining features supported by its loader.
There can be other matrixes for implemented (after boot) and
default-to-be-enabled features. The OS-dependent matrixes would ease ZFS
developers to determine which features are implemented / defaulted /
bootable on specific OS. (Already there?)
--
Tomoaki AOKI
update on 3rd November:
>
> % uname -aKU
> FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25
> main-n259004-2c10be9e06d4: Thu Nov 3 00:14:52 GMT 2022
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
>
> amd64 1400073 1400073
>
--
Tomoaki AOKI
omatically.
If any conflict happenes, ask the admin (this case, you) for actions.
So it requires previous default state, thus cannot use for this case,
except you are sure what the actual previous revision was and can
prepare the source tree (possibly obj tree, too?) and somehow create
"current" tree ATM (will be turned over to "previous" tree on etcupdate
run).
See manpages for detail.
--
Tomoaki AOKI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206
--
Tomoaki AOKI
ernal definitions in the ports tree
> provided scripts.
>
> Whether or not someone will have to script something to rerun the
> +POST_INSTALL
> on reboot shouldn't stop from adding a pkg script run option to enable the
> former.
>
> Solutions not involving the actual ports scripts seem to be over-engineering
> when trying to record "unknown state" for a "reproducible outcome". ;)
>
>
> Cheers,
> Franco
>
--
Tomoaki AOKI
On Wed, 17 Aug 2022 07:55:32 +0900
Tomoaki AOKI wrote:
> On Mon, 15 Aug 2022 21:35:52 -0600
> Warner Losh wrote:
>
> > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura wrote:
> >
> > > From: Yasuhiro Kimura
> > > Subject: Re: Updating EFI boot loader res
line.
And so as base /usr/bin/xz (through pipe) and ports lang/ruby30.
The former caused x11/linux-nvidia-libs to fail on extract,
and the latter caused ports-mgmt/portupgrade (including portsclean) to
fail on start.
Both are fixed at the commit.
Thanks!
--
Tomoaki AOKI
09792 135219200 4 freebsd-swap (64G)
3907028992 136- free - (68K)
% gpart show ada0
=>40 3907029088 ada0 GPT (1.8T)
402008- free - (1.0M)
2048 1126400 1 efi (550M)
11284482048 2 freebsd-boot (1.0M)
1130496 3749707776 3 freebsd-zfs (1.7T)
375083827220971520 4 freebsd-ufs (10G)
3771809792 135219200 5 freebsd-swap (64G)
3907028992 136- free - (68K)
--
Tomoaki AOKI
gt; ---
> > Yasuhiro Kimura
> >
> > --
> >
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>
> --
> 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
>
> --
>
> Nuno Teixeira
> FreeBSD Committer (ports)
>
> --
> 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
--
Tomoaki AOKI
hould* have read: Ctrl+Alt+F<1-8>
...and Alt+F<1-8> to switch vtys afterwards.
To get back to X, Alt+F9.
You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.
>
> Sorry.
> > accomplish your goal. Does doing it that way fix it for you?
> >
> > HTH
> >
> > --Chris
> >>
> >> im using the drm-devel-kmod git for i915kms.ko btw
> >>
> >> any ideas what could it be?
> >>
> >> thank you guys
> >>
> >> --tzk
--
Tomoaki AOKI
system :-)
>
> --HPS
Plus, unlike GPL, you don't need to make open-source what you modified.
This should be a killer who uses NDA'ed codes in conjunction with
BSD-licensed codes.
In these cases, you SHALL make open-source under GPL whole NDA'ed code
if you use GPL'ed codes.
On Sat, 25 Jun 2022 11:29:43 +0200
Hans Petter Selasky wrote:
> On 6/24/22 18:51, Tomoaki AOKI wrote:
> > On Fri, 24 Jun 2022 17:29:26 +0200
> > Hans Petter Selasky wrote:
> >
>
> Hi Tomoaki,
>
> Please retest:
> https://reviews.freebsd.org/D35552
>
code normalization treat
them. But we Japanese would want U+3000 treated as space.
[1] https://en.wikipedia.org/wiki/Non-breaking_space
--
Tomoaki AOKI
1 - 100 of 246 matches
Mail list logo
