or not.
> > >>
> > >> rgds,
> > >> toomas
> > >>
> > >>>
> > >>> Nuno Teixeira escreveu no dia ter〓a, 6/07/2021
> > >> 〓(s)
> > >>> 11:37:
> > >>>
> > >>>> Hello,
> > >>>>
> > >>>> I remember having high resolution console at 1920x1080 but due to
> > >> hardware
> > >>>> problems I replaced hdd and installed latest snapshot #0
> > >>>> main-n247671-c5f4772c66d: Thu Jul 1 and now console resolution is very
> > >> low.
> > >>>>
> > >>>> Did I missed something or I need to configure system so I can have high
> > >>>> res again?
> > >>>>
> > >>>> Thanks,
> > >>>> Nuno Teixeira
> > >>>>
> > >>
> > >>
> >
> >
> >
> >
--
Tomoaki AOKI
wrote:
> hello,
>
> which config file should I put that line? loader.conf?
>
> Tomoaki AOKI escreveu no dia ter〓a, 6/07/2021
> 〓(s) 14:08:
>
> > Or if the previous installation is old enough,
> > possibly just a font auto-selection problem.
> > If screen res
> yes and no. the automatic font selection does try the best, but people are
> different and the automatic selection may not be best for You. Anyhow, thats
> the reason to have option to set it manually.
>
> rgds,
> toomas
>
>
> > Tomoaki AOKI escreveu no di
of work would be more of a one shot.
> Didn't look at cmake at all, but I imagine it would be similar...
>
> Warner
>
> >
What about devel/samurai, ninja-compatible build tool written in C?
devel/ninja/Makefile has USES= python in it, so it maybe require python
to run or at least build.
In addition, ports framework can use it instead of ninja.
See {PORTSDIR}/Mk/Uses/ninja.mk.
--
Tomoaki AOKI
1
if I understand correctly.
Or remove line 392 and 393 with guarding added line 470 though 485 with
#ifdef DETECT_TZ_CHANGES.
Old behaviour never returns there.
I suspect current code without defining WITH_DETECT_TZ_CHANGES=yes
in /etc/src.conf make first tzload() call do nothing and forth fallback
to UTC.
--
Tomoaki AOKI
On Tue, 14 Sep 2021 21:49:28 +0100
Edward Tomasz Napiera〓a wrote:
>
> > On 14 Sep 2021, at 16:33, Tomoaki AOKI wrote:
> >
> > On Tue, 14 Sep 2021 10:37:36 +0200
> > Michael Gmelin wrote:
> >
> >>
> >> On Tue, 14 Sep 2021 09:02:46 +
>
ppening overall.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
IIRC, zpool (except zpool import) only works with already-imported
pool(s).
So IIUC, `zpool status` and `zpool destroy` for faulted pool(s) would
only works properly if the pool(s) fault after graceful import.
*I have root pools only (in different physical drives), so non-root
pools can behave differently.
--
Tomoaki AOKI
oot to multiuser at git: 8db1669959ce
Boot fine at git: 0b79a76f8487
Boot to singleuser is fine even with failed revision.
Failure mode:
Hard hangup or spinning and non-operable. Hard power-off needed.
Seems to happen after starting rc.conf processing and before setting
hostid.
--
Tomoaki AOKI
On Wed, 22 Sep 2021 23:09:05 +0900
Tomoaki AOKI wrote:
> On Wed, 22 Sep 2021 05:47:46 -0700
> David Wolfskill wrote:
>
> > On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:
> > > I did a git pull this morning and it fails to boot.
> > > I han
> That also brings up a question: Does nvidia kmods (and probably also drm
> kmod) match the kernel?
>
>
> 〓
> Juraj Lutter
> o...@freebsd.org
Of course. I habitally rebuild all ports having *.ko after installworld
and etcupdate.
(I don't use drm-*-kmod, as nvidia-driver doesn't need it.)
--
Tomoaki AOKI
On Fri, 24 Sep 2021 01:33:33 +0300
Konstantin Belousov wrote:
> On Thu, Sep 23, 2021 at 09:20:51PM +0200, Johan Hendriks wrote:
> >
> > On 23/09/2021 19:52, Konstantin Belousov wrote:
> > > On Fri, Sep 24, 2021 at 12:43:01AM +0900, Tomoaki AOKI wrote:
> > > >
079240.html
[3]
https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007513.html
[4]
https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007512.html
--
Tomoaki AOKI
kern.sched.steal_thresh value now.
In the other hand, at least some Ryzen users seem to have much more
severe problem than me and the workaround make significant imrovement.
> On 25.09.2021 21:47, Konstantin Belousov wrote:
> > On Sun, Sep 26, 2021 at 10:23:47AM +0900, Tomoaki AOKI w
>libtinfow.so.9 => /lib/libtinfow.so.9 (0x800703000)
> >>
> >> Note: The dialog4ports is a non-debug build but with debug symbols,
> >> as is normal for my port builds via poudriere-devel .
> >>
> >> As for the poudriere-devel build context for the ports:
> >>
> >> # chroot /usr/obj/DESTDIRs/13_0R-amd64-poud/
> >> # uname -apKU
> >> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3
> >> main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021
> >> root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
> >> amd64 amd64 1400036 1300139
> >>
> >> # cd /usr/13_0R-src/
> >> # ~/fbsd-based-on-what-commit.sh
> >> branch: releng/13.0
> >> merge-base: 940681634ee17d12225ecd722c07fef1a0bde813
> >> merge-base: CommitDate: 2021-08-24 18:23:29 +
> >> 940681634ee1 (HEAD -> releng/13.0, freebsd/releng/13.0) Add UPDATING
> >> entries and bump version.
> >> n244760 (--first-parent --count for merge-base)
> >
> >
> >
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
>
--
Tomoaki AOKI
de from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.
Anyway, please don't remove it unless usable alternative appears.
> If I am "well informed" FreeBSD is the only widely used OS not
> supporting SMBv2. (MacOS, Linux, Sola
On Sun, 31 Oct 2021 18:15:25 +0100
Marek Zarychta wrote:
> W dniu 29.10.2021 o〓08:29, Andrea Venturoli pisze:
> >
> > On 10/29/21 00:47, Tomoaki AOKI wrote:
> >
> >> But possibly we need to delete current smbfs code from base and switch
> >> to ports (sysu
> git_daemon 〓slpd 〓〓〓webcamd
> > gkrellmd 〓〓〓smartd
> > root@mowa219-gjp4-8570p-freebsd:~ # date
> > Sat Nov 13 10:21:22 GMT 2021
> > root@mowa219-gjp4-8570p-freebsd:~ # uname -aKU
> > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #114
> > main-n
> > 250511-5f73b3338ee: Sat Nov 〓6 21:15:23 GMT 2021
> > root@mowa219-gjp4-8570p-fre
> > ebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 〓amd64 1400040 1400040
> > root@mowa219-gjp4-8570p-freebsd:~ #
>
>
> --
> Gary Jennejohn
>
--
Tomoaki AOKI
gt; not found and is required by the application
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/ports/devel/py-pycparser
> >
> > ===>>> make build failed for devel/py-pycparser@py38
> > ===>>> Aborting update
> >
> > FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62
> > heads/main-n251146-d109559ddbf: Mon Nov 29 12:18:48 CET 2021
> > root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING?? amd64
> >
> >
--
Tomoaki AOKI
Confirmed.
Thanks for your quick reaction!
On Tue, 30 Nov 2021 22:45:37 +
Brooks Davis wrote:
> Yeah, I've got this in progress.
>
> -- Brooks
>
> On Wed, Dec 01, 2021 at 06:57:56AM +0900, Tomoaki AOKI wrote:
> > It would be better making new special hand
n june).
*I got busy manually checking and applying changes to /etc, and
forgot to file PR.
Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does
NOT do anything, hence nothing is actually updated.
The only workaround I have is NOT to try dry-run.
It would be because the same trees are used for dry-run and actual run.
(Not looked into the code. Just a thought.)
Maybe using dedicated trees (older one is copied from actual current
one, building current tree on dedicated place and delete them every
time the dry-run finishes) for dry-run would fix.
And copying /etc to some temporary place and applying changes to it,
copy back to /etc may be help for your issue, I think.
--
Tomoaki AOKI
On Wed, 8 Dec 2021 09:11:05 -0800
John Baldwin wrote:
> On 12/3/21 6:09 PM, Tomoaki AOKI wrote:
> > On Fri, 03 Dec 2021 05:54:37 -0800 (PST)
> > "Jeffrey Bouquet" wrote:
> >
> >>
> >>
> >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav L
0d908f8a6-251253 in order to avoid
> possible problems
>
> and again, after make kernel and reboot OS runs, but after installworld I
> ended up in the same situation
>
> thoughts ?
>
> --
> wbr, Sergey
>
>
Bootcode should be updated.
The procedure you wrote doesn't seem to update it.
--
Tomoaki AOKI
that modern Linux distributions have been
> using NFSv4 by default for some time.
>
> So I think it makes sense to teach mount_nfs to attempt NFSv4, then
> NFSv3 and NFSv2. However, this might be a POLA violation and we would
> like to know if there is any objections.
>
> (I've attached a patch but I haven't actually tested it yet).
>
> Cheers,
--
Tomoaki AOKI
el and -amdgpu drivers)
is also updated? drm-*-kmod could be affected by LinuxKPI updates in
base.
*There can be some (sometime very wide) timeframe between LinuxKPI
update and corresponding linux-*-kmod catches up with it.
Looking into cgit.freebsd.org, at least drm-current-kmod is updated 36
hours ago. Not sure it's related or not, though.
*I always prefer nvidia dGPU because of these dangerous span.
So I've forced to choose ThinkPad P series (without "s") which
usually can disable CPU-integrated Intel GPU and run nvidia GPU
alone though BIOS setting.
--
Tomoaki AOKI
On Sat, 29 Jan 2022 15:33:34 -0800
David Wolfskill wrote:
> On Sun, Jan 30, 2022 at 07:25:49AM +0900, Tomoaki AOKI wrote:
> > ...
> > *I always prefer nvidia dGPU because of these dangerous span.
> > So I've forced to choose ThinkPad P series (without "s")
reeBSD 13 with ZFS, and it can work well. And boot into
> > FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the
> > testing as above.
> >
> > Regards,
> >
> > Alvin Chen
> >
> > Dell | Comercial Client Group
> >
> > office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506
> > weike_c...@dell.com <mailto:weike_c...@dell.com>
> >
> > Internal Use - Confidential
> >
>
> --
> Alexander Motin
>
--
青木 知明 [Tomoaki AOKI]
cting is not realistic.
(Would require tens of weekends, maybe.)
Any thoughts? Or am I missing something to check for?
Regards.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008
--
Tomoaki AOKI
re
described at Comment 20 [3].
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c21
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c20
On Sat, 26 Feb 2022 13:29:26 +0100
Michael Gmelin wrote:
> Maybe it’s related to ASLR? (or is it also enabled in 13/stable?)
>
&g
uld be worth trying.
Beware! If other updated components are mandatory for /sbin/zfs, the
above procedure is not at all enough. But would crash before actually
the pool is imported.
--
Tomoaki AOKI
till at git
c79331a42c308139828c1117f49224bb83617a53 and is using both NVMe and
UEFI, but via nda, not nvd.
Non-Geli-encrypted bootfs.
Note that my BOOTx64.efi is not a copy of loader.efi, but boot1.efi
applied latest patch uploaded on Bug 207940 [1].
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940
Basically, I upgrade pool only when I switch to latest stable branch
that is just created, meaning that the zfs codes and boot codes are
basically 100% match on main and latest stable. This way, both pools
of main environment and of stable (now stable/13) environment have
100% equal features.
--
Tomoaki AOKI
s://cgit.freebsd.org/src/commit/?id=1599fc904d35cfa8eecad92818d1f4b55de6818f
Regards.
--
Tomoaki AOKI
On Wed, 4 May 2022 20:37:41 -0600
Warner Losh wrote:
> On Wed, May 4, 2022 at 6:03 PM Tomoaki AOKI
> wrote:
>
> > Hi.
> >
> > After updating src main git: f44280bf5fbb to git: 1599fc904d35,
> > with options CAM_IOSCHED_DYNAMIC on kernel config file,
> > A
set
DEFAULT_VERSIONS+= llvm=13
for editors/libreoffice on /etc/make.conf with conditinal.
Please visit the mentioned PR for more detail.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263976
Regards.
--
Tomoaki AOKI
y.
>
> It builds fine on a recent -current with clang14,
> https://build.dimapanov.com/poudriere//data/140amd64-dimaports/2022-05-21_19h50m37s/logs/libreoffice-7.3.3.2_1.log
>
> However, all my own builds run without LTO enabled, it might matters
>
> On 22.05.2022 02:29, Tomoak
ar)*end))
> > + {
> > + *end = '\0';
> > + end--;
> > + }
> > +
>
> I think this would be better and avoid the ">" with pointers!
>
> for (end = buf + i; end-- != buf; ) {
> if (isspace((unsigned char)*end) == false)
> break;
> *end = '\0';
> }
>
> Can you explain this:
>
> > - buf[i++] = '\r';
> > + buf[i] = '\r';
> > buf[i++] = '\n';
>
> '\r' character is now overwritten by '\n' character.
>
> --HPS
>
--
Tomoaki AOKI
38080, U+3000) seems to be treated
as regular character, not as space.
Possibly, any other space characters in code points other than CJK
could have problem, but not at all tested. Sorry.
Anyway, thanks in great advance!
--
Tomoaki AOKI
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
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
>
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.
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
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
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
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
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
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206
--
Tomoaki AOKI
201 - 246 of 246 matches
Mail list logo
