<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/libexec/rc/rc.d/zpool, branch main</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>rc.d/zpool: change mountcritlocal dep from BEFORE to REQUIRE</title>
<updated>2025-06-13T15:47:25+00:00</updated>
<author>
<name>Siva Mahadevan</name>
<email>me@svmhdvn.name</email>
</author>
<published>2025-03-14T15:52:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=900bc0206348a439b3a0625a7239cb87a2dc27c5'/>
<id>900bc0206348a439b3a0625a7239cb87a2dc27c5</id>
<content type='text'>
In cases where the `/boot` directory is mounted from a different disk,
`/boot/zfs/zpool.cache` will not be found during a `rc.d/zpool`
run. This is because `/etc/fstab` mounts are mounted in
`rc.d/mountcritlocal`, which currently runs AFTER (i.e. `REQUIRE:`)
`rc.d/zpool`.

This change swaps the `rcorder` of `rc.d/zpool`'s dependency on
`mountcritlocal` from `BEFORE:` to `REQUIRE:`. This will ensure that
`/boot` (or even `/etc/` in some configurations) to be visible while
searching for `zpool.cache`.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1614
Closes: https://github.com/freebsd/freebsd-src/pull/1614
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In cases where the `/boot` directory is mounted from a different disk,
`/boot/zfs/zpool.cache` will not be found during a `rc.d/zpool`
run. This is because `/etc/fstab` mounts are mounted in
`rc.d/mountcritlocal`, which currently runs AFTER (i.e. `REQUIRE:`)
`rc.d/zpool`.

This change swaps the `rcorder` of `rc.d/zpool`'s dependency on
`mountcritlocal` from `BEFORE:` to `REQUIRE:`. This will ensure that
`/boot` (or even `/etc/` in some configurations) to be visible while
searching for `zpool.cache`.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1614
Closes: https://github.com/freebsd/freebsd-src/pull/1614
</pre>
</div>
</content>
</entry>
<entry>
<title>rc.d: add a service jails config to all base system services</title>
<updated>2024-05-22T13:41:49+00:00</updated>
<author>
<name>Alexander Leidinger</name>
<email>netchild@FreeBSD.org</email>
</author>
<published>2024-05-22T13:31:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=f99f0ee14e3af81c23150a6a340259ca8a33d01a'/>
<id>f99f0ee14e3af81c23150a6a340259ca8a33d01a</id>
<content type='text'>
This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
service jail.

The sshd patch is important for the sshd-related functionality as
described in the man-page in the service jails part.

The location of the added env vars is supposed to allow overriding them
in rc.conf, and to hard-disable the use of svcj for some parts where it
doesn't make sense or will not work.

Only a subset of all of the services are fully tested (I'm running this
since more than a year with various services started as service jails).
The untested parts should be most of the time ok, in some edge-cases
more permissions are needed inside the service jail.
Differential Revision:	https://reviews.freebsd.org/D40371
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
service jail.

The sshd patch is important for the sshd-related functionality as
described in the man-page in the service jails part.

The location of the added env vars is supposed to allow overriding them
in rc.conf, and to hard-disable the use of svcj for some parts where it
doesn't make sense or will not work.

Only a subset of all of the services are fully tested (I'm running this
since more than a year with various services started as service jails).
The untested parts should be most of the time ok, in some edge-cases
more permissions are needed inside the service jail.
Differential Revision:	https://reviews.freebsd.org/D40371
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove $FreeBSD$: one-line sh pattern</title>
<updated>2023-08-16T17:55:03+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-08-16T17:55:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d0b2dbfa0ecf2bbc9709efc5e20baf8e4b44bbbf'/>
<id>d0b2dbfa0ecf2bbc9709efc5e20baf8e4b44bbbf</id>
<content type='text'>
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
</pre>
</div>
</content>
</entry>
<entry>
<title>wait for device mounts in zpool and dumpon</title>
<updated>2021-04-05T16:25:04+00:00</updated>
<author>
<name>Chuck Tuffli</name>
<email>chuck@FreeBSD.org</email>
</author>
<published>2021-03-05T16:13:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=f30f11f878fe2aa535cd286810d31c92793a3d95'/>
<id>f30f11f878fe2aa535cd286810d31c92793a3d95</id>
<content type='text'>
If the root file system is composed from multiple devices, wait for
devices to be ready before running zpool and dumpon rc scripts.

An example of this is if the bulk of the root file system exists on a
fast device (e.g. NVMe) but the /var directory comes from a ZFS dataset
on a slower device (e.g. SATA). In this case, it is possible that the
zpool import may run before the slower device has finished being probed,
leaving the system in an intermediate state.

Fix is to add root_hold_wait to the zpool and dumpon (which has a
similar issue) rc scripts.

PR:		242189
Reported by:	osidorkin@gmail.com
Reviewed by:	allanjude
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D29101
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the root file system is composed from multiple devices, wait for
devices to be ready before running zpool and dumpon rc scripts.

An example of this is if the bulk of the root file system exists on a
fast device (e.g. NVMe) but the /var directory comes from a ZFS dataset
on a slower device (e.g. SATA). In this case, it is possible that the
zpool import may run before the slower device has finished being probed,
leaving the system in an intermediate state.

Fix is to add root_hold_wait to the zpool and dumpon (which has a
similar issue) rc scripts.

PR:		242189
Reported by:	osidorkin@gmail.com
Reviewed by:	allanjude
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D29101
</pre>
</div>
</content>
</entry>
<entry>
<title>Declare dependency relationship once instead of twice for zpool</title>
<updated>2020-09-05T00:45:46+00:00</updated>
<author>
<name>Xin LI</name>
<email>delphij@FreeBSD.org</email>
</author>
<published>2020-09-05T00:45:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=90802d88a57c6c86b4d48bbee8d14ed2fc80c107'/>
<id>90802d88a57c6c86b4d48bbee8d14ed2fc80c107</id>
<content type='text'>
and zvol.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
and zvol.
</pre>
</div>
</content>
</entry>
<entry>
<title>Make zpool on GELI work again.</title>
<updated>2020-09-04T23:36:43+00:00</updated>
<author>
<name>Xin LI</name>
<email>delphij@FreeBSD.org</email>
</author>
<published>2020-09-04T23:36:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=0cd669785de0279f61077ad93a74804ad949a057'/>
<id>0cd669785de0279f61077ad93a74804ad949a057</id>
<content type='text'>
After OpenZFS import, zpool auto import behavior was moved to an
explicit "zpool import -a", and the zpool rc.d script was added
as a prerequisite of zvol.

However, in r299839, zvol was added as a prerequisite of dumpon,
making it to start very early and before all 'disks' providers.
At this time, dumping on a zvol is not supported, so remove this
requirement and make zpool depend on disks to allow zpool on
full disk encryption work.

Reviewed by:		allanjude
Differential Revision:	https://reviews.freebsd.org/D26333
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After OpenZFS import, zpool auto import behavior was moved to an
explicit "zpool import -a", and the zpool rc.d script was added
as a prerequisite of zvol.

However, in r299839, zvol was added as a prerequisite of dumpon,
making it to start very early and before all 'disks' providers.
At this time, dumping on a zvol is not supported, so remove this
requirement and make zpool depend on disks to allow zpool on
full disk encryption work.

Reviewed by:		allanjude
Differential Revision:	https://reviews.freebsd.org/D26333
</pre>
</div>
</content>
</entry>
<entry>
<title>/etc/zfs/zpool.cache is the preferred (and new) location of zpool.cache.</title>
<updated>2020-08-27T14:33:46+00:00</updated>
<author>
<name>Cy Schubert</name>
<email>cy@FreeBSD.org</email>
</author>
<published>2020-08-27T14:33:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a784185078e566103b7f8abffc7c0a4a1e813eb1'/>
<id>a784185078e566103b7f8abffc7c0a4a1e813eb1</id>
<content type='text'>
Check for it first. Only use /boot/zfs/zpool.cache if the /etc/zfs
version is not found and good.

Reported by:	avg
Suggested by:	avg, kevans
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Check for it first. Only use /boot/zfs/zpool.cache if the /etc/zfs
version is not found and good.

Reported by:	avg
Suggested by:	avg, kevans
</pre>
</div>
</content>
</entry>
<entry>
<title>As of r364746 (OpenZFS import) existing ZPOOLs are not imported</title>
<updated>2020-08-26T13:13:57+00:00</updated>
<author>
<name>Cy Schubert</name>
<email>cy@FreeBSD.org</email>
</author>
<published>2020-08-26T13:13:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=74e2b24f2c369ffdff2f54fa9f96427cc45ef3a6'/>
<id>74e2b24f2c369ffdff2f54fa9f96427cc45ef3a6</id>
<content type='text'>
prior to zvol and mountcritlocal resulting in ZVOLs (swap and
virtual machine UFS filesystems) being unavailable, leading to
boot failures.

We move the zpool import from zfs to a new zpool script, with the
-N option to avoid mounting datasets while making the ZPOOL's
datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
available for subsequent use for swap (in the zvol rc sript) or
for UFS or other filesystems in fstab(5), mounted by mountcritlocal.

Reviewed by:		freqlabs (previous version)
Differential Revision:	https://reviews.freebsd.org/D26185
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
prior to zvol and mountcritlocal resulting in ZVOLs (swap and
virtual machine UFS filesystems) being unavailable, leading to
boot failures.

We move the zpool import from zfs to a new zpool script, with the
-N option to avoid mounting datasets while making the ZPOOL's
datasets available for "legacy" mount (mountpoint=legacy) and ZVOLs
available for subsequent use for swap (in the zvol rc sript) or
for UFS or other filesystems in fstab(5), mounted by mountcritlocal.

Reviewed by:		freqlabs (previous version)
Differential Revision:	https://reviews.freebsd.org/D26185
</pre>
</div>
</content>
</entry>
</feed>
