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 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
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 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.
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 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
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
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
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
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
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
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
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
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
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
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
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
d zsh is `exec`'ed from tcsh.
if ( -X zsh && -f ~/.Use_zsh ) exec zsh
--
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
> > 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
}
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?
> >
> >
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
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
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
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Â
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
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
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
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
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
).
>
> 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, 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
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
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
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
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: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
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
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
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*
. 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 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:
> >>
> >>&
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
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
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
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
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:
> >>
> >>
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, 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
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
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
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
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
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
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
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
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
I've recently found this thread on forums.freebsd.org. [1]
[1]
https://forums.freebsd.org/threads/new-system-hardware-supported.93574/
--
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
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
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
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 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:
> >
n/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe
l: #11 0x80ef5b7b at
> >> Xfast_syscall+0xfb
> >>
> >>
> >> Is the slow transfers user error?
> >>
> >
> > It's likely due to the slow UFS issue...
> >
> > Warner
> >
> The Transcend ssd is formated ZFS, I use
221 https://www.youtube.com/watch?v=IbCHE-hONow
> ___
> 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"
>
and trouble.
> Bridger
> ___
> 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"
>
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
, 2 Feb 2018 12:38:47 +0100
Michael Gmelin wrote:
>
>
> On Fri, 2 Feb 2018 20:23:32 +0900
> Tomoaki AOKI wrote:
>
> > Not 100% sure but possibly some (one?) EisaId are (is) missing in
> > ibm_ids definition of sys/dev/acpi_support/acpi_ibm.c.
> > Currently i
ry tip).
>
>
> thanks
>
> Julian
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr.
On Wed, 21 Feb 2018 22:22:08 +0800
Julian Elischer wrote:
> On 21/2/18 7:14 pm, Tomoaki AOKI wrote:
> > Hi.
> >
> > +1. But have one suggestion for format.
> > Something like
> >
> > Broken by: rXXX
> > Broken by: Unknown (Bugfix but the r
fore?
>
> Thanks,
>
> Kyle Evans
> ___
> 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"
8 at 10:16 AM, Peter Lei wrote:
> >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> >>> Hi.
> >>> For problem 2, try reverting r331241 alone.
> >>> This worked for my ThinkPad T420.
> >>
> >>
> >> I also hit this after updating to la
ot issues reported
> recently.
>
> Please help test, and report back (both successes and failures).
>
> Thanks,
>
> Glen
>
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/
4-390.59
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
>
> --
> -
> Alex.
> ___
> freebsd-current@fr
On Sun, 3 Jun 2018 15:20:24 +0200
Mateusz Guzik wrote:
> On Sun, Jun 3, 2018 at 2:42 PM, Tomoaki AOKI
> wrote:
>
> > This is caused by r334533 and/or r334534 (memset-related changes).
> > sysutils/lsof is also affected.
> >
> > You should revert r334533 and
;next boot and later", IIUC.
The latest patch is for head and stable/12. Applicable on top
of /usr/src.
Patch for stable/11 is NOT tested / maintained for more than one year,
so possibly doesn't apply / work anymore.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940
--
T
and write all this so that FreeBSD performs EFI/ESP
> > > booting
> > > in a more intuitive way. It seems odd to me, that I can install Windows,
> > > and
> > > it'll add FreeBSD to the (efi) boot menu, but not vis-a-vis.
> > >
> > > --Chris
> > >> > > > > Thanks again, Andrey. Greatly appreciated! :)
> > >> > >
>
>
> ___
> 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"
>
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> of commitment to it. I'll see if I can't take it on myself. :)
>
> Thanks again! :)
>
> --Chris
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>
line in src.conf didn't help.
*Combination of the above two didn't help, too (at r364788).
*There are two root pools in different physical drive.
stable/12 on nvd0 (primary) and head on ada0 (secondary).
*GENERIC-NODEBUG based (added options CAM_IOSCHED_DYNAMIC)
Filed PR.
Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249147
On Fri, 4 Sep 2020 22:03:01 +0900
Tomoaki AOKI wrote:
> Hi.
>
> Encountering boot failure with fatal trap 18 on boot,
> happening at (maybe)
return error;
> + if (error != 0)
> + return (error);
>
> IWM_LOCK(sc);
> if (ic->ic_nrunning > 0) {
> @@ -4435,7 +4435,7 @@ iwm_media_change(struct ifnet *ifp)
> iwm_init(sc);
> }
> IWM_UNLOCK(sc);
>
On Thu, 10 Sep 2020 10:22:05 +
"Bjoern A. Zeeb" wrote:
> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
>
> > This breaks at least iwm. (Other drivers not tested.)
> >
> > Messages below are repeatedly shown and no carrier detected.
> > Manual
info/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Fri, 11 Sep 2020 14:20:22 +
"Bjoern A. Zeeb" wrote:
> On 11 Sep 2020, at 14:02, Tomoaki AOKI wrote:
>
> > On Thu, 10 Sep 2020 10:22:05 +
> > "Bjoern A. Zeeb" wrote:
> >
> >> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
> >
; been generated. We were getting close to publishing the final schedule
> >>> when
> >>> this thread popped up, though, since it is finally feeling like it will
> >>> be
> >>> real soon. I also had hoped to refine things so that existing developers
> >>> and users would have only minor disruption at the cut over because things
> >>> were well documented.
> >>>
> >>> And once we have all the basics of phase 1 (which is just going to be 'do
> >>> FreeBSD's current workflow in git, making minimal changes initially),
> >>> we'll
> >>> start on the refinements to the workflow that will help improve the
> >>> quality
> >>> of code, make it easier to integrate changes, etc. There's quite the
> >>> diversity of views and opinions in the larger open source world on what
> >>> best practices are here, with different projects doing different things.
> >>> It
> >>> will take some time for the project to adopt these new tools, new work
> >>> flows and realize that in some cases a diversity of tools can be an
> >>> advantage rather than a liability. This may be especially true as the
> >>> needs
> >>> of the ports tree differ from the needs of the src tree and what's
> >>> optimal
> >>> for one may not work too well for the other.
> >>>
> >>> So a lot of my reaction in the past few days has been frustration that
> >>> this
> >>> came up about a week before we had all our ducks in a row to talk about
> >>> it
> >>> effectively and talk about the transition plans. I apologize for being so
> >>> snarky about it.
> >>>
> >>> Warner
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to "
> >>> freebsd-current-unsubscr...@freebsd.org"
> >>>
> >>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
s://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> The need of the many outweighs the greed of the few.
>
>
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-cu
Forgot to mention here.
As I already mentioned on bugzilla, this problem is fixed at r365894.
Thanks again, Ryan and Matthew!
On Sun, 6 Sep 2020 18:02:40 +0900
Tomoaki AOKI wrote:
> Filed PR.
> Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
>
> https://bugs
uido Falsi
> ___
> 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"
--
Tomoaki AOKI
_
On Sat, 7 Nov 2020 19:24:02 -0700
Warner Losh wrote:
> On Sat, Nov 7, 2020 at 5:43 PM Tomoaki AOKI
> wrote:
>
> > On Sun, 8 Nov 2020 00:22:26 +0100
> > Guido Falsi wrote:
> >
> > > On 07/11/20 17:20, Gary Jennejohn wrote:
> > > > It seems li
> 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"
This happens on stable/12, too.
As a workaround, reverti
gt; iwm0: code ce, frame 2/216 b82c unhandled
> Security policy loaded: MAC/ntpd (mac_ntpd)
>
> ___
> 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"
Hi.
You would be bitten by a known issue with ThinkPad P50s described in
rtsx (4) man page.
Try adding dev.rtsx.0.inversion=1 in /boot/loader.conf.
Unfortunately, man pages for head cannot read via FreeBSD project top
page. So read raw manpage data with svn commit mail archive below.
https://lists.freebsd.org/pipermail/svn-src-head/2020-November/141972.html
In addition, write attempts to write-protected card causes 100% panic.
For example, sysutils/automount trys fsck on mount.
This causes 100% panic (not only rtsx, but every adapters), avoidable
by write-protect off.
--
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
eep multiple branch.
Of course, if you need only one branch (e.g. main) and want to follow
existing official example, /usr/src is the only place to clone repo to.
>
> --
> Herbert
> ___
>
# vbe_max_resolution=1280x800
> >
> > This works -- boots OK, and I see kernel probe (&c.) messages; this is a
> > text console (mostly blue text; some white, against a dark background.
> > It's a medium-light blue, so it's easy enough to read (unlike a navy
> > blue, for example).
> >
> >
?
>
> Kind regards and thank you very much in advance,
>
> O. Hartmann
>
+1.
IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not.
Unfortunately, I currently don't have enough time to bisect
further. :-(
As stable/13 is
s://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-c
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
> based, so there
> is no chance to attach PS/2 equipment :-(
>
> Kind regards,
>
> oh
I usually try these kind of things though /boot/loader.conf whenever
possible.
If you prefer usbhid drivers, add BOTH
hw.usb.usbhid.enable=1
usbhid_load="YES"
lines to l
stinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
Hi.
Unclear if it's related or not, but my ThinkPad P52 often refuses
keyboard input on loader.efi and boot1.efi (boot1.efi as bootx64.efi).
I
git c7e6cb9e08d6 and 0b373f26bea1 is
installed, nvidia-driver SHOULD ALWAYS FAIL until world after git
6827435548d2 is installed.
This is the primary reason why I don't like/don't use current
PORTS_MODULES approach. (Not all modules are mandatory to boot.)
Building PORTS_MODULES would
rpose when it landed).
And one more.
If you insert write-protected card and then mount it as writable,
it SHOULD certainly crash the system.
It's not a rtsx driver issue, but promised to happen.
I've encountered the problem on USB card readers, too.
>
> --
> // Lev Serebryakov
> __
101 - 200 of 246 matches
Mail list logo
