What are known limitations and caveats when using UCK?

Created by Wolf Geldmacher
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
        architectures different from the one you run UCK on, e.g.
        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.