genkernel's initramfs image is built incrementally by appending to the
cpio file. The introduction of copy_binaries resulted in copying
libraries from the host system, which causes the cpio to include certain
libraries multiple times whenever different stages depended upon the
same library. We address this by extracting the cpio to a temporary
directory and then compressing it again to "finalize" it. The extraction
eliminates the duplicate files.
This makes generated initramfs images slightly smaller and in theory,
should make the initramfs load slightly faster.
Signed-off-by: Richard Yao <ryao@gentoo.org>
Conflicts:
gen_initramfs.sh
Commit 3a054014e8 replaced our modprobe
with busybox's modprobe. Unfortunately, busybox's modprobe appears to be
unable to properly load modules with more than 1 level of dependencies.
The zfs and zpool commands will invoke modprobe if /dev/zvol is missing,
which concealed this problem. However, this caused problems because some
invocations would fail and under certain circumstances, init would be
killed, causing a kernel panic. This issue was made clear by commit
c812c35100771bb527f6b03853fa6d8ef66a48fe, which ensured that the zpool
and zfs commands were not run until the ZFS module was loaded.
busybox modprobe's failure to load module dependencies correctly appears
to occur because busybox modprobe does not wait until until a module is
loaded before loading a module that depends on it, which is a race. It
would be best to correct this race by waiting until the module has
properly loaded, but it is not clear that the race is the only thing
going wrong and developer time is a premium.
We implement a workaround by modifying the busy loop added in the
previous commit to explicit call `modprobe zfs` on each iteration. While
the first few calls fail due to bugs in busybox modprobe, it will
eventually work, after which each call is a noop. This lets us keep
looping until either the loop exit condition that /dev/zvol exist is
reached or the 5 second timeout is reached.
Once the busybox modprobe issue is fixed, this workaround should be safe
to revert.
Signed-off-by: Richard Yao <ryao@gentoo.org>
There is a race between ZFS module initialization and our attempt to
import pools. We address this by doing a busy wait for the /dev/zfs
device to appear. We wait a maximum of 5 seconds for the device to
appear.
We also slightly alter output messages to be more readable.
Signed-off-by: Richard Yao <ryao@gentoo.org>
Conflicts:
defaults/initrd.scripts
call_func_timeout permits us to call a helper function and kill it
should it exceed some timeout. This is derived from example code posted
on Stack Overflow:
http://stackoverflow.com/a/11056286
Signed-off-by: Richard Yao <ryao@gentoo.org>
Conflicts:
defaults/initrd.scripts
zpool.cache and zdev.conf are optional files, so instead of warning when
they are missing, we print a message when they are copied.
Signed-off-by: Richard Yao <ryao@gentoo.org>
At least one kernel configuration generates an addition module that we
need to load for USB 3.0 support, so lets load it.
Reported-by: Robin Johnson <robbat2@gentoo.org>
Signed-off-by: Richard Yao <ryao@gentoo.org>
Users were seeing the following error message printed:
cp: cannot stat ‘/etc/zfs/zdev.conf’: No such file or directory
Both zdev.conf and zpool.cache are optional files. We print a warning
when they are absent, but cp printed its own error in addition to our
warning. We suppress that.
Signed-off-by: Richard Yao <ryao@gentoo.org>
udev may still be processing rules and this can cause very bad
things. For instance, modules_load may have loaded an usb host
controller driver and we must wait for the udev rules to terminate.
However, this may lead to other race conditions, but we have
observed that adding scandelay=n where n >= 5 actually fixes the
issue of booting off USB under certain scenarios.
Crapping with .config thinking to be smarter than the user is just
stupid and can lead to sudden and unexpected compile/config failure.
Just DONT FUCKING TOUCH TEH CONFIGGGGGGGGGGG!
Fabio Erculiani
Richard Yao