Re: [current-users] Re: Best practice for setting up disks for ZFS on NetBSD
As far as I understand it, ZFS vdevs have their own ID, so they can be laid out correctly no matter the OS device each are discovered on ... wouldn't that make a raidframe wrapper redundant? it would also mean the zpool vdevs couldn't be used on other systems that understand ZFS because they're unlikely to understand raidframe ... Regards, Malcolm On Thu, 3 Dec 2020, at 12:00, HIROSE yuuji wrote: > >> On Thu, 3 Dec 2020 00:30:17 + > >> a...@absd.org (David Brownlee) said: > > > > What would be the best practice for setting up disks to use under ZFS > > on NetBSD, with particular reference to handling renumbered devices? > > > > The two obvious options seem to be: > > > > - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7) > > - Entire disk (eg: /dev/wd0 or /dev/sd4) > > > > Creating raidframe for thoset wedges or disks and "raidframe -A yes" > would be helpful to create stable device-name for zpool. > > I prefer to use dummy raidframe even if the host has only single device > to make HDD/SSDs bootable when they attached to USB-SATA adapters. > > --yuuji > -- Malcolm Herbert m...@mjch.net
daily CVS update output
Updating src tree: P src/doc/3RDPARTY P src/doc/CHANGES P src/doc/HACKS P src/etc/security P src/external/bsd/pkg_install/dist/add/perform.c P src/external/bsd/pkg_install/dist/admin/check.c P src/external/bsd/pkg_install/dist/admin/main.c P src/external/bsd/pkg_install/dist/admin/pkg_admin.1 P src/external/bsd/pkg_install/dist/create/perform.c P src/external/bsd/pkg_install/dist/create/pl.c P src/external/bsd/pkg_install/dist/info/perform.c P src/external/bsd/pkg_install/dist/lib/iterate.c P src/external/bsd/pkg_install/dist/lib/lib.h P src/external/bsd/pkg_install/dist/lib/license.c P src/external/bsd/pkg_install/dist/lib/pkgdb.c P src/external/bsd/pkg_install/dist/lib/plist.c P src/external/bsd/pkg_install/dist/lib/version.h P src/external/bsd/pkg_install/dist/lib/vulnerabilities-file.c P src/external/bsd/pkg_install/lib/Makefile P src/lib/libc_vfp/vfpdf.S P src/lib/libc_vfp/vfpsf.S P src/share/man/man5/daily.5 P src/share/man/man5/security.conf.5 P src/sys/arch/arm/cortex/a9tmr.c P src/sys/arch/mac68k/mac68k/pram.c P src/sys/net/if_sppp.h P src/usr.sbin/etcupdate/etcupdate P src/usr.sbin/sysinst/label.c P src/usr.sbin/sysinst/partitions.h Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38300272 Dec 3 03:03 ls-lRA.gz
Re: Best practice for setting up disks for ZFS on NetBSD
>> On Thu, 3 Dec 2020 00:30:17 + >> a...@absd.org (David Brownlee) said: > > What would be the best practice for setting up disks to use under ZFS > on NetBSD, with particular reference to handling renumbered devices? > > The two obvious options seem to be: > > - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7) > - Entire disk (eg: /dev/wd0 or /dev/sd4) > Creating raidframe for thoset wedges or disks and "raidframe -A yes" would be helpful to create stable device-name for zpool. I prefer to use dummy raidframe even if the host has only single device to make HDD/SSDs bootable when they attached to USB-SATA adapters. --yuuji
Re: Best practice for setting up disks for ZFS on NetBSD
hello David. In the absence of other variables, I'd suggest using wedges. That gives you the ability to replace disks that go bad with differently sized disks in the future, while still retaining your zfs vdev sizes, something zfs likes a lot. Also, I'm pretty sure zfs recovers fine from wedge renumbering, at least it does under FreeBSD, much like raidframe does when it's autoconfiguring. I should say that while I have a lot of experience with zfs under FreeBSD, I've not used it much under NetBSD, mostly due to its instability, which is apparently now becoming much less of a problem -- something I'm very happy about. Anyway, hope that helps. -Brian On Dec 3, 12:30am, David Brownlee wrote: } Subject: Best practice for setting up disks for ZFS on NetBSD } What would be the best practice for setting up disks to use under ZFS } on NetBSD, with particular reference to handling renumbered devices? } } The two obvious options seem to be: } } - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7) } - Entire disk (eg: /dev/wd0 or /dev/sd4) } } (I'm going to skip disklabel partitions as they are size limited and } also encounter other issues with zpool import) } } Creating disks with single zfs wedges has the advantage of marking } each disk as "hey, zfs in use here", so it should be less likely to } accidentally overwrite it with something else, the wedge layer is } light enough to not add any measurable overhead, and providing the zfs } partition is aligned correctly zfs should be getting close enough to } "the real disk" } } Using the entire disk seems simpler, and the system (including tools } like iostat) are not suddenly cluttered by (in this case) a set of } unnecessary dk entries. } } In the event of disk renumbering both are thrown out, needing a "zfs } export foo;zfs import foo" to recover. Is there some way to avoid } that? } } David >-- End of excerpt from David Brownlee
Best practice for setting up disks for ZFS on NetBSD
What would be the best practice for setting up disks to use under ZFS on NetBSD, with particular reference to handling renumbered devices? The two obvious options seem to be: - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7) - Entire disk (eg: /dev/wd0 or /dev/sd4) (I'm going to skip disklabel partitions as they are size limited and also encounter other issues with zpool import) Creating disks with single zfs wedges has the advantage of marking each disk as "hey, zfs in use here", so it should be less likely to accidentally overwrite it with something else, the wedge layer is light enough to not add any measurable overhead, and providing the zfs partition is aligned correctly zfs should be getting close enough to "the real disk" Using the entire disk seems simpler, and the system (including tools like iostat) are not suddenly cluttered by (in this case) a set of unnecessary dk entries. In the event of disk renumbering both are thrown out, needing a "zfs export foo;zfs import foo" to recover. Is there some way to avoid that? David
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 03:07:55PM -0800, Paul Goyette wrote: > This is just getting too complicated. Too many manual steps, and too > many changes to too many long-established procedures. Yeah, I'm sorry that you spent too much time on this. Actually, the easiest way is to just: cd /usr/pkgsrc/pkgtools/pkg_install make USE_CWRAPPERS=no install install -c /usr/pkg/sbin/pkg_* /usr/sbin Then you don't have to change anything else. The rest of the thread contains just options for power users (that want to stay back on the old location, or don't want to replace /usr/sbin/pkg_*). Thomas
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 02:57:01PM -0800, Paul Goyette wrote:
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
The new default for the pkgsrc database (which contains information
about all installed packages) in pkgsrc-HEAD has changed from
/var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since some people have trouble installing a new pkg_install from
pkgsrc (because it depends on cwrappers, which depends on pkg_install)
- the easiest way to get a new pkg_install from pkgsrc is this:
cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
That will build pkg_install without cwrappers.
I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
this succeeds to avoid further problems.
(I'm one of the "somple haqve trouble installing..." mentioned above!)
Well, that's a bit of a problem for me. I'm building everything in
a chroot to a freshly-created sandbox (from sysutils/mksandbox) and
/usr is a read-only null-mount file-system. So I cannot copy the
pkgsrc images to the "real" system. (And I'm not sure I would want
to be able to affect the "real" system's /usr/bin/ from within the
chroot sandbox.)
You can cp it outside the sandbox... and use pkg_install.conf if you
want to keep using the old database directory.
This is just getting too complicated. Too many manual steps, and too
many changes to too many long-established procedures.
It sounds to me like this was not very well thought out and not very
well tested (in sufficient environments) before the change was made.
FWIW, I also don't remember ever seeing any discussion of this change
being made on any non-pkgsrc lists. (If it was discusssed, and I
simply missed it, skip this paragraph!) Since you've changed defaults
withing programs in the base system, a discussion on tech-userlevel
would probably have been appropriate (in addition to any relevant
pkgsrc lists).
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 02:57:01PM -0800, Paul Goyette wrote:
> On Wed, 2 Dec 2020, Thomas Klausner wrote:
>
> > On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
> > > The new default for the pkgsrc database (which contains information
> > > about all installed packages) in pkgsrc-HEAD has changed from
> > > /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
> >
> > Since some people have trouble installing a new pkg_install from
> > pkgsrc (because it depends on cwrappers, which depends on pkg_install)
> > - the easiest way to get a new pkg_install from pkgsrc is this:
> >
> > cd /usr/pkgsrc/pkgtools/pkg_install
> > make USE_CWRAPPERS=no install
> >
> > That will build pkg_install without cwrappers.
> >
> > I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
> > this succeeds to avoid further problems.
>
> (I'm one of the "somple haqve trouble installing..." mentioned above!)
>
> Well, that's a bit of a problem for me. I'm building everything in
> a chroot to a freshly-created sandbox (from sysutils/mksandbox) and
> /usr is a read-only null-mount file-system. So I cannot copy the
> pkgsrc images to the "real" system. (And I'm not sure I would want
> to be able to affect the "real" system's /usr/bin/ from within the
> chroot sandbox.)
You can cp it outside the sandbox... and use pkg_install.conf if you
want to keep using the old database directory.
Thomas
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
The new default for the pkgsrc database (which contains information
about all installed packages) in pkgsrc-HEAD has changed from
/var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since some people have trouble installing a new pkg_install from
pkgsrc (because it depends on cwrappers, which depends on pkg_install)
- the easiest way to get a new pkg_install from pkgsrc is this:
cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
That will build pkg_install without cwrappers.
I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
this succeeds to avoid further problems.
(I'm one of the "somple haqve trouble installing..." mentioned above!)
Well, that's a bit of a problem for me. I'm building everything in
a chroot to a freshly-created sandbox (from sysutils/mksandbox) and
/usr is a read-only null-mount file-system. So I cannot copy the
pkgsrc images to the "real" system. (And I'm not sure I would want
to be able to affect the "real" system's /usr/bin/ from within the
chroot sandbox.)
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since some people have trouble installing a new pkg_install from
pkgsrc (because it depends on cwrappers, which depends on pkg_install)
- the easiest way to get a new pkg_install from pkgsrc is this:
cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
That will build pkg_install without cwrappers.
I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
this succeeds to avoid further problems.
I also found out that pbulk.conf includes the path to the database, so
please update that as well (pkgdb variable).
Cheers,
Thomas
Re: [HEADS UP] pkgsrc default database directory changed
Date:Wed, 2 Dec 2020 07:25:48 -0800 (PST) From:Paul Goyette Message-ID: | If one adds tnn's suggested entry to /etc/mk.conf, is it also needed | to apply uwe's update to /etc/pkgpath.conf? Depends what state you leave the system, mk.conf is used when building stuff (and only then), pkgpath.conf is used at run-time (including by /etc/daily). pkg_install.conf is used internally by pkg_install. | One additional series of questions: | | * should anything be changed in postinstall(8) to at least check for |the "correct" location? | * should postinstall(8) attempt to fix it? (probably no) | * should postinstall(8) "obey" the suggested changes to mk.conf and/or |pkgpath.conf? Those I'll leave for someone else to consider. | Finally, I looked, and my system doesn't have any file, anywhere | (other than in source trees) with the name ``pkg_install''. Am I | missing something? Only that pkg_install is just the generic name for the set of pkg_* utilities, none of which is actually called pkg_install. It includes pkg_admin pkg_add pkg_delete pkg_info and pkg_create. For your setup, the versions in /usr/sbin should work fine with an entry in /etc/pkg_install.conf to specify where the database is to live. You probably also need /etc/pkgpath.conf for /etc/daily and mk.conf for the next time you build everything (that or an up to date checkout of HEAD, assuming that you want to use the new default path). kre
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 07:25:48AM -0800, Paul Goyette wrote: > If one adds tnn's suggested entry to /etc/mk.conf, is it also needed > to apply uwe's update to /etc/pkgpath.conf? The advise helps in different use cases: If you follow tnn's advise, you'll keep using the old database location and don't need to change anything else, since the old and new tools will operate on the same location. uwe's advice is needed if you do switch to the new location, and use the pkg_install tools from pkgsrc so that the daily cronjob gets the correct output. If you use the new pkg_install tools from -current (updated a few hours ago) you need neither. > One additional series of questions: > > * should anything be changed in postinstall(8) to at least check for > the "correct" location? > * should postinstall(8) attempt to fix it? (probably no) > * should postinstall(8) "obey" the suggested changes to mk.conf and/or > pkgpath.conf? IMHO postinstall should not do anything. > Finally, I looked, and my system doesn't have any file, anywhere > (other than in source trees) with the name ``pkg_install''. Am I > missing something? I've been running pkgsrc for ~forever without > any (apparent) issues. /etc/pkg_install.conf (documented in pkg_install.conf(5)) is an optional file. There is no default file installed in NetBSD. Thomas
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020 at 10:28, Thomas Klausner wrote:
>
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
>
> This matches the default the bootstrap script had for a long time.
>
> pkgsrc-HEAD will insist on using pkg_install 20200828, which will
> print an error and ask the user to move the existing database to the
> new location. This move is not done automatically by purpose so that
> the administrators will take note.
>
> There is one potential pitfall: you'll have to make sure
> ${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
> will default to the old location until -current and the branches are
> updated).
>
> So please make sure your admin user's PATH has ${PREFIX}/sbin before
> /usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
> /usr/sbin.
>
> There is no change for the existing binary packages, since they do not
> care where the information about the installed packages is stored.
Not wanting to dump more onto releng, but would this be a good reason
to try to get a new release on netbsd-8 and netbsd-9?
(on a related note - thanks to everyone who worked to get this change
and is going to be fielding fallout for a while :)
David
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Valery Ushakov wrote:
On Wed, Dec 02, 2020 at 11:28:41 +0100, Thomas Klausner wrote:
There is one potential pitfall: you'll have to make sure
${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
will default to the old location until -current and the branches are
updated).
So please make sure your admin user's PATH has ${PREFIX}/sbin before
/usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
/usr/sbin.
NetBSD daily cron job uses full paths. They can be changed by adding
pkg_admin=/usr/pkg/sbin/pkg_admin
pkg_info=/usr/pkg/sbin/pkg_info
to /etc/pkgpath.conf
And Tobias Nygren replied:
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since this is about changing a default, it should be mentioned in the
heads-up how to stay on the old path if migration is currently not
convenient. To do this one can add PKG_DBDIR=/var/db/pkg to mk.conf
before the new pkg_install is built.
If one adds tnn's suggested entry to /etc/mk.conf, is it also needed
to apply uwe's update to /etc/pkgpath.conf?
One additional series of questions:
* should anything be changed in postinstall(8) to at least check for
the "correct" location?
* should postinstall(8) attempt to fix it? (probably no)
* should postinstall(8) "obey" the suggested changes to mk.conf and/or
pkgpath.conf?
Finally, I looked, and my system doesn't have any file, anywhere
(other than in source trees) with the name ``pkg_install''. Am I
missing something? I've been running pkgsrc for ~forever without
any (apparent) issues.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 11:28:41 +0100, Thomas Klausner wrote:
> There is one potential pitfall: you'll have to make sure
> ${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
> will default to the old location until -current and the branches are
> updated).
>
> So please make sure your admin user's PATH has ${PREFIX}/sbin before
> /usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
> /usr/sbin.
NetBSD daily cron job uses full paths. They can be changed by adding
pkg_admin=/usr/pkg/sbin/pkg_admin
pkg_info=/usr/pkg/sbin/pkg_info
to /etc/pkgpath.conf
-uwe
Re: cvs update aborted by broken pipe on server
> On Tue, Dec 1, 2020 at 1:44 AM Thomas Mueller wrote: > > Will this problem be relieved when NetBSD repository switches to mercurial, > > and when is the switch to mercurial expected (time estimate)? > You can try this out right now and pull the NetBSD source from > anonhg.netbsd.org. As an added benefit, it is much quicker to pull > updates. > Benny (Siegert) I thought anonhg.netbsd.org was still in testing and not yet ready to replace cvs. I see several branches in anonhg.netbsd.org on the website, which one would I use? Is anonhg.netbsd.org for all releng branches of NetBSD as well as pkgsrc? When I update my NetBSD installations, mercurial will be near the top of my agenda. Tom
Re: [HEADS UP] pkgsrc default database directory changed
Date:Wed, 2 Dec 2020 12:01:08 +0100
From:Thomas Klausner
Message-ID: <20201202110108.7ml5gw3jospli...@yt.nih.at>
| The change is documented here:
|
| http://pkgsrc.org/news/pkgdb-change/
I have been using ${PREFIX}/db now for years, on regular NetBSD.
(It seemed, still seems, kind of silly to have /usr/pkg/pkgdb
as the location - with "pkg" in there twice ... but that is not
important).
To make that work (aside from moving from /var/db) all that was
needed was to put
PKG_DBDIR=/usr/pkg/db
in /etc/pkg_install.conf (that's all I have in that file).
With that, the standard tools, of any reasonable vintage, simply work,
and so there's no need to force the use of the pkgsrc version of the
pkg_* tools. This is a much simpler upgrade path for most
users than waiting upon an upgrade for their release (I don't
see one coming any time soon for NetBSD 6!)
kre
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 11:54:31AM +0100, Tobias Nygren wrote:
> On Wed, 2 Dec 2020 11:28:41 +0100
> Thomas Klausner wrote:
>
> > The new default for the pkgsrc database (which contains information
> > about all installed packages) in pkgsrc-HEAD has changed from
> > /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
>
> Since this is about changing a default, it should be mentioned in the
> heads-up how to stay on the old path if migration is currently not
> convenient. To do this one can add PKG_DBDIR=/var/db/pkg to mk.conf
> before the new pkg_install is built.
Thanks for this note.
Another user already remarked privately that this only affects NetBSD
-- all operating systems using the bootstrap method were already using
${PREFIX}/pkgdb.
The change is documented here:
http://pkgsrc.org/news/pkgdb-change/
Feel free to improve this.
Thanks,
Thomas
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020 11:28:41 +0100
Thomas Klausner wrote:
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since this is about changing a default, it should be mentioned in the
heads-up how to stay on the old path if migration is currently not
convenient. To do this one can add PKG_DBDIR=/var/db/pkg to mk.conf
before the new pkg_install is built.
-Tobias
[HEADS UP] pkgsrc default database directory changed
Hi!
The new default for the pkgsrc database (which contains information
about all installed packages) in pkgsrc-HEAD has changed from
/var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
This matches the default the bootstrap script had for a long time.
pkgsrc-HEAD will insist on using pkg_install 20200828, which will
print an error and ask the user to move the existing database to the
new location. This move is not done automatically by purpose so that
the administrators will take note.
There is one potential pitfall: you'll have to make sure
${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
will default to the old location until -current and the branches are
updated).
So please make sure your admin user's PATH has ${PREFIX}/sbin before
/usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
/usr/sbin.
There is no change for the existing binary packages, since they do not
care where the information about the installed packages is stored.
Cheers,
Thomas
