ZFS root (builtin) - Revision history

Foobarz at 12:12, 25 September 2012

Foobarz — Tue, 25 Sep 2012 12:12:38 GMT

← Older revision		Revision as of 12:12, 25 September 2012
Line 833:		Line 833:
	reboot		reboot
	</pre>		</pre>
	Note: If <code>spl.spl_hostid=0x007f0100</code> is not included in addappend, then during boot SPL module will attempt to read /etc/hostid or run a user-space helper to write the <code>hostid</code> into <code>/proc/sys/kernel/spl/hostid</code>. Reading /etc/hostid fails unless you use foobarz-chhostid ~~and~~ make the file and copy it ~~into~~ /boot/initramfs-source/etc/hostid. The helper will fail because no <code>sh</code> shell and no <code>hostid</code> command are installed in the initramfs. The default hostid becomes 0xffffffff, which is considered an invalid hostid.		Note: If <code>spl.spl_hostid=0x007f0100</code> is not included in addappend, then during boot SPL module will attempt to read <code>/etc/hostid</code> or else run a user-space helper to write the <code>hostid</code> into <code>/proc/sys/kernel/spl/hostid</code>. Reading <code>/etc/hostid</code> fails unless you use [https://github.com/foobarz/foobarz-chhostid foobarz-chhostid] to make the file and copy it to <code>/boot/initramfs-source/etc/hostid</code> then run the steps above again. The helper will fail because no <code>sh</code> shell and no <code>hostid</code> command are installed in the initramfs. The default hostid becomes 0xffffffff, which is considered an invalid hostid.

	Congrats! If this works, you can select the "vm3.2.29b" lilo entry to boot. If you are using the zpool_import support in the init program, you need to add at least the <code>zpool_import_name=zfs-root</code> param to the addappend line in lilo.conf.		Congrats! If this works, you can select the "vm3.2.29b" lilo entry to boot. If you are using the zpool_import support in the init program, you need to add at least the <code>zpool_import_name=zfs-root</code> param to the addappend line in lilo.conf.

Foobarz at 20:08, 24 September 2012

Foobarz — Mon, 24 Sep 2012 20:08:44 GMT

Show changes

Foobarz at 09:30, 22 September 2012

Foobarz — Sat, 22 Sep 2012 09:30:40 GMT

← Older revision		Revision as of 09:30, 22 September 2012
Line 283:		Line 283:
	* mknod dev/ttyS3 c 4 67 $ COM4		* mknod dev/ttyS3 c 4 67 $ COM4
	*		*
	* ~~and~~ this program ~~compiled~~ to /boot/initramfs-source/init		* Copy this compiled program to /boot/initramfs-source/init
			* If not named /init, then use rdinit=/othername kernel parameter.
	*		*
	* Set kernel config option		* Set kernel config option
Line 291:		Line 292:
	*/		*/

	#define FOOBARZ_INIT_VERSION "1.1.1"		#define FOOBARZ_INIT_VERSION "1.1.2"
	#define _BSD_SOURCE		#define _BSD_SOURCE
	#include <stdio.h>		#include <stdio.h>
Line 309:		Line 310:
	*		*
	* gcc -static -DINCLUDE_ZPOOL_IMPORT \		* gcc -static -DINCLUDE_ZPOOL_IMPORT \
	* foobarz-init.c -include /usr/src/zfs-0.6.0-~~rc11~~/3.2.28/zfs_config.h \		* foobarz-init.c -include /usr/src/zfs-0.6.0-rc10/3.2.28/zfs_config.h \
	* -o init \		* -o init \
	* -I /usr/include/libspl -I /usr/include/libzfs \		* -I /usr/include/libspl -I /usr/include/libzfs \
Line 381:		Line 382:
	struct nv { char* n; char* v; char* v_end; int req; int src; };		struct nv { char* n; char* v; char* v_end; int req; int src; };
	struct nv param[] = {		struct nv param[] = {
	{ "root=", NULL, NULL, PARAM_REQ_YES, PARAM_SRC_DEFAULT },		{ " root=", NULL, NULL, PARAM_REQ_YES, PARAM_SRC_DEFAULT },
	{ "rootfstype=", NULL, NULL, PARAM_REQ_YES, PARAM_SRC_DEFAULT },		{ " rootfstype=", NULL, NULL, PARAM_REQ_YES, PARAM_SRC_DEFAULT },
	{ "mountopt=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " mountopt=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "init=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " init=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "runlevel=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " runlevel=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "console=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT }		{ " console=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT }
	#if defined(INCLUDE_ZPOOL_IMPORT)		#if defined(INCLUDE_ZPOOL_IMPORT)
	,		,
	{ "zpool_import_name=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " zpool_import_name=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "zpool_import_guid=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " zpool_import_guid=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "zpool_import_newname=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },		{ " zpool_import_newname=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT },
	{ "zpool_import_force=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT }		{ " zpool_import_force=", NULL, NULL, PARAM_REQ_NO , PARAM_SRC_DEFAULT }
	#endif		#endif
	};		};
Line 524:		Line 525:
	}		}

			/* set defaults for params not given on cmdline */
	for( i=iroot; i<ilastparam; i++ ) {		for( i=iroot; i<ilastparam; i++ ) {
	/* terminate value strings */		/* terminate value strings */
Line 616:		Line 618:
	printk("zpool_import: init libzfs.\n");		printk("zpool_import: init libzfs.\n");
	libzfs = libzfs_init();		libzfs = libzfs_init();
	printk("zpool_import: searching for pool.\n");		if( libzfs != NULL ) {
	pools = zpool_search_import(libzfs, &iargs);		printk("zpool_import: searching for pool.\n");
	if( (pools == NULL) \|\| nvlist_empty(pools) )		pools = zpool_search_import(libzfs, &iargs);
	printk("zpool_import: pool not available for import, or already imported by cachefile.\n");		if( (pools == NULL) \|\| nvlist_empty(pools) )
	else {		printk("zpool_import: pool not available for import, or already imported by cachefile.\n");
	printk("zpool_import: getting pool information.\n");		else {
	pool = nvlist_next_nvpair(pools, pool);		printk("zpool_import: getting pool information.\n");
	printk("zpool_import: getting pool configuration.\n");		pool = nvlist_next_nvpair(pools, pool);
	nvpair_value_nvlist(pool, &config);		printk("zpool_import: getting pool configuration.\n");
	printk("zpool_import: attempting pool import.\n");		nvpair_value_nvlist(pool, &config);
	if( zpool_import(libzfs, config, param[izpool_import_newname].v, NULL) != 0 ) {		printk("zpool_import: attempting pool import.\n");
	printk("zpool_import: import failed.\n");		if( zpool_import(libzfs, config, param[izpool_import_newname].v, NULL) != 0 ) {
	printk("zpool_import: error description: %s\n", libzfs_error_description(libzfs) );		printk("zpool_import: import failed.\n");
	printk("zpool_import: error action: %s\n", libzfs_error_action(libzfs) );		printk("zpool_import: error description: %s\n", libzfs_error_description(libzfs) );
	} else printk("zpool_import: import successful.\n");		printk("zpool_import: error action: %s\n", libzfs_error_action(libzfs) );
			} else printk("zpool_import: import successful.\n");
			}
			printk("zpool_import: fini libzfs.\n");
			libzfs_fini(libzfs);
			} else {
			printk("zpool_import: unable to initialize libzfs.\n");
	}		}
	~~printk("zpool_import: fini libzfs.\n");~~
	~~libzfs_fini(libzfs);~~
	}		}
	#endif /* zpool_import */		#endif /* zpool_import */

Foobarz at 13:28, 19 September 2012

Foobarz — Wed, 19 Sep 2012 13:28:18 GMT

← Older revision		Revision as of 13:28, 19 September 2012
Line 97:		Line 97:
	At this point, the <code>copy-builtin</code> scripts have installed the configured spl and zfs modules source into the kernel source. The regular <code>make menuconfig</code> in the kernel source should now show options for spl and zfs in the kernel config.		At this point, the <code>copy-builtin</code> scripts have installed the configured spl and zfs modules source into the kernel source. The regular <code>make menuconfig</code> in the kernel source should now show options for spl and zfs in the kernel config.

	As of this writing, the copy-builtin script places the spl and zfs modules into the kernel source in places where the modules may not initialize in the best order, <i>after</i> all lower-level storage drivers are initialized. If spl and zfs initialize too soon, there is a chance they may not be able to see all of the storage devices. The order of initialization (as seen in dmesg) of modules that are builtin to the kernel is the order that the modules are linked into the kernel during kernel compilation. The order of link depends on where the module source files are located in the kernel source tree. To ensure that spl and zfs will initialize after all hardware drivers, we can move them into the <code>drivers</code> tree and after all other drivers. This move is <~~bold~~>optional</~~bold~~> and you can skip doing this and everything will probably work fine, but it is shown here how to move the modules to under drivers in case you prefer them there:		As of this writing, the copy-builtin script places the spl and zfs modules into the kernel source in places where the modules may not initialize in the best order, <i>after</i> all lower-level storage drivers are initialized. If spl and zfs initialize too soon, there is a chance they may not be able to see all of the storage devices. The order of initialization (as seen in dmesg) of modules that are builtin to the kernel is the order that the modules are linked into the kernel during kernel compilation. The order of link depends on where the module source files are located in the kernel source tree. To ensure that spl and zfs will initialize after all hardware drivers, we can move them into the <code>drivers</code> tree and after all other drivers. This move is <b>optional</b> and you can skip doing this and everything will probably work fine, but it is shown here how to move the modules to under drivers in case you prefer them there:
	<pre>		<pre>
	cd /usr/src/linux-3.2.28b		cd /usr/src/linux-3.2.28b

Foobarz at 13:26, 19 September 2012

Foobarz — Wed, 19 Sep 2012 13:26:56 GMT

← Older revision		Revision as of 13:26, 19 September 2012
Line 66:		Line 66:
	--with-linux=/usr/src/linux-3.2.28b \		--with-linux=/usr/src/linux-3.2.28b \
	--with-linux-obj=/usr/src/linux-3.2.28b		--with-linux-obj=/usr/src/linux-3.2.28b
	~~wget https://raw.github.com/zfsonlinux/spl/master/copy-builtin~~
	~~chmod +x copy-builtin~~
	./copy-builtin /usr/src/linux-3.2.28b		./copy-builtin /usr/src/linux-3.2.28b
	make		make
Line 78:		Line 76:
	tar xvzf ~/zfs-0.6.0-rc11.tar.gz		tar xvzf ~/zfs-0.6.0-rc11.tar.gz
	mkdir install		mkdir install
	cd ~~spl~~-0.6.0-rc11		cd zfs-0.6.0-rc11
	./configure \		./configure \
	--prefix=/ \		--prefix=/ \
Line 88:		Line 86:
	--with-linux-obj=/usr/src/linux-3.2.28b \		--with-linux-obj=/usr/src/linux-3.2.28b \
	--with-spl=/root/src/spl-0.6.0-rc11		--with-spl=/root/src/spl-0.6.0-rc11
	~~wget https:~~//~~raw~~.~~github~~.~~com/zfsonlinux/zfs/master/copy-builtin~~		--with-spl-obj=/root/src/spl-0.6.0-rc11
	~~chmod +x copy~~-~~builtin~~
	./copy-builtin /usr/src/linux-3.2.28b		./copy-builtin /usr/src/linux-3.2.28b
	make		make
Line 100:		Line 97:
	At this point, the <code>copy-builtin</code> scripts have installed the configured spl and zfs modules source into the kernel source. The regular <code>make menuconfig</code> in the kernel source should now show options for spl and zfs in the kernel config.		At this point, the <code>copy-builtin</code> scripts have installed the configured spl and zfs modules source into the kernel source. The regular <code>make menuconfig</code> in the kernel source should now show options for spl and zfs in the kernel config.

	As of this writing, the copy-builtin script places the spl and zfs modules into the kernel source in places where the modules may not initialize in the best order, <i>after</i> all lower-level storage drivers are initialized. If spl and zfs initialize too soon, there is a chance they may not be able to see all of the storage devices. The order of initialization (as seen in dmesg) of modules that are builtin to the kernel is the order that the modules are linked into the kernel during kernel compilation. The order of link depends on where the module source files are located in the kernel source tree. To ensure that spl and zfs will initialize after all hardware drivers, we move them into the <code>drivers</code> tree and after all other drivers:		As of this writing, the copy-builtin script places the spl and zfs modules into the kernel source in places where the modules may not initialize in the best order, <i>after</i> all lower-level storage drivers are initialized. If spl and zfs initialize too soon, there is a chance they may not be able to see all of the storage devices. The order of initialization (as seen in dmesg) of modules that are builtin to the kernel is the order that the modules are linked into the kernel during kernel compilation. The order of link depends on where the module source files are located in the kernel source tree. To ensure that spl and zfs will initialize after all hardware drivers, we can move them into the <code>drivers</code> tree and after all other drivers. This move is <bold>optional</bold> and you can skip doing this and everything will probably work fine, but it is shown here how to move the modules to under drivers in case you prefer them there:
	<pre>		<pre>
	cd /usr/src/linux-3.2.28b		cd /usr/src/linux-3.2.28b
Line 785:		Line 782:
	<pre>		<pre>
	gcc -static -DINCLUDE_ZPOOL_IMPORT \		gcc -static -DINCLUDE_ZPOOL_IMPORT \
	foobarz-init.c -include /usr/src/~~zfs~~-~~0.6.0-rc11/~~3.2.28/zfs_config.h \		foobarz-init.c -include /usr/src/linux-3.2.28b/zfs_config.h \
	-o init \		-o init \
	-I /usr/include/libspl -I /usr/include/libzfs \		-I /usr/include/libspl -I /usr/include/libzfs \

Foobarz at 10:49, 19 September 2012

Foobarz — Wed, 19 Sep 2012 10:49:36 GMT

Show changes

Foobarz at 14:29, 14 September 2012

Foobarz — Fri, 14 Sep 2012 14:29:31 GMT

← Older revision		Revision as of 14:29, 14 September 2012
Line 9:		Line 9:
	</pre>		</pre>

	Edit <code>/etc/rc.d/rc.S</code> and <code>rc.6</code> to use regular <code>mount</code> commands, remove <code>zfs</code> commands. Edit <code>rc.6</code> and remove or comment out <code>~~zfs~~ export</code> command. These edits undo changes made in the "ZFS root" wiki, but it shows the two different ways of mounting a zfs filesystem.		Edit <code>/etc/rc.d/rc.S</code> and <code>rc.6</code> to use regular <code>mount</code> commands, remove <code>zfs</code> commands. Edit <code>rc.6</code> and remove or comment out <code>zpool export</code> command. These edits undo changes made in the "ZFS root" wiki, but it shows the two different ways of mounting a zfs filesystem.

	You <i>might</i> think to set <code>bootfs</code> property like this:		You <i>might</i> think to set <code>bootfs</code> property like this:
Line 229:		Line 229:
	The slackware mkinitrd package is a fully configured BusyBox installation that makes an external initramfs image file, initrd.gz, that is passed to the kernel by the bootloader (lilo). It could be changed to be internal to the kernel by just using initrd-tree as the CONFIG_INITRAMFS_SOURCE in the kernel config and removing initrd in the lilo.conf.		The slackware mkinitrd package is a fully configured BusyBox installation that makes an external initramfs image file, initrd.gz, that is passed to the kernel by the bootloader (lilo). It could be changed to be internal to the kernel by just using initrd-tree as the CONFIG_INITRAMFS_SOURCE in the kernel config and removing initrd in the lilo.conf.

	The main purpose of most initramfs/initrd is to load and configure kernel modules and devices needed to mount a root filesystem. Because the spl/zfs modules are builtin, there isn't really a lot that needs to be done by an initramfs. What remains to be done is import the zfs-root pool, mount it, and exec the system /sbin/init. The kernel's "legacy" parameters <code>root=</code> and <code>rootfstype=</code> that are able to directly boot a root disk do not work with ZFS at this time because ZFS pools always need to be imported before it is possible to mount and boot on them. The automatic import that ZFS can do by using a cachefile (/etc/zfs/zpool.cache) stored in initramfs still does not work with the legacy boot parameters because at an ~~eariler~~ stage of the boot process, the kernel ignores a rootfs that does not contain an <code>/init</code> program, and/or the device type of an imported pool is not the device types recognized by the legacy boot as valid root devices.		The main purpose of most initramfs/initrd is to load and configure kernel modules and devices needed to mount a root filesystem. Because the spl/zfs modules are builtin, there isn't really a lot that needs to be done by an initramfs. What remains to be done is import the zfs-root pool, mount it, and exec the system /sbin/init. The kernel's "legacy" parameters <code>root=</code> and <code>rootfstype=</code> that are able to directly boot a root disk do not work with ZFS at this time because ZFS pools always need to be imported before it is possible to mount and boot on them. The automatic import that ZFS can do by using a cachefile (/etc/zfs/zpool.cache) stored in initramfs still does not work with the legacy boot parameters because at an earlier stage of the boot process, the kernel ignores a rootfs that does not contain an <code>/init</code> program, and/or the device type of an imported pool is not the device types recognized by the legacy boot as valid root devices.

	You could just continue to use slackware's mkinitrd package as in the "ZFS root" wiki and it works the same whether the modules are builtin or not. But, by building the spl/zfs modules in, aren't we really wanting to get rid of using the mkinitrd/initrd.gz? We'd like to have a kernel with everything in it to boot, and use a simple lilo image entry that has no initrd.		You could just continue to use slackware's mkinitrd package as in the "ZFS root" wiki and it works the same whether the modules are builtin or not. But, by building the spl/zfs modules in, aren't we really wanting to get rid of using the mkinitrd/initrd.gz? We'd like to have a kernel with everything in it to boot, and use a simple lilo image entry that has no initrd.
Line 826:		Line 826:
	reboot		reboot
	</pre>		</pre>
			Note: If <code>spl.spl_hostid=0x007f0100</code> is not included in addappend, then during boot SPL module will attempt to read /etc/hostid or run a user-space helper to write the <code>hostid</code> into <code>/proc/sys/kernel/spl/hostid</code>. Reading /etc/hostid fails unless you use foobarz-chhostid and make the file and copy it into /boot/initramfs-source/etc/hostid. The helper will fail because no <code>sh</code> shell and no <code>hostid</code> command are installed in the initramfs. The default hostid becomes 0xffffffff, which is considered an invalid hostid.

	Congrats! If this works, you can select the "vm3.2.27b" lilo entry to boot. If you are using the zpool_import support in the init program, you need to add at least the <code>zpool_import_name=zfs-root</code> param to the addappend line in lilo.conf.		Congrats! If this works, you can select the "vm3.2.27b" lilo entry to boot. If you are using the zpool_import support in the init program, you need to add at least the <code>zpool_import_name=zfs-root</code> param to the addappend line in lilo.conf.

Foobarz at 22:50, 12 September 2012

Foobarz — Wed, 12 Sep 2012 22:50:19 GMT

← Older revision		Revision as of 22:50, 12 September 2012
Line 795:		Line 795:
	<li> Install [http://sourceforge.net/projects/libtirpc/ libtirpc]. The glibc package has removed the RPC-related functions from the static libc. The libtirpc is the new replacement as a separate library. You can make your own libtirpc package and install it to resolve these RPC-related functions. Without this, the compile fails because it cannot find many "xdr" functions.</li>		<li> Install [http://sourceforge.net/projects/libtirpc/ libtirpc]. The glibc package has removed the RPC-related functions from the static libc. The libtirpc is the new replacement as a separate library. You can make your own libtirpc package and install it to resolve these RPC-related functions. Without this, the compile fails because it cannot find many "xdr" functions.</li>
	<li> Reinstall the [ftp://slackware.mirrors.tds.net/pub/slackware/slackware64-current/source/a/util-linux/ util-linux] package with static libraries enabled. Edit the <code>util-linux.SlackBuild</code> and remove the line <code>--disable-static</code>, then build it and use upgradepkg to install the new package. This resolves linking static to libuuid.</li>		<li> Reinstall the [ftp://slackware.mirrors.tds.net/pub/slackware/slackware64-current/source/a/util-linux/ util-linux] package with static libraries enabled. Edit the <code>util-linux.SlackBuild</code> and remove the line <code>--disable-static</code>, then build it and use upgradepkg to install the new package. This resolves linking static to libuuid.</li>
			<li><code>zfs_config.h</code> can be found in the kernel source when you have installed the builtin spl/zfs configuration; for example at <code>/usr/src/linux-3.2.27b/zfs_config.h</code>. If you currently have installed the modular spl/zfs configuration, <code>zfs_config.h</code> is found where the zfs module headers are installed; for example at <code>/usr/src/zfs-0.6.0-rc10/3.2.28/zfs_config.h</code>. Wherever it is, <code>-include</code> it as shown in the example gcc line above. zfs_config.h seems misplaced because it would seem that using libzfs shouldn't depend on modules header files.</li>
	<li>You may need to install the spl and zfs packages configured for --enable-linux-builtin=yes before compiling and linking to libzfs to make sure you are using the version of libzfs intended for builtin modules in case a difference between the two configurations exists. Currently, there seems to be no difference in the libzfs for either modular or builtin modules, but later there could be at least a small difference for detection of modules to load or builtin already. You may see a message that the ZFS modules stack load failed, but it can be ignored since the modules are builtin; this is just libzfs trying to load the modules even though they are builtin.</li>		<li>You may need to install the spl and zfs packages configured for --enable-linux-builtin=yes before compiling and linking to libzfs to make sure you are using the version of libzfs intended for builtin modules in case a difference between the two configurations exists. Currently, there seems to be no difference in the libzfs for either modular or builtin modules, but later there could be at least a small difference for detection of modules to load or builtin already. You may see a message that the ZFS modules stack load failed, but it can be ignored since the modules are builtin; this is just libzfs trying to load the modules even though they are builtin.</li>
	</ul>		</ul>

Foobarz at 22:31, 12 September 2012

Foobarz — Wed, 12 Sep 2012 22:31:37 GMT

← Older revision		Revision as of 22:31, 12 September 2012
Line 795:		Line 795:
	<li> Install [http://sourceforge.net/projects/libtirpc/ libtirpc]. The glibc package has removed the RPC-related functions from the static libc. The libtirpc is the new replacement as a separate library. You can make your own libtirpc package and install it to resolve these RPC-related functions. Without this, the compile fails because it cannot find many "xdr" functions.</li>		<li> Install [http://sourceforge.net/projects/libtirpc/ libtirpc]. The glibc package has removed the RPC-related functions from the static libc. The libtirpc is the new replacement as a separate library. You can make your own libtirpc package and install it to resolve these RPC-related functions. Without this, the compile fails because it cannot find many "xdr" functions.</li>
	<li> Reinstall the [ftp://slackware.mirrors.tds.net/pub/slackware/slackware64-current/source/a/util-linux/ util-linux] package with static libraries enabled. Edit the <code>util-linux.SlackBuild</code> and remove the line <code>--disable-static</code>, then build it and use upgradepkg to install the new package. This resolves linking static to libuuid.</li>		<li> Reinstall the [ftp://slackware.mirrors.tds.net/pub/slackware/slackware64-current/source/a/util-linux/ util-linux] package with static libraries enabled. Edit the <code>util-linux.SlackBuild</code> and remove the line <code>--disable-static</code>, then build it and use upgradepkg to install the new package. This resolves linking static to libuuid.</li>
			<li>You may need to install the spl and zfs packages configured for --enable-linux-builtin=yes before compiling and linking to libzfs to make sure you are using the version of libzfs intended for builtin modules in case a difference between the two configurations exists. Currently, there seems to be no difference in the libzfs for either modular or builtin modules, but later there could be at least a small difference for detection of modules to load or builtin already. You may see a message that the ZFS modules stack load failed, but it can be ignored since the modules are builtin; this is just libzfs trying to load the modules even though they are builtin.</li>
	</ul>		</ul>
	With these dependencies, you can probably compile static with the zpool_import support. The exact location of "zfs_config.h" may vary depending on your zfs and kernel versions, so adjust accordingly.		With these dependencies, you can probably compile static with the zpool_import support. The exact location of "zfs_config.h" may vary depending on your zfs and kernel versions, so adjust accordingly.

Foobarz at 19:57, 12 September 2012

Foobarz — Wed, 12 Sep 2012 19:57:57 GMT

← Older revision		Revision as of 19:57, 12 September 2012
Line 791:		Line 791:
	strip init		strip init
	</pre>		</pre>
	~~Note~~: ~~the zpool_import support requires that you install~~ [http://sourceforge.net/projects/libtirpc/ libtirpc] ~~first~~.		Dependencies required before you can compile this second way:
			<ul>
			<li> Install [http://sourceforge.net/projects/libtirpc/ libtirpc]. The glibc package has removed the RPC-related functions from the static libc. The libtirpc is the new replacement as a separate library. You can make your own libtirpc package and install it to resolve these RPC-related functions. Without this, the compile fails because it cannot find many "xdr" functions.</li>
			<li> Reinstall the [ftp://slackware.mirrors.tds.net/pub/slackware/slackware64-current/source/a/util-linux/ util-linux] package with static libraries enabled. Edit the <code>util-linux.SlackBuild</code> and remove the line <code>--disable-static</code>, then build it and use upgradepkg to install the new package. This resolves linking static to libuuid.</li>
			</ul>
			With these dependencies, you can probably compile static with the zpool_import support. The exact location of "zfs_config.h" may vary depending on your zfs and kernel versions, so adjust accordingly.

	Read the foobarz-init source code to see how it uses kernel parameters. The params <code>root</code> and <code>rootfstype</code> are always required to tell init what root pool name to mount and the filesystem type (e.g. zfs).		Read the foobarz-init source code to see how it uses kernel parameters. The params <code>root</code> and <code>rootfstype</code> are always required to tell init what root pool name to mount and the filesystem type (e.g. zfs).