febootstrap fedora-10 /tmp/f10
febootstrap rawhide /tmp/rawhide
febootstrap rawhide /tmp/rawhide http://mymirror/rawhide/x86_64/os
- febootstrap --groupinstall="Mail Server" rawhide /tmp/rawhide
+ febootstrap --groupinstall="Mail Server" fedora-10 /tmp/mailserver
=head1 DESCRIPTION
(otherwise the public Fedora mirrors are used). I<REPO> names are
C<fedora-I<VERSION>> (eg. C<fedora-10>) or C<rawhide>.
-febootstrap does not need to be run as root. If for some reason you
-do run it as root, then it works slightly differently and may have
+febootstrap does I<not> need to be run as root. If for some reason
+you do run it as root, then it works slightly differently and may have
side effects such as stopping or starting system daemons.
-For more advanced needs, take a look at L<mock(1)> and
-C<livecd-creator>.
+For more advanced needs, take a look at L<mock(1)>, C<livecd-creator>
+and I<thincrust.net>'s C<appliance-creator>.
The normal output is a root directory located at I<TARGET> and
a fakeroot logfile at C<I<TARGET>/fakeroot.log>.
also use shell globs and filenames here, as with ordinary yum.
If no packages or groups are given, then we install the C<Core> group
-which is the smallest working Fedora installation. Use C<yum
-groupinfo Core> to list the packages currently in the C<Core> group.
+which is a small working Fedora installation (but by no means
+minimal). Use C<yum groupinfo Core> to list the packages currently in
+the C<Core> group.
+
+=item B<--no-clean>
+
+Normally febootstrap will clean up the yum repository
+(C</var/cache/yum> inside the image). This contains the downloaded
+RPMs and metadata. However if you give the C<--no-clean> option, then
+the yum repository is left. This is useful if you want to run further
+yum commands inside the filesystem by hand.
+
+=item B<-p "proxyurl">
+
+=item B<--proxy="proxyurl">
+
+URL to the proxy server that yum should use.
+
+=item B<-u source>
+
+=item B<--updates=source>
+
+Pull in updates from an additional updates repository. The possible
+sources are:
+
+=over 4
+
+=item -u C<http://...> (a URL)
+
+Get updates from the specific URL.
+
+=item -u C<updates-released-fN> (an updates repository name)
+
+Get updates from the public mirrors of the named repository
+(eg. C<updates-released-f10>). See REPOSITORIES below.
+
+=item -u C<none> (default)
+
+Don't add an updates repository. This is the default.
+
+=back
=back
(If necessary replace C<i386> with your architecture, but it seems
unlikely that this list will change based on architecture).
-=head1 FAKEROOT LOGFILE
+=head1 RUNNING EXTRA COMMANDS IN THE ROOT FILESYSTEM
+
+If you want to run further commands inside the root filesystem, for
+example additional C<yum> installs, then use C<febootstrap-run>. See
+the L<febootstrap-run(8)> manual page for more details.
+
+You have to be careful about modifying files in the root filesystem
+directly (without using C<febootstrap-run>). It's easy to confuse
+fakeroot and end up with the wrong permissions on files (see FAKEROOT
+LOGFILE below).
+
+C<febootstrap-run> runs the command inside the root filesystem, which
+means it won't normally have access to files outside the root. You
+can use C<FAKECHROOT_EXCLUDE_PATH> environment variable (see
+L<fakechroot(1)>) or copy files into the root first.
+
+=head2 FAKEROOT LOGFILE
When febootstrap is run as non-root (the normal case) we use fakeroot
so that yum thinks it is running as root. Fakeroot keeps track of
"real" file permissions in a log file which is saved into the target
directory as C<I<TARGET>/fakeroot.log>.
+This logfile is indexed by inode number, which makes certain
+operations safe and other operations unsafe.
+Files should be replaced only by doing:
+
+ echo updated-content > old-file
+
+(since that preserves the original inode).
+
+Deleting files and then creating new ones (even with a different name)
+is usually unsafe, because the new files might reuse inodes claimed by
+the old files, and so appear with peculiar permissions
+(eg. unreadable, or as a symbolic link).
+
+Deleting files is also usually unsafe, although the reasons are more
+subtle. If you just use C<rm> then the inode number is not deleted
+from C<fakeroot.log> which means it can be reused by another file
+later on.
+
+In most cases it's usually safest to use C<febootstrap-run>.
+
You can use the fakeroot logfile in a number of ways:
=over 4
=item *
-Run C<fakeroot -i fakeroot.log I<command>> in order to run a
-command with the faked file permissions.
+Use L<febootstrap-run(8)> to run a command with the faked file
+permissions.
=item *
-Generate an initrd (cpio) file containing the correct permissions
-using the tool C<febootstrap-to-initrd>.
+Use L<febootstrap-install(8)> to install a file with permissions
+in the root filesystem.
=item *
-Apply the permissions to the target directory using the tool
-C<febootstrap-fix-root> (requires root).
+Generate an initramfs (compressed cpio) file containing the correct
+permissions using the tool C<febootstrap-to-initramfs>.
+
+=item *
+
+Apply the permissions to the target directory using the forthcoming
+tool C<febootstrap-fix-root> (requires root).
=back
-=head1 COMPARISON TO debootstrap
+=head1 RUNNING FEBOOTSTRAP AS ROOT
+
+There is some rudimentary support for running C<febootstrap> as root.
+However it is not well-tested and generally not recommended.
+
+=head1 COMPARISON TO DEBOOTSTRAP
febootstrap cannot do cross-architecture installs (C<debootstrap
--foreign>). The reason is that C<%pre> and C<%post> scripts cannot
=head1 OTHER RESTRICTIONS AND BUGS
-Some C<%post> scripts do not run correctly. The most common case is
-C</sbin/ldconfig>. Since this binary is statically linked, fakeroot
-and fakechroot's LD_PRELOAD hack does not work, so effectively
-ldconfig tries to update the system cache. You will see the following
-error:
+The following programs are not run during C<%post> scriptlets (because
+they are all statically linked, and fakechroot cannot run statically
+linked programs).
+
+=over 4
- /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
+=item C</sbin/ldconfig> (from many packages)
-This error is mostly harmless. Just run C</sbin/ldconfig> the first
-time you boot into the newly created Fedora system.
+=item C</usr/sbin/glibc_post_upgrade> (from C<glibc>)
+
+=item C</usr/sbin/build-locale-archive> (from C<glibc-common>)
+
+=item C</usr/sbin/libgcc_post_upgrade> (from C<libgcc>)
+
+=back
-Another error you will see is with C</usr/sbin/glibc_post_upgrade>
-which is caused for the same reason - this binary is statically
-linked. We have examined what this binary does, and it is not really
-necessary for installs. If it makes you happier, you can run it the
-first time you boot the new system.
+If you wish, you can run them the first time you boot into the new
+machine.
febootstrap recreates the repository anew each time, and this causes
yum to download all the RPMs every time. This is very wasteful, and
=head1 SEE ALSO
-L<febootstrap-to-initrd(8)>,
-L<febootstrap-fix-root(8)>,
+L<febootstrap-to-initramfs(8)>,
+L<febootstrap-minimize(8)>,
+L<febootstrap-run(8)>,
+L<febootstrap-install(8)>,
L<fakeroot(1)>,
L<fakechroot(1)>,
L<yum(8)>,
L<mock(1)>,
L<http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo>,
-L<debootstrap(8)>.
+L<http://thincrust.net/>,
+L<debootstrap(8)>,
+C<ubuntu-vm-builder>.
=head1 AUTHORS
git.annexia.org / febootstrap.git / blobdiff