What are known limitations and caveats when using UCK?
- Keywords:
- Last updated by:
- Wolf Geldmacher
- UCK currently requires root privileges for many of the steps. You need to be
able to run sudo (fakeroot will not suffice!) on the machine that you
want to perform customization on. It is generally not a good idea to
run UCK on a server that must be available for production purposes.
It's way better to use a private workstation with no valuable data or
a virtual machine as host.
*** You have been warned! ***
- UCK performs customization of the root file system by running commands
(apt-get install et.al.) as root in a chroot environment. This implies that:
1) You generally cannot customize Live CD images for machine
customizing an image for ARM processors will not be possible
if your machine is x86 based. One exception to this rule is that
you can customize x86 images on an x86_64 host because 32bit
binaries can be run on 64bit Linux systems - the reverse (i.e.
customizing a 64bit system on a 32bit host) is not possible.
2) Some commands may not work in the chroot environment, especially
if they require services that can only be run once on a system.
3) While installing/removing packages in the chroot environment,
services may be stopped/started by the packaging scripts. You will
need to take care that these services (a) do not collide with
services running on the customization host and (b) that they
get terminated near the end of the root file system customization
because otherwise it may be impossible to successfully finish
the customization.
4) Even though commands run in a chroot environment they run with
full root privileges. It is therefore possible that the hosting
system is corrupted by commands going astray, e.g. if the date
command is run to set the date/time in the chrooted environment
the date/time of the hosting environment will be affected. Even
worse: Should a command create a device node that represents a
device in the hosting system and then decide to format that device
(or to install a bootloader someplace) the hosting system will
be unusable afterwards.
- There are known problems with placing the directories the customization
is done in (usually ~/tmp) on encrypted file systems and it doesn't really
make a lot of sense either - after all you are modifying open source software
that is freely available on the Net ;-)
- Placing the customization directory on a network drive may be possible.