#
f99f0ee1 |
| 22-May-2024 |
Alexander Leidinger <netchild@FreeBSD.org> |
rc.d: add a service jails config to all base system services
This gives more permissions to services (e.g. network access to services which require this) when they are started as an automatic servic
rc.d: add a service jails config to all base system services
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
show more ...
|
Revision tags: release/13.3.0, release/14.0.0 |
|
#
d0b2dbfa |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
f30f11f8 |
| 05-Mar-2021 |
Chuck Tuffli <chuck@FreeBSD.org> |
wait for device mounts in zpool and dumpon
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
wait for device mounts in zpool and dumpon
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
show more ...
|
Revision tags: release/12.2.0 |
|
#
90802d88 |
| 05-Sep-2020 |
Xin LI <delphij@FreeBSD.org> |
Declare dependency relationship once instead of twice for zpool and zvol.
|
#
0cd66978 |
| 05-Sep-2020 |
Xin LI <delphij@FreeBSD.org> |
Make zpool on GELI work again.
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, i
Make zpool on GELI work again.
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
show more ...
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
a7841850 |
| 27-Aug-2020 |
Cy Schubert <cy@FreeBSD.org> |
/etc/zfs/zpool.cache is the preferred (and new) location of zpool.cache. Check for it first. Only use /boot/zfs/zpool.cache if the /etc/zfs version is not found and good.
Reported by: avg Suggested
/etc/zfs/zpool.cache is the preferred (and new) location of zpool.cache. 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
show more ...
|
#
74e2b24f |
| 26-Aug-2020 |
Cy Schubert <cy@FreeBSD.org> |
As of r364746 (OpenZFS import) existing ZPOOLs are not imported prior to zvol and mountcritlocal resulting in ZVOLs (swap and virtual machine UFS filesystems) being unavailable, leading to boot failu
As of r364746 (OpenZFS import) existing ZPOOLs are not imported 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
show more ...
|