dracut: use /bin/sh instead of bash as the intepreter
Despite that dracut has a hard dependency on bash,
its modules doesn't, dracut only has a hard dependency on bash for
module-setup (on a fully usable machine). Inside initramfs, dracut
allows users choose from a list of handful other shells, e.g. bash,
busybox, dash, mkfsh.
In fact, my local machine's initramfs is being built with dash,
and it's functional for a very long time.
Before 64025fa3a (Silence 'make checkbashisms', 2020-08-20), we also
allows our users to have that right, too.
Let's fix the problem 'make checkbashisms' reported and allows our users
to have that right, again.
For 'plymouth' case, let's simply run the command inside the if instead
of checking for the existence of command before running it, because the
status is also failture if plymouth is unavailable.
While we're at it, let's remove an unnecessary fork for grep in
zfs-generator.sh.in and its following complicated 'if elif fi' with
a simple 'case ... esac'.
To support this change, also exclude 90zfs from "make checkbashisms"
because the current CI infrastructure ships an old version of
"checkbashisms", which complains about "command -v", while the current
latest "checkbashisms" thinks it's fine. In the near future, we can
revert that change to "Makefile.am" when CI infrastructure is updated.
Reviewed-by: Gabriel A. Devenyi <gdevenyi@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Closes #11244
2020-11-28 22:02:08 +03:00
|
|
|
#!/bin/sh
|
2022-04-04 23:45:58 +03:00
|
|
|
# shellcheck disable=SC2016,SC1004,SC2154
|
2016-03-31 02:59:15 +03:00
|
|
|
|
2021-04-13 23:37:59 +03:00
|
|
|
grep -wq debug /proc/cmdline && debug=1
|
|
|
|
|
[ -n "$debug" ] && echo "zfs-generator: starting" >> /dev/kmsg
|
Use a different technique to detect whether to mount-zfs
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes #5157
Closes #5204
2016-10-06 20:26:47 +03:00
|
|
|
|
2016-03-31 02:59:15 +03:00
|
|
|
GENERATOR_DIR="$1"
|
Use a different technique to detect whether to mount-zfs
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes #5157
Closes #5204
2016-10-06 20:26:47 +03:00
|
|
|
[ -n "$GENERATOR_DIR" ] || {
|
|
|
|
|
echo "zfs-generator: no generator directory specified, exiting" >> /dev/kmsg
|
|
|
|
|
exit 1
|
|
|
|
|
}
|
2016-03-31 02:59:15 +03:00
|
|
|
|
2022-04-04 23:45:58 +03:00
|
|
|
# shellcheck source=zfs-lib.sh.in
|
contrib/dracut: 90: mount essential datasets under root
This partly mirrors what the i-t script does (though that mounts all
children, recursively) ‒ /etc, /usr, /lib*, and /bin are all essential,
if present, to successfully invoke the real init, which will then mount
everything else it might need in the right order
The following extreme-case set-up boots w/o issues now:
/ zoot zfs rw,relatime,xattr,noacl
├─/etc zoot/etc zfs rw,relatime,xattr,noacl
├─/usr zoot/usr zfs rw,relatime,xattr,noacl
│ └─/usr/local zoot/usr/local zfs rw,relatime,xattr,noacl
├─/var zoot/var zfs rw,relatime,xattr,noacl
│ ├─/var/lib zoot/var/lib zfs rw,relatime,xattr,noacl
│ ├─/var/log zoot/var/log zfs rw,relatime,xattr,posixacl
│ ├─/var/cache zoot/var/cache zfs rw,relatime,xattr,noacl
│ └─/var/tmp zoot/var/tmp zfs rw,relatime,xattr,noacl
├─/home zoot/home zfs rw,relatime,xattr,noacl
│ └─/home/nab zoot/home/nab zfs rw,relatime,xattr,noacl
├─/boot zoot/boot zfs rw,relatime,xattr,noacl
├─/root zoot/home/root zfs rw,relatime,xattr,noacl
├─/opt zoot/opt zfs rw,relatime,xattr,noacl
└─/srv zoot/srv zfs rw,relatime,xattr,noacl
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #11898
2021-04-13 23:41:10 +03:00
|
|
|
. /lib/dracut-zfs-lib.sh
|
2022-04-04 23:45:58 +03:00
|
|
|
decode_root_args || exit 0
|
contrib/dracut: 90: mount essential datasets under root
This partly mirrors what the i-t script does (though that mounts all
children, recursively) ‒ /etc, /usr, /lib*, and /bin are all essential,
if present, to successfully invoke the real init, which will then mount
everything else it might need in the right order
The following extreme-case set-up boots w/o issues now:
/ zoot zfs rw,relatime,xattr,noacl
├─/etc zoot/etc zfs rw,relatime,xattr,noacl
├─/usr zoot/usr zfs rw,relatime,xattr,noacl
│ └─/usr/local zoot/usr/local zfs rw,relatime,xattr,noacl
├─/var zoot/var zfs rw,relatime,xattr,noacl
│ ├─/var/lib zoot/var/lib zfs rw,relatime,xattr,noacl
│ ├─/var/log zoot/var/log zfs rw,relatime,xattr,posixacl
│ ├─/var/cache zoot/var/cache zfs rw,relatime,xattr,noacl
│ └─/var/tmp zoot/var/tmp zfs rw,relatime,xattr,noacl
├─/home zoot/home zfs rw,relatime,xattr,noacl
│ └─/home/nab zoot/home/nab zfs rw,relatime,xattr,noacl
├─/boot zoot/boot zfs rw,relatime,xattr,noacl
├─/root zoot/home/root zfs rw,relatime,xattr,noacl
├─/opt zoot/opt zfs rw,relatime,xattr,noacl
└─/srv zoot/srv zfs rw,relatime,xattr,noacl
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #11898
2021-04-13 23:41:10 +03:00
|
|
|
|
2021-04-13 23:37:59 +03:00
|
|
|
[ -n "$debug" ] && echo "zfs-generator: writing extension for sysroot.mount to $GENERATOR_DIR/sysroot.mount.d/zfs-enhancement.conf" >> /dev/kmsg
|
Use a different technique to detect whether to mount-zfs
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes #5157
Closes #5204
2016-10-06 20:26:47 +03:00
|
|
|
|
2016-03-31 02:59:15 +03:00
|
|
|
|
contrib: dracut: fix race with root=zfs:dset when necessities required
This had always worked in my testing, but a user on hardware reported
this to happen 100%, and I reproduced it once with cold VM host caches.
dracut-zfs-generator runs as a systemd generator, i.e. at Some
Relatively Early Time; if root= is a fixed dataset, it tries to
"solve [necessities] statically at generation time".
If by that point zfs-import.target hasn't popped (because the import is
taking a non-negligible amount of time for whatever reason), it'll see
no children for the root datase, and as such generate no mounts.
This has never had any right to work. No-one caught this earlier because
it's just that much more convenient to have root=zfs:AUTO, which orders
itself properly.
To fix this, always run zfs-nonroot-necessities.service;
this additionally simplifies the implementation by:
* making BOOTFS from zfs-env-bootfs.service be the real, canonical,
root dataset name, not just "whatever the first bootfs is",
and only set it if we're ZFS-booting
* zfs-{rollback,snapshot}-bootfs.service can use this instead of
re-implementing it
* having zfs-env-bootfs.service also set BOOTFSFLAGS
* this means the sysroot.mount drop-in can be fixed text
* zfs-nonroot-necessities.service can also be constant and always
enabled, because it's conditioned on BOOTFS being set
There is no longer any code generated at run-time
(the sysroot.mount drop-in is an unavoidable gratuitous cp).
The flow of BOOTFS{,FLAGS} from zfs-env-bootfs.service to sysroot.mount
is not noted explicitly in dracut.zfs(7), because (a) at some point it's
just visual noise and (b) it's already ordered via d-p-m.s from z-i.t.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #14690
2023-03-31 19:47:48 +03:00
|
|
|
mkdir -p "$GENERATOR_DIR"/sysroot.mount.d "$GENERATOR_DIR"/dracut-pre-mount.service.d
|
|
|
|
|
|
2016-03-31 02:59:15 +03:00
|
|
|
{
|
|
|
|
|
echo "[Unit]"
|
Use a different technique to detect whether to mount-zfs
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes #5157
Closes #5204
2016-10-06 20:26:47 +03:00
|
|
|
echo "Before=initrd-root-fs.target"
|
2018-07-31 20:15:41 +03:00
|
|
|
echo "After=zfs-import.target"
|
contrib/dracut: 90: mount essential datasets under root
This partly mirrors what the i-t script does (though that mounts all
children, recursively) ‒ /etc, /usr, /lib*, and /bin are all essential,
if present, to successfully invoke the real init, which will then mount
everything else it might need in the right order
The following extreme-case set-up boots w/o issues now:
/ zoot zfs rw,relatime,xattr,noacl
├─/etc zoot/etc zfs rw,relatime,xattr,noacl
├─/usr zoot/usr zfs rw,relatime,xattr,noacl
│ └─/usr/local zoot/usr/local zfs rw,relatime,xattr,noacl
├─/var zoot/var zfs rw,relatime,xattr,noacl
│ ├─/var/lib zoot/var/lib zfs rw,relatime,xattr,noacl
│ ├─/var/log zoot/var/log zfs rw,relatime,xattr,posixacl
│ ├─/var/cache zoot/var/cache zfs rw,relatime,xattr,noacl
│ └─/var/tmp zoot/var/tmp zfs rw,relatime,xattr,noacl
├─/home zoot/home zfs rw,relatime,xattr,noacl
│ └─/home/nab zoot/home/nab zfs rw,relatime,xattr,noacl
├─/boot zoot/boot zfs rw,relatime,xattr,noacl
├─/root zoot/home/root zfs rw,relatime,xattr,noacl
├─/opt zoot/opt zfs rw,relatime,xattr,noacl
└─/srv zoot/srv zfs rw,relatime,xattr,noacl
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #11898
2021-04-13 23:41:10 +03:00
|
|
|
echo
|
2016-03-31 02:59:15 +03:00
|
|
|
echo "[Mount]"
|
contrib: dracut: fix race with root=zfs:dset when necessities required
This had always worked in my testing, but a user on hardware reported
this to happen 100%, and I reproduced it once with cold VM host caches.
dracut-zfs-generator runs as a systemd generator, i.e. at Some
Relatively Early Time; if root= is a fixed dataset, it tries to
"solve [necessities] statically at generation time".
If by that point zfs-import.target hasn't popped (because the import is
taking a non-negligible amount of time for whatever reason), it'll see
no children for the root datase, and as such generate no mounts.
This has never had any right to work. No-one caught this earlier because
it's just that much more convenient to have root=zfs:AUTO, which orders
itself properly.
To fix this, always run zfs-nonroot-necessities.service;
this additionally simplifies the implementation by:
* making BOOTFS from zfs-env-bootfs.service be the real, canonical,
root dataset name, not just "whatever the first bootfs is",
and only set it if we're ZFS-booting
* zfs-{rollback,snapshot}-bootfs.service can use this instead of
re-implementing it
* having zfs-env-bootfs.service also set BOOTFSFLAGS
* this means the sysroot.mount drop-in can be fixed text
* zfs-nonroot-necessities.service can also be constant and always
enabled, because it's conditioned on BOOTFS being set
There is no longer any code generated at run-time
(the sysroot.mount drop-in is an unavoidable gratuitous cp).
The flow of BOOTFS{,FLAGS} from zfs-env-bootfs.service to sysroot.mount
is not noted explicitly in dracut.zfs(7), because (a) at some point it's
just visual noise and (b) it's already ordered via d-p-m.s from z-i.t.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #14690
2023-03-31 19:47:48 +03:00
|
|
|
echo "PassEnvironment=BOOTFS BOOTFSFLAGS"
|
|
|
|
|
echo 'What=${BOOTFS}'
|
contrib/dracut: 90: mount essential datasets under root
This partly mirrors what the i-t script does (though that mounts all
children, recursively) ‒ /etc, /usr, /lib*, and /bin are all essential,
if present, to successfully invoke the real init, which will then mount
everything else it might need in the right order
The following extreme-case set-up boots w/o issues now:
/ zoot zfs rw,relatime,xattr,noacl
├─/etc zoot/etc zfs rw,relatime,xattr,noacl
├─/usr zoot/usr zfs rw,relatime,xattr,noacl
│ └─/usr/local zoot/usr/local zfs rw,relatime,xattr,noacl
├─/var zoot/var zfs rw,relatime,xattr,noacl
│ ├─/var/lib zoot/var/lib zfs rw,relatime,xattr,noacl
│ ├─/var/log zoot/var/log zfs rw,relatime,xattr,posixacl
│ ├─/var/cache zoot/var/cache zfs rw,relatime,xattr,noacl
│ └─/var/tmp zoot/var/tmp zfs rw,relatime,xattr,noacl
├─/home zoot/home zfs rw,relatime,xattr,noacl
│ └─/home/nab zoot/home/nab zfs rw,relatime,xattr,noacl
├─/boot zoot/boot zfs rw,relatime,xattr,noacl
├─/root zoot/home/root zfs rw,relatime,xattr,noacl
├─/opt zoot/opt zfs rw,relatime,xattr,noacl
└─/srv zoot/srv zfs rw,relatime,xattr,noacl
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #11898
2021-04-13 23:41:10 +03:00
|
|
|
echo "Type=zfs"
|
contrib: dracut: fix race with root=zfs:dset when necessities required
This had always worked in my testing, but a user on hardware reported
this to happen 100%, and I reproduced it once with cold VM host caches.
dracut-zfs-generator runs as a systemd generator, i.e. at Some
Relatively Early Time; if root= is a fixed dataset, it tries to
"solve [necessities] statically at generation time".
If by that point zfs-import.target hasn't popped (because the import is
taking a non-negligible amount of time for whatever reason), it'll see
no children for the root datase, and as such generate no mounts.
This has never had any right to work. No-one caught this earlier because
it's just that much more convenient to have root=zfs:AUTO, which orders
itself properly.
To fix this, always run zfs-nonroot-necessities.service;
this additionally simplifies the implementation by:
* making BOOTFS from zfs-env-bootfs.service be the real, canonical,
root dataset name, not just "whatever the first bootfs is",
and only set it if we're ZFS-booting
* zfs-{rollback,snapshot}-bootfs.service can use this instead of
re-implementing it
* having zfs-env-bootfs.service also set BOOTFSFLAGS
* this means the sysroot.mount drop-in can be fixed text
* zfs-nonroot-necessities.service can also be constant and always
enabled, because it's conditioned on BOOTFS being set
There is no longer any code generated at run-time
(the sysroot.mount drop-in is an unavoidable gratuitous cp).
The flow of BOOTFS{,FLAGS} from zfs-env-bootfs.service to sysroot.mount
is not noted explicitly in dracut.zfs(7), because (a) at some point it's
just visual noise and (b) it's already ordered via d-p-m.s from z-i.t.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #14690
2023-03-31 19:47:48 +03:00
|
|
|
echo 'Options=${BOOTFSFLAGS}'
|
Use a different technique to detect whether to mount-zfs
The behavior of the Dracut module was very wrong before.
The correct behavior: initramfs should not run `zfs-mount` to completion
if the two generator files exist. If, however, one of them is missing,
it indicates one of three cases:
* The kernel command line did not specify a root ZFS file system, and
another Dracut module is already handling root mount (via systemd).
`mount-zfs` can run, but it will do nothing.
* There is no systemd to run `sysroot.mount` to begin with.
`mount-zfs` must run.
* The root parameter is zfs:AUTO, which cannot be run in sysroot.mount.
`mount-zfs` must run.
In any of these three cases, it is safe to run `zfs-mount` to completion.
`zfs-mount` must also delete itself if it determines it should not run,
or else Dracut will do the insane thing of running it over and over again.
Literally, the definition of insanity, doing the same thing that did not
work before, expecting different results. Doing that may have had a great
result before, when we had a race between devices appearing and pools
being mounted, and `mount-zfs` was tasked with the full responsibility
of importing the needed pool, but nowadays it is wrong behavior and
should be suppressed.
I deduced that self-deletion was the correct thing to do by looking at
other Dracut code, because (as we all are very fully aware of) Dracut
is entirely, ahem, "implementation-defined".
Tested-by: @wphilips
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Manuel Amador (Rudd-O) <rudd-o@rudd-o.com>
Closes #5157
Closes #5204
2016-10-06 20:26:47 +03:00
|
|
|
} > "$GENERATOR_DIR"/sysroot.mount.d/zfs-enhancement.conf
|
contrib/dracut: 90: mount essential datasets under root
This partly mirrors what the i-t script does (though that mounts all
children, recursively) ‒ /etc, /usr, /lib*, and /bin are all essential,
if present, to successfully invoke the real init, which will then mount
everything else it might need in the right order
The following extreme-case set-up boots w/o issues now:
/ zoot zfs rw,relatime,xattr,noacl
├─/etc zoot/etc zfs rw,relatime,xattr,noacl
├─/usr zoot/usr zfs rw,relatime,xattr,noacl
│ └─/usr/local zoot/usr/local zfs rw,relatime,xattr,noacl
├─/var zoot/var zfs rw,relatime,xattr,noacl
│ ├─/var/lib zoot/var/lib zfs rw,relatime,xattr,noacl
│ ├─/var/log zoot/var/log zfs rw,relatime,xattr,posixacl
│ ├─/var/cache zoot/var/cache zfs rw,relatime,xattr,noacl
│ └─/var/tmp zoot/var/tmp zfs rw,relatime,xattr,noacl
├─/home zoot/home zfs rw,relatime,xattr,noacl
│ └─/home/nab zoot/home/nab zfs rw,relatime,xattr,noacl
├─/boot zoot/boot zfs rw,relatime,xattr,noacl
├─/root zoot/home/root zfs rw,relatime,xattr,noacl
├─/opt zoot/opt zfs rw,relatime,xattr,noacl
└─/srv zoot/srv zfs rw,relatime,xattr,noacl
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #11898
2021-04-13 23:41:10 +03:00
|
|
|
ln -fs ../sysroot.mount "$GENERATOR_DIR"/initrd-root-fs.target.requires/sysroot.mount
|
|
|
|
|
|
2021-01-26 23:14:22 +03:00
|
|
|
{
|
|
|
|
|
echo "[Unit]"
|
|
|
|
|
echo "After=zfs-import.target"
|
|
|
|
|
} > "$GENERATOR_DIR"/dracut-pre-mount.service.d/zfs-enhancement.conf
|
|
|
|
|
|
2021-04-13 23:37:59 +03:00
|
|
|
[ -n "$debug" ] && echo "zfs-generator: finished" >> /dev/kmsg
|
|
|
|
|
|
|
|
|
|
exit 0
|