Debian Live. All configuration that is done during run time is done by live-config. Here are some of the most common options of live-config that users are interested in.
A full list of all possibilities can be found in the man page of live-config. One important consideration is that the live user is created by live-boot at boot time, not by live-build at build time. You can specify additional groups that the live user will belong to by using any of the possibilities to configure live-config. It is also possible to change the default username "user" and the default password "live". If you want to do that for any reason, you can easily achieve it as follows:.
To change the default username you can simply specify it in your config:. One possible way of changing the default password is by means of a hook as described in Boot-time hooks. To define the locale that should be generated, use the locales parameter in the --bootappend-live option of lb config , e. This parameter, as well as the keyboard configuration parameters indicated below, can also be used at the kernel command line. Both the console and X keyboard configuration are performed by live-config using the console-setup package.
To configure them, use the keyboard-layouts , keyboard-variants , keyboard-options and keyboard-model boot parameters via the --bootappend-live option. Note that each variant lists the layout to which it applies in the description. Often, only the layout needs to be configured. For example, to get the locale files for German and Swiss German keyboard layout in X use:. However, for very specific use cases, you may wish to include other parameters.
If multiple keyboard-variants values are given, they will be matched one-to-one with keyboard-layouts values see setxkbmap 1 -variant option. Empty values are allowed; e.
A live cd paradigm is a pre-installed system which runs from read-only media, like a cdrom, where writes and modifications do not survive reboots of the host hardware which runs it.
A live system is a generalization of this paradigm and thus supports other media in addition to CDs; but still, in its default behaviour, it should be considered read-only and all the run-time evolutions of the system are lost at shutdown. To understand how it works it would be handy to know that even if the system is booted and run from read-only media, modifications to the files and directories are written on writable media, typically a ram disk tmpfs and ram disks' data do not survive reboots.
All these media are supported in live systems in different ways, and all but the last one require a special boot parameter to be specified at boot time: persistence.
If the boot parameter persistence is set and nopersistence is not set , local storage media e. It is possible to restrict which types of persistence volumes to use by specifying certain boot parameters described in the live-boot 7 man page.
This manual serves as a single access point to all documentation related to the Debian Live Project and in particular applies to the software produced by the project for the Debian 9. While live-manual is primarily focused on helping you build a live system and not on end-user topics, an end user may find some useful information in these sections: The Basics covers downloading prebuilt images and preparing images to be booted from media or the network, either using the web builder or running live-build directly on your system.
Customizing run time behaviours describes some options that may be specified at the boot prompt, such as selecting a keyboard layout and locale, and using persistence. Some of the commands mentioned in the text must be executed with superuser privileges which can be obtained by becoming the root user via su or by using sudo. This symbol is not a part of the command. While we believe that everything in this manual is important to at least some of our users, we realize it is a lot of material to cover and that you may wish to experience early success using the software before delving into the details.
Therefore, we suggest reading in the following order. First, read this chapter, About this manual , from the beginning and ending with the Terms section. Next, skip to the three tutorials at the front of the Examples section designed to teach you image building and customization basics.
Read Using the examples first, followed by Tutorial 1: A default image , Tutorial 2: A web browser utility and finally Tutorial 3: A personalized image. By the end of these tutorials, you will have a taste of what can be done with live systems. We encourage you to return to more in-depth study of the manual, perhaps next reading The basics , skimming or skipping Building a netboot image , and finishing by reading the Customization overview and the chapters that follow it.
By this point, we hope you are thoroughly excited by what can be done with live systems and motivated to read the rest of the manual, cover-to-cover. This manual is intended as a community project and all proposals for improvements and contributions are extremely welcome.
Please see the section Contributing to the project for detailed information on how to fetch the commit key and make good commits. 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 automated. 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.
0コメント