Re: svn commit: r368575 - head/stand/lua

Yes, with pager or it is a bit useless. Sent from my iPhone > On 12. Dec 2020, at 16:10, Kyle Evans wrote: > > On Sat, Dec 12, 2020 at 1:35 AM Toomas Soome wrote: >> >> How about ’show-module-options’? >> >> rgds, >> toomas >> > > I missed that one. My 4th is a bit rusty, but it looks

Re: svn commit: r368575 - head/stand/lua

How about ’show-module-options’? rgds, toomas > On 12. Dec 2020, at 07:57, Kyle Evans wrote: > > Author: kevans > Date: Sat Dec 12 05:57:42 2020 > New Revision: 368575 > URL: https://svnweb.freebsd.org/changeset/base/368575 > > Log: > lualoader: provide module-manipulation commands > >

Re: svn commit: r366626 - head/sbin/reboot

> On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: >> Please note, the remove is done by rc script during the boot. > > But not by the loader(8) as the page used to claim. It confused me how to > avoid the remove, and only

Re: svn commit: r366626 - head/sbin/reboot

Please note, the remove is done by rc script during the boot. Also nextboot.conf not generic configuration file (such as loader.conf or loader.conf.local), but the implementation specific file, part of special feature. That is, one should not assume the presence of nextboot.conf file, make

Re: svn commit: r365643 - head/bin/cp

> On 23. Sep 2020, at 00:50, Warner Losh wrote: > > I think it's a great leap sideways, but I've done cp /dev/null foo to clear > it out for 35 years now... It's why it feels like a workaround. > > Though it is a legit optimization, no matter the feelings. As for clearer, > I'm less sure

Re: svn commit: r365249 - head

> On 2. Sep 2020, at 18:53, Ryan Moeller wrote: > > > On 9/2/20 11:43 AM, Andriy Gapon wrote: >> On 02/09/2020 18:23, Ryan Moeller wrote: >>> On 9/2/20 10:28 AM, Warner Losh wrote: Author: imp Date: Wed Sep 2 14:28:54 2020 New Revision: 365249 URL:

Re: svn commit: r360836 - head/stand/libsa/zfs

> On 9. May 2020, at 11:23, Ronald Klop wrote: > > On Sat, 09 May 2020 09:25:29 +0200, Toomas Soome > wrote: > >> >> >>> On 9. May 2020, at 09:57, Ronald Klop wrote: >>> >>> Hi Toomas, >>> >>> Could this fix this issue >>>

Re: svn commit: r360836 - head/stand/libsa/zfs

> On 9. May 2020, at 09:57, Ronald Klop wrote: > > Hi Toomas, > > Could this fix this issue > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234 ? > > Regards, > Ronald. I doubt a bit unless you have GELI encryption or 4kn disk (which we can not boot with BIOS, only with UEFI).

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 29. Mar 2020, at 09:40, Ruslan Garipov wrote: > >>> >> >> That definitely can be the case. If you do not set any custom values, >> missing tem.* variables would confirm that. >> >> Now, there is still an question, why in your system that allocation does >> fail? > Is there a way I

Re: svn commit: r359408 - head/stand/libsa/zfs

> On 29. Mar 2020, at 00:04, Oliver Pinter wrote: > > > > On Saturday, March 28, 2020, Toomas Soome > wrote: > Author: tsoome > Date: Sat Mar 28 21:50:27 2020 > New Revision: 359408 > URL: https://svnweb.freebsd.org/changeset/base/359408 >

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 28. Mar 2020, at 08:07, Alexey Dokuchaev wrote: > > On Sat, Mar 14, 2020 at 06:36:03AM +, Toomas Soome wrote: >> New Revision: 358989 >> URL: https://svnweb.freebsd.org/changeset/base/358989 >> >> Log: >> loader: add comconsole implementation on top of SIO protocol >> >> [...] >>

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 27. Mar 2020, at 16:39, Ruslan Garipov wrote: > > On 3/14/2020 11:36 AM, Toomas Soome wrote: >> Author: tsoome >> Date: Sat Mar 14 06:36:03 2020 >> New Revision: 358989 >> URL: https://svnweb.freebsd.org/changeset/base/358989 >> >> Log: >> loader: add comconsole implementation on top of

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 20. Mar 2020, at 13:29, Tomoaki AOKI wrote: > > > Maybe I got a hint... > COLUMNS and LINES (either `show` on loader prompt or `kenv` on running > system) only appears when I manually set any mode by ex. `mode 0` > on loader prompt. Just viewing current mode by `mode` doesn't affect. >

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 19. Mar 2020, at 14:33, Tomoaki AOKI wrote: > > On Thu, 19 Mar 2020 00:28:59 +0200 > Toomas Soome mailto:tso...@me.com>> wrote: > >> >> >>> On 18. Mar 2020, at 20:41, Ruslan Garipov wrote: >>> >>> On 3/18/2020 10:29 PM,

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 18. Mar 2020, at 20:41, Ruslan Garipov wrote: > > On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: >> >> >>> On 18. Mar 2020, at 18:40, Ruslan Garipov wrote: >>> >>> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >>&g

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

> On 18. Mar 2020, at 18:40, Ruslan Garipov wrote: > > On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >> Hi! Thanks for your respond. >> >> Unfortunately, no. >> I'm running on ThinkPad P52, which has no com connector installed. >> No USB serial interface connected. >> >> `efi-show -g global -v

Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

Hi! This means, your system has UART serial device — you can check this from loader prompt: efi-show -g global -v ConOut or with efivar from running system. This would trigger efi console driver to use TERM_EMU, which can be turned off by user and doing that would cause ESC sequences to be

Re: svn commit: r356693 - in head/stand: efi/libefi i386/libi386 libofw uboot/lib

> On 13. Jan 2020, at 20:45, Ian Lepore wrote: > > On Mon, 2020-01-13 at 20:43 +0200, Toomas Soome wrote: >>> On 13. Jan 2020, at 20:31, Ian Lepore wrote: >>> >>> On Mon, 2020-01-13 at 18:22 +, Toomas Soome wrote: Author: tsoome Date: Mon Jan 13 18:22:54 2020 New

Re: svn commit: r356693 - in head/stand: efi/libefi i386/libi386 libofw uboot/lib

> On 13. Jan 2020, at 20:31, Ian Lepore wrote: > > On Mon, 2020-01-13 at 18:22 +, Toomas Soome wrote: >> Author: tsoome >> Date: Mon Jan 13 18:22:54 2020 >> New Revision: 356693 >> URL: https://svnweb.freebsd.org/changeset/base/356693 >> >> Log: >> loader: allocate properly aligned

Re: svn commit: r356031 - head/stand/i386/gptboot

The only limit set by specification is: A minimum of 16,384 bytes of space must be reserved for the GPT Partition Entry Array. >From this size and array entry size we do get 128, but specification does not >limit the max number. rgds, toomas > On 23. Dec 2019, at 00:33, Ian Lepore wrote: >

Re: svn commit: r354435 - head/stand/efi/libefi

> On 7. Nov 2019, at 17:29, Warner Losh wrote: > > > > On Thu, Nov 7, 2019 at 4:17 AM Toomas Soome > wrote: > Author: tsoome > Date: Thu Nov 7 11:17:03 2019 > New Revision: 354435 > URL: https://svnweb.freebsd.org/changeset/base/354435 >

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

> On 4. Nov 2019, at 03:42, Alexander Motin wrote: > > On 03.11.2019 20:19, Xin Li wrote: >> On 2019-11-03 15:30, Ravi Pokala wrote: >>> Uh >>> >>> I've had a log device in my boot-pool for months, and have booted without >>> issue: >>> >>>[threepio:~] rpokala% zpool status zroot

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

> On 3. Nov 2019, at 19:42, Andriy Gapon wrote: > > On 03/11/2019 15:25, Toomas Soome wrote: >> Author: tsoome >> Date: Sun Nov 3 13:25:47 2019 >> New Revision: 354283 >> URL: https://svnweb.freebsd.org/changeset/base/354283 >> >> Log: >> loader: we do not support booting from pool with log

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

> On 3. Nov 2019, at 22:39, Kevin Bowling wrote: > > I believe this is/was a common configuration, at least the few > spinning disk based systems I have left have a slog. > On boot pool? um. well, I’ll kick out that return then. rgds, toomas > On Sun, Nov 3, 2019 at 10:55 AM Andriy Gapon

Re: svn commit: r353341 - head/cddl/contrib/opensolaris/cmd/zpool

> On 9. Oct 2019, at 14:34, Andriy Gapon wrote: > > Author: avg > Date: Wed Oct 9 11:34:16 2019 > New Revision: 353341 > URL: https://svnweb.freebsd.org/changeset/base/353341 > > Log: > zfs: document large_dnode feature > > The text is copied from illumos. > The conversion to mdoc is

Re: svn commit: r352421 - head/stand/libsa

> On 17 Sep 2019, at 11:56, Konstantin Belousov wrote: > > On Mon, Sep 16, 2019 at 08:28:09PM +, Toomas Soome wrote: >> Author: tsoome >> Date: Mon Sep 16 20:28:08 2019 >> New Revision: 352421 >> URL: https://svnweb.freebsd.org/changeset/base/352421 >> >> Log: >> loader: Malloc(0)

Re: svn commit: r350444 - head/stand/efi/loader

hi! efihttp is also using network, is it intentionally left untouched? rgds, toomas > On 30 Jul 2019, at 17:54, Ruslan Bukin wrote: > > Author: br > Date: Tue Jul 30 14:54:18 2019 > New Revision: 350444 > URL: https://svnweb.freebsd.org/changeset/base/350444 > > Log: > Fix EFI loader build

Re: svn commit: r347953 - head/cddl/contrib/opensolaris/cmd/zfs

> On 18 May 2019, at 15:37, Alexey Dokuchaev wrote: > > On Sat, May 18, 2019 at 12:27:22PM +, Allan Jude wrote: >> New Revision: 347953 >> URL: https://svnweb.freebsd.org/changeset/base/347953 >> >> Log: >> MFV/ZoL: `zfs userspace` ignored all unresolved UIDs after the first >> >>

Re: svn commit: r344569 - in head/cddl/contrib/opensolaris: cmd/zfs lib/libzfs/common

> On 26 Feb 2019, at 23:02, Cy Schubert wrote: > > In message , Fatih Acar > writes: >> This is a multi-part message in MIME format. >> --6A54CE5B28D823DCB8C41577 >> Content-Type: text/plain; charset=utf-8 >> Content-Transfer-Encoding: 8bit >> >> On 2/26/19 5:36 PM, Cy Schubert

Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

> On 20 Feb 2019, at 09:56, Alexey Dokuchaev wrote: > > On Tue, Feb 19, 2019 at 06:43:28PM -0500, Shawn Webb wrote: >> At the risk of painting a bikeshed a lovely color of neon purple, I'm >> curious about if/how these types of commits get merged upstream to >> (OpenZFS|Illumos|ZFS On

Re: svn commit: r344238 - head/stand/common

> On 18 Feb 2019, at 18:25, Warner Losh wrote: > > > > On Mon, Feb 18, 2019 at 7:31 AM Ian Lepore > wrote: > On Mon, 2019-02-18 at 15:09 +0200, Toomas Soome wrote: > > > On 18 Feb 2019, at 01:32, Ian Lepore wrote: > > > > > > Author: ian > > > Date: Sun Feb 17

Re: svn commit: r344238 - head/stand/common

> On 18 Feb 2019, at 01:32, Ian Lepore wrote: > > Author: ian > Date: Sun Feb 17 23:32:09 2019 > New Revision: 344238 > URL: https://svnweb.freebsd.org/changeset/base/344238 > > Log: > Restore loader(8)'s ability for lsdev to show partitions within a bsd slice. > > I'm pretty sure this

Re: svn commit: r339959 - head/stand/i386/libi386

I forgot to note imp, sorry… rgds, toomas > On 31 Oct 2018, at 18:42, Toomas Soome wrote: > > Author: tsoome > Date: Wed Oct 31 16:42:40 2018 > New Revision: 339959 > URL: https://svnweb.freebsd.org/changeset/base/339959 > > Log: > loader: issue edd probe before legacy ah=08 and detect no

Re: svn commit: r339673 - head/stand/libsa

> On 24 Oct 2018, at 02:11, Konstantin Belousov wrote: > > Author: kib > Date: Tue Oct 23 23:11:38 2018 > New Revision: 339673 > URL: https://svnweb.freebsd.org/changeset/base/339673 > > Log: > Fix stand/ build after r339671. > > ffs_subr.c requires calculate_crc32c() from libkern.

Re: svn commit: r337878 - head/stand/i386/libi386

> On 16 Aug 2018, at 16:03, Warner Losh wrote: > > > > On Thu, Aug 16, 2018 at 1:10 AM, Toomas Soome > wrote: > > > > On 16 Aug 2018, at 09:59, John Baldwin wrote: > > > > On 8/15/18 11:59 PM, Warner Losh wrote: > >> > >> > >> On Wed, Aug 15, 2018 at 4:28 PM,

Re: svn commit: r337878 - head/stand/i386/libi386

> On 16 Aug 2018, at 09:59, John Baldwin wrote: > > On 8/15/18 11:59 PM, Warner Losh wrote: >> >> >> On Wed, Aug 15, 2018 at 4:28 PM, Ian Lepore > > wrote: >> >>On Wed, 2018-08-15 at 22:25 +, Toomas Soome wrote: >>> Author: tsoome >>> Date: Wed Aug 15

Re: svn commit: r337271 - head/stand/i386/libi386

> On 4 Aug 2018, at 11:54, Xin Li wrote: > > Hi, Cy, > > On 8/3/18 12:11, Cy Schubert wrote: >> Author: cy >> Date: Fri Aug 3 19:11:00 2018 >> New Revision: 337271 >> URL: https://svnweb.freebsd.org/changeset/base/337271 >> >> Log: >> Some drives report a geometry that is inconsisetent

Re: svn commit: r337231 - head/stand/efi/loader

> On 3 Aug 2018, at 11:32, Warner Losh wrote: > > Any reason why efipart_inithandles() should even return an error in this > case? Seems to cause us nothing but trouble so we have to filter some, but > not all errors which strikes me as a bad design. We should only return errors > for real

Re: svn commit: r336532 - in head/stand: . common i386 i386/loader i386/zfsboot i386/zfsloader sparc64 sparc64/loader sparc64/zfsloader

> On 20 Jul 2018, at 11:00, Andriy Gapon wrote: > > On 20/07/2018 08:17, Warner Losh wrote: >> Provide a symbolic link from zfsloader >> to loader so people who have not upgraded their boot blocks are not >> affected > > I am not sure that ZFS boot blocks can handle symbolic links... > I

Re: svn commit: r336017 - in head: include/rpcsvc lib/libutil libexec/rpc.rquotad sys/cddl/contrib/opensolaris/uts/common/fs/zfs usr.bin/quota

Hi! Unfortunately this patch is not quite correct regarding how you define the RPC interfaces. The versioning in RPC is to specify the interface, much like versioning in shared library. If you have RPC program version 1, exposing functions get_quota() and get_active_quota(), and you want to