2011-03-17 22:18:13 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
. /lib/dracut-zfs-lib.sh
|
2011-03-17 22:18:13 +00:00
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
ZFS_DATASET=""
|
|
|
|
|
ZFS_POOL=""
|
2011-07-24 20:53:15 +00:00
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
case "${root}" in
|
|
|
|
|
zfs:*) ;;
|
|
|
|
|
*) return ;;
|
|
|
|
|
esac
|
2011-07-04 17:25:31 +00:00
|
|
|
|
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 17:26:47 +00:00
|
|
|
GENERATOR_FILE=/run/systemd/generator/sysroot.mount
|
|
|
|
|
GENERATOR_EXTENSION=/run/systemd/generator/sysroot.mount.d/zfs-enhancement.conf
|
|
|
|
|
|
|
|
|
|
if [ -e "$GENERATOR_FILE" -a -e "$GENERATOR_EXTENSION" ] ; then
|
|
|
|
|
# If the ZFS sysroot.mount flag exists, the initial RAM disk configured
|
|
|
|
|
# it to mount ZFS on root. In that case, we bail early. This flag
|
|
|
|
|
# file gets created by the zfs-generator program upon successful run.
|
|
|
|
|
info "ZFS: There is a sysroot.mount and zfs-generator has extended it."
|
|
|
|
|
info "ZFS: Delegating root mount to sysroot.mount."
|
|
|
|
|
# Let us tell the initrd to run on shutdown.
|
|
|
|
|
# We have a shutdown hook to run
|
|
|
|
|
# because we imported the pool.
|
|
|
|
|
need_shutdown
|
|
|
|
|
# We now prevent Dracut from running this thing again.
|
|
|
|
|
for zfsmounthook in "$hookdir"/mount/*zfs* ; do
|
|
|
|
|
if [ -f "$zfsmounthook" ] ; then
|
|
|
|
|
rm -f "$zfsmounthook"
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
return
|
2016-04-24 11:35:44 +00:00
|
|
|
fi
|
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 17:26:47 +00:00
|
|
|
info "ZFS: No sysroot.mount exists or zfs-generator did not extend it."
|
|
|
|
|
info "ZFS: Mounting root with the traditional mount-zfs.sh instead."
|
2016-04-24 11:35:44 +00:00
|
|
|
|
2015-03-23 16:17:56 +00:00
|
|
|
# Delay until all required block devices are present.
|
|
|
|
|
udevadm settle
|
|
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
if [ "${root}" = "zfs:AUTO" ] ; then
|
|
|
|
|
ZFS_DATASET="$(find_bootfs)"
|
|
|
|
|
if [ $? -ne 0 ] ; then
|
|
|
|
|
zpool import -N -a ${ZPOOL_IMPORT_OPTS}
|
|
|
|
|
ZFS_DATASET="$(find_bootfs)"
|
|
|
|
|
if [ $? -ne 0 ] ; then
|
|
|
|
|
warn "ZFS: No bootfs attribute found in importable pools."
|
2015-02-16 08:56:04 +00:00
|
|
|
export_all || export_all "-f"
|
2015-02-15 19:28:42 +00:00
|
|
|
|
|
|
|
|
rootok=0
|
|
|
|
|
return 1
|
2011-07-24 20:46:16 +00:00
|
|
|
fi
|
2015-02-15 19:28:42 +00:00
|
|
|
fi
|
|
|
|
|
info "ZFS: Using ${ZFS_DATASET} as root."
|
|
|
|
|
fi
|
2011-07-04 17:25:31 +00:00
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
ZFS_DATASET="${ZFS_DATASET:-${root#zfs:}}"
|
|
|
|
|
ZFS_POOL="${ZFS_DATASET%%/*}"
|
2014-10-06 11:08:33 +00:00
|
|
|
|
2015-02-15 19:28:42 +00:00
|
|
|
if import_pool "${ZFS_POOL}" ; then
|
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 17:26:47 +00:00
|
|
|
# Let us tell the initrd to run on shutdown.
|
|
|
|
|
# We have a shutdown hook to run
|
|
|
|
|
# because we imported the pool.
|
|
|
|
|
need_shutdown
|
2015-02-15 19:28:42 +00:00
|
|
|
info "ZFS: Mounting dataset ${ZFS_DATASET}..."
|
|
|
|
|
if mount_dataset "${ZFS_DATASET}" ; then
|
|
|
|
|
ROOTFS_MOUNTED=yes
|
|
|
|
|
return 0
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
rootok=0
|
