Without these programs installed on my system I save several mega-bits in software and libraries. They can even make their own portables with the following programs from the same site: - AppDirAssistant: Utility to port the programs, it is necessary to run AppDirAssistant before installing the software to be ported; such software cannot be installed before running AppDirAssistant. Creating portables with this method will not look for dependencies installed in your operating system, nor will it save the configuration in your user folder unless a symbolic link is created within cde-root or the cde.
Seeing this we will realize that we can download or create the portables we want, eliminating the need to install extra applications outside our base system, and thus reduce your space when creating our own LiveCD.
Development As the title says, we will see how to create our own LiveCD from scratch which will allow us to install the applications we want starting by installing our base system, there are several ways to achieve this, one by means of a text mode installation without actually installing the graphic system and another using debootstrap, this last case is the one that we will address in this manual because it allows us to create our system from scratch without any extra program to the base system.
Step 4 We change the working root from the terminal with chroot and proceed to install the essential software according to our needs. If we use the traditional method from a web page and we use a proxy address, we will need to tell it to use this proxy from the same cage with the following command:.
Step 7 Install the version of the kernel that we are going to use, example:. Step 8 Proceed to install essential software for the correct boot of the system and subsequent creation of the LiveCD. Step 11 Install the graphical environment -Optional if you do not need to install a graphical environment. Step 12 Install the grub, if we do not have any grub installed in the boot sector we can do it in the following way:.
We install our preferred desktop environment as well as our session manager that we want. In my case, I installed the desktop environment e17 enlightenment together with the spacefm file explorer and thus created my own LiveCD to make backup copies, as well as I included the debootstrap program to install my new operating systems directly from the repositories without need to use other LiveCDs or text mode installations.
You can choose the desktop environment of your preference, as well as the set of applications to use. Remastersys has 2 LiveCD creation modes, one saving the configuration of all users and another removing all configuration and registration of another user, which is what we are used to seeing in traditional Ubuntu LiveCDs.
This process can take a while, depending on the speed of your computer and your network connection. When it is complete, there should be a live-image-i Note: If you are building on an amd64 system the name of the resulting image will be live-image-amd Keep in mind this naming convention throughout the manual.
Burning an ISO image is easy. Just install xorriso and use it from the command-line to burn the image.
For instance:. ISO images prepared with xorriso , can be simply copied to a USB stick with the cp program or an equivalent. Once you are certain you have the correct device name, use the cp command to copy the image to the stick. This will definitely overwrite any previous contents on your stick! Note: The sync command is useful to ensure that all the data, which is stored in memory by the kernel while copying the image, is written to the USB stick.
After copying the live-image-i To use the remaining free space, use a partitioning tool such as gparted or parted to create a new partition on the stick. One possible choice would be ext4. Note: If you want to use the extra space with Windows, apparently that OS cannot normally access any partitions but the first. Some solutions to this problem have been discussed on our mailing list , but it seems there are no easy answers. Remember: Every time you install a new live-image-i Since BIOSes vary greatly in features and key bindings, we cannot get into the topic in depth here.
Some BIOSes provide a key to bring up a menu of boot devices at boot time, which is the easiest way if it is available on your system. Otherwise, you need to enter the BIOS configuration menu and change the boot order to place the boot device for the live system before your normal boot device. Once you've booted the medium, you are presented with a boot menu.
If you just press enter here, the system will boot using the default entry, Live and default options. For more information about boot options, see the "help" entry in the menu and also the live-boot and live-config man pages found within the live system. Assuming you've selected Live and booted a default desktop live image, after the boot messages scroll by, you should be automatically logged into the user account and see a desktop, ready to use.
If you have booted a console-only image, you should be automatically logged in on the console to the user account and see a shell prompt, ready to use. It can be a great time-saver for the development of live images to run them in a virtual machine VM. This is not without its caveats:. Provided you can work within these constraints, survey the available VM software and choose one that is suitable for your needs. If your processor has hardware support for virtualization, use the qemu-kvm package; the qemu-kvm package description briefly lists the requirements.
First, install qemu-kvm if your processor supports it. If not, install qemu , in which case the program name is qemu instead of kvm in the following examples. The qemu-utils package is also valuable for creating virtual disk images with qemu-img. Create a new virtual machine, change the storage settings to use live-image-i Note: For live systems containing X. Otherwise, the resolution is limited to x In order to make the dkms package work, also the kernel headers for the kernel flavour used in your image need to be installed.
Instead of manually listing the correct linux-headers package in above created package list, the selection of the right package can be done automatically by live-build. Building an HDD image is similar to an ISO hybrid one in all respects except you specify -b hdd and the resulting filename is live-image-i Note: if you created an ISO hybrid image with the previous example, you will need to clean up your working directory with the lb clean command see The lb clean command :.
Run the lb config command as before, except this time specifying the HDD image type:. When the build finishes, a live-image-i Follow the instructions in Using an ISO hybrid live image , except use the filename live-image-i Then run kvm or qemu , depending on which version your host system needs, specifying live-image-i The following sequence of commands will create a basic netboot image containing a default live system without X.
It is suitable for booting over the network. Note: if you performed any previous examples, you will need to clean up your working directory with the lb clean command:. In this specific case, a lb clean --binary would not be enough to clean up the necessary stages.
The cause for this is that in netboot setups, a different initramfs configuration needs to be used which live-build performs automatically when building netboot images. Since the initramfs creation belongs to the chroot stage, switching to netboot in an existing build directory means to rebuild the chroot stage too. Therefore, lb clean which will remove the chroot stage, too needs to be used. Run the lb config command as follows to configure your image for netbooting:.
Different network filesystems can be chosen through lb config. The --net-root-path and --net-root-server options specify the location and server, respectively, of the NFS server where the filesystem image will be located at boot time. Make sure these are set to suitable values for your network and server. Typically, the next step is getting a higher level bootloader via the TFTP protocol. For example, if you unpack the generated live-image-i You should install the tftpd-hpa package.
Once the guest computer has downloaded and booted a Linux kernel and loaded its initrd, it will try to mount the Live filesystem image through a NFS server. Setting up these three services can be a little tricky. You might need some patience to get all of them working together. They might help, as their processes are very similar. Netboot image creation is made easy with live-build , but testing the images on physical machines can be really time consuming. Webbooting is a convenient way of retrieving and booting live systems using the internet as a means.
The requirements for webbooting are very few. On the one hand, you need a medium with a bootloader, an initial ramdisk and a kernel. On the other hand, a web server to store the squashfs files which contain the filesystem. Using prebuilt images would be handy for doing initial testing until one can fine tune their own needs.
The files are called vmlinuz , initrd. It is also possible to extract those files from an already existing iso image. In order to achieve that, loopback mount the image as follows:.
This method has the disadvantage that you need to be root to be able to mount the image. However, it has the advantage that it is easily scriptable and thus, easily automatized. But undoubtedly, the easiest way of extracting the files from an iso image and uploading it to the web server at the same time, is using the midnight commander or mc. If you have the genisoimage package installed, the two-pane file manager allows you to browse the contents of an iso file in one pane and upload the files via ftp in the other pane.
Even though this method requires manual work, it does not require root privileges. While some users will prefer virtualization to test webbooting, we refer to real hardware here to match the following possible use case which should only be considered as an example. In order to boot a webboot image it is enough to have the components mentioned above, i. This way, it is possible to use the downloaded compressed filesystem as a regular live system.
For example:. Use case: You have a web server in which you have stored two squashfs files, one which contains a full desktop, like for example gnome, and a standard one. If you need a graphical environment for one machine, you can plug your usb stick in and webboot the gnome image. If you need one of the tools included in the second type of image, perhaps for another machine, you can webboot the standard one.
This chapter contains an overview of the three main tools used in building live systems: live-build , live-boot and live-config.
These scripts are also referred to as "commands". The idea behind live-build is to be a framework that uses a configuration directory to completely automate and customize all aspects of building a Live image. Many concepts are similar to those used to build Debian packages with debhelper :. Unlike debhelper , live-build provides the tools to generate a skeleton configuration directory.
This could be considered to be similar to tools such as dh-make. For more information about these tools, read on, since the remainder of this section discuses the four most important commands. Note that the preceding lb is a generic wrapper for live-build commands. As constructing this directory by hand would be time-consuming and error-prone, the lb config command can be used to create the initial skeleton configuration tree.
Normally, you will want to specify some options. For example, to specify which package manager to use while building the image:. It then runs the lower level commands needed to build your Live system.
It is the job of the lb clean command to remove various parts of a build so subsequent builds can start from a clean state. By default, chroot , binary and source stages are cleaned, but the cache is left intact. Also, individual stages can be cleaned. For example, if you have made changes that only affect the binary stage, use lb clean --binary prior to building a new binary. If found, it will create a writable environment, using aufs, for Debian like systems to boot from.
It handles such tasks as setting the hostname, locales and timezone, creating the live user, inhibiting cron jobs and performing autologin of the live user. This chapter explains how to manage a live configuration from initial creation, through successive revisions and successive releases of both the live-build software and the live image itself. Live configurations rarely are perfect on the first try. It may be fine to pass lb config options from the command-line to perform a single build, but it is more typical to revise those options and build again until you are satisfied.
To support these changes, you will need auto scripts which ensure your configuration is kept in a consistent state. If you run lb config again, it will not reset any option that was defaulted based on your initial options.
So, for example, if you run lb config again with a new value for --binary-images , any dependent options that were defaulted for the old image type may no longer work with the new ones.
Nor are these files intended to be read or edited. They store values for over a hundred options, so nobody, let alone yourself, will be able to see in these which options you actually specified.
They are simple wrappers to the lb config , lb build and lb clean commands that are designed to help you manage your configuration. Each of these scripts is run automatically every time you run the corresponding lb command.
By using these scripts, your configuration is easier to read and is kept internally consistent from one revision to the next. Also, it will be much easier for you identify and fix options which need to change when you upgrade live-build after reading the updated documentation.
For your convenience, live-build comes with example auto shell scripts to copy and edit. Start a new, default configuration, then copy the examples into it:. When you want to make changes to them, edit the options in this file instead of passing them to lb config. Make sure you don't accidentally remove it when making edits. Use the lb config --config option to clone a Git repository that contains a live system configuration. This repository contains the configurations for the live systems prebuilt images.
For example, to build a standard image, use the live-images repository as follows:. For example, the unofficial non-free prebuilt images are made by simply adding --archive-areas "main contrib non-free".
This enables you to use lso: anywhere you need to specify the address of a salsa. If you also drop the optional. Cloning the entire live-images repository pulls the configurations used for several images. If you feel like building a different image after you have finished with the first one, change to another directory and again and optionally, make any changes to suit your needs. In any case, remember that every time you will have to build the image as superuser: lb build.
This chapter gives an overview of the various ways in which you may customize a live system. Live system configuration options are divided into build-time options which are options that are applied at build time and boot-time options which are applied at boot time. Boot-time options are further divided into those occurring early in the boot, applied by the live-boot package, and those that happen later in the boot, applied by live-config. Any boot-time option may be modified by the user by specifying it at the boot prompt.
The image may also be built with default boot parameters so users can normally just boot directly to the live system without specifying any options when all of the defaults are suitable. In particular, the argument to lb --bootappend-live consists of any default kernel command line options for the Live system, such as persistence, keyboard layouts, or timezone. See Customizing locale and language , for example. Build-time configuration options are described in the lb config man page.
Boot-time options are described in the man pages for live-boot and live-config. Although the live-boot and live-config packages are installed within the live system you are building, it is recommended that you also install them on your build system for easy reference when you are working on your configuration.
It is safe to do so, as none of the scripts contained within them are executed unless the system is configured as a live system.
The build process is divided into stages, with various customizations applied in sequence in each. The first stage to run is the bootstrap stage. This is the initial phase of populating the chroot directory with packages to make a barebones Debian system.
This is followed by the chroot stage, which completes the construction of chroot directory, populating it with all of the packages listed in the configuration, along with any other materials. Most customization of content occurs in this stage. The final stage of preparing the live image is the binary stage, which builds a bootable image, using the contents of the chroot directory to construct the root filesystem for the Live system, and including the installer and any other additional material on the target medium outside of the Live system's filesystem.
After the live image is built, if enabled, the source tarball is built in the source stage. Within each of these stages, there is a particular sequence in which commands are applied. These are arranged in such a way as to ensure customizations can be layered in a reasonable fashion. For example, within the chroot stage, preseeds are applied before any packages are installed, packages are installed before any locally included files are copied, and hooks are run later, after all of the materials are in place.
Depending on where the files are stored in the configuration, they may be copied into the live system's filesystem or into the binary image filesystem, or may provide build-time configurations of the system that would be cumbersome to pass as command-line options.
You may include things such as custom lists of packages, custom artwork, or hook scripts to run either at build time or at boot time, boosting the already considerable flexibility of debian-live with code of your own. The following chapters are organized by the kinds of customization task users typically perform: Customizing package installation , Customizing contents and Customizing locale and language cover just a few of the things you might want to do.
Perhaps the most basic customization of a live system is the selection of packages to be included in the image. This chapter guides you through the various build-time options to customize live-build 's installation of packages. The broadest choices influencing which packages are available to install in the image are the distribution and archive areas.
To ensure decent download speeds, you should choose a nearby distribution mirror. You can also add your own repositories for backports, experimental or custom packages, or include packages directly as files. You can define lists of packages, including metapackages which will install many related packages at once, such as packages for a particular desktop or language. Finally, a number of options give some control over apt , or if you prefer, aptitude , at build time when packages are installed.
You may find these handy if you use a proxy, want to disable installation of recommended packages to save space, or need to control which versions of packages are installed via APT pinning, to name a few possibilities. The distribution you choose has the broadest impact on which packages are available to include in your live image.
Specify the codename, which defaults to buster for the buster version of live-build. Any current distribution carried in the archive may be specified by its codename here. See Terms for more details. The --distribution option not only influences the source of packages within the archive, but also instructs live-build to behave as needed to build each supported distribution.
For example, to build against the unstable release, sid , specify:. Within the distribution archive, archive areas are major divisions of the archive. In Debian, these are main , contrib and non-free. Only main contains software that is part of the Debian distribution, hence that is the default. One or more values may be specified, e.
Experimental support is available for some Debian derivatives through a --mode option. By default, this option is set to debian only if you are building on a Debian or on an unknown system. If lb config is invoked on any of the supported derivatives, it will default to create an image of that derivative. If lb config is run in e. The mode also modifies live-build behaviour to suit the derivatives. Note: The projects for whom these modes were added are primarily responsible for supporting users of these options.
The Debian Live Project, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
The Debian archive is replicated across a large network of mirrors around the world so that people in each region can choose a nearby mirror for best download speed.
Recall from Stages of the build that the bootstrap stage is when the chroot is initially populated by debootstrap with a minimal system, and the chroot stage is when the chroot used to construct the live system's filesystem is built. Thus, the corresponding mirror switches are used for those stages, and later, in the binary stage, the --mirror-binary and --mirror-binary-security values are used, superseding any mirrors used in an earlier stage. To set the distribution mirrors used at build time to point at a local mirror, it is sufficient to set --mirror-bootstrap and --mirror-chroot-security as follows.
The chroot mirror, specified by --mirror-chroot , defaults to the --mirror-bootstrap value. These may be used to install additional packages while running the live system. The defaults employ deb. This is a suitable choice when you cannot predict which mirror will be best for all of your users.
Or you may specify your own values as shown in the example below. An image built from this configuration would only be suitable for users on a network where " mirror " is reachable. You may add more repositories, broadening your package choices beyond what is available in your target distribution.
These may be, for example, for backports, experimental or custom packages. There are a number of ways to choose which packages live-build will install in your image, covering a variety of different needs.
You can simply name individual packages to install in a package list. You can also use metapackages in those lists, or select them using package control file fields. Package lists are a powerful way of expressing which packages should be installed. The list syntax supports conditional sections which makes it easy to build lists and adapt them for use in multiple configurations. Package names may also be injected into the list using shell helpers at build time.
Note: The behaviour of live-build when specifying a package that does not exist is determined by your choice of APT utility. See Choosing apt or aptitude for more details. The simplest way to populate your package list is to use a task metapackage maintained by your distribution. This supercedes the older predefined list method supported in live-build 2. Unlike predefined lists, task metapackages are not specific to the Live System project. Instead, they are maintained by specialist working groups within the distribution and therefore reflect the consensus of each group about which packages best serve the needs of the intended users.
They also cover a much broader range of use cases than the predefined lists they replace. Email Required, but never shown. The Overflow Blog. Does ES6 make JavaScript frameworks obsolete? Podcast Do polyglots have an edge when it comes to mastering programming Featured on Meta. Now live: A fully responsive profile. Related 3. Hot Network Questions. A live install image contains a Debian system that can boot without modifying any files on the hard drive and also allows installation of Debian from the contents of the image.
Is a live image suitable for me? Here are some things to consider that will help you decide. Many users will find these initial package selections suitable, installing any additional packages they need from the network afterwards. Architecture: Only images for the two most popular architectures, bit PC i and bit PC amd64 , are currently provided.
0コメント