Technic Dynamic is a source of education focused in the following categories of technology: (Computer - Design - Gadgets - Networking - Security) Link : http://technicdynamic.com
As described in the section called "Devices Requiring Firmware”, some devices require
firmware to be loaded. In most cases the device will not work at all
if the firmware is not available; sometimes basic functionality is not
impaired if it is missing and the firmware is only needed to enable
additional features.
If a device driver requests firmware that is not available, debian-installer will
display a dialog offering to load the missing firmware. If this option
is selected, debian-installer will scan available devices for either loose firmware
files or packages containing firmware. If found, the firmware will be
copied to the correct location (/lib/firmware) and
the driver module will be reloaded.
Which devices are scanned and which file systems are supported depends on
the architecture, the installation method and the stage of the installation.
Especially during the early stages of the installation, loading the firmware
is most likely to succeed from a FAT-formatted floppy disk or USB stick.
On i386 and amd64 firmware can also be loaded from an
MMC or SD card.
Note that it is possible to skip loading the firmware if you know the
device will also function without it, or if the device is not needed during
the installation.
Support for loading firmware is still relatively basic and is likely to
be improved in future releases of the installer. Currently debian-installer will
for example not display any warning if you choose to load missing firmware,
but the requested firmware is not found.
Please report any issues you encounter by filing an installation report
(see the section called "Submitting Installation Reports”).
Preparing a medium
Although in some cases the firmware can also be loaded from a partition on
a hard disk, the most common method to load firmware will be from some
removable medium such as a floppy disk or a USB stick.
The firmware files or packages must be placed in either the root directory
or a directory named /firmware of the file system on
the medium. The recommended file system to use is FAT as that is most
certain to be supported during the early stages of the installation.
Tarballs containing current packages for the most common firmware are
available from:
Just download the tarball for the correct release and unpack it to the file
system on the medium.
If the firmware you need is not included in the tarball, you can also
download specific firmware packages from the (non-free section of the)
archive. The following overview should list most available firmware
packages but is not guaranteed to be complete and may also contain
non-firmware packages:
It is also possible to copy individual firmware files to the medium. Loose
firmware could be obtained for example from an already installed system or
from a hardware vendor.
... Read more »
Here is a list of installer components with a brief description
of each component's purpose. Details you might need to know about
using a particular component are in the section called "Using Individual Components”.
main-menu
Shows the list of components to the user during installer operation,
and starts a component when it is selected. Main-menu's
questions are set to priority medium, so if your priority is set to
high or critical (high is the default), you will not see the menu. On
the other hand, if there is an error which requires your intervention,
the question priority may be downgraded temporarily to allow you
to resolve the problem, and in that case the menu may appear.
You can get to the main menu by selecting the Go Back button
repeatedly to back all the way out of the currently running component.
... Read more »
The Ubuntu Installer (based on the Debian Installer, and so often called
simply debian-installer) consists of a number of special-purpose
components to perform each installation task. Each component performs
its task, asking the user questions as necessary to do its job.
The questions themselves are given priorities, and the priority
of questions to be asked is set when the installer is started.
When a default installation is performed, only essential (high priority)
questions will be asked. This results in a highly automated installation
process with little user interaction. Components are automatically run
in sequence; which components are run depends mainly on the installation
method you use and on your hardware. The installer will use default values
for questions that are not asked.
If there is a problem, the user will see an error screen, and the
installer menu may be shown in order to select some alternative
action. If there are no problems, the user will never see the
installer menu, but will simply answer questions for each component
in turn. Serious error notifications are set to priority
"critical” so the user will always be notified.
Some of the defaults that the installer uses can be influenced by passing
boot arguments when debian-installer is started. If, for example, you wish to
force static network configuration (DHCP is used by default if available),
you could add the boot parameter netcfg/disable_dhcp=true.
See the section called "Ubuntu Installer Parameters” for available options.
Power users may be more comfortable with a menu-driven interface,
where each step is controlled by the user rather than the installer
performing each step automatically in sequence. To use the installer
in a manual, menu-driven way, add the boot argument
priority=medium.
If your hardware requires you to pass options to kernel modules as
they are installed, you will need to start the installer in
"expert” mode. This can be done by either using the
expert command to start the installer or by adding
the boot argument priority=low.
Expert mode gives you full control over debian-installer.
For this architecture the debian-installer supports two different user interfaces: a
character-based one and a graphical one. The character-based interface is
used by default unless you selected the "Graphical install”
option in the initial boot menu. For more information about the
graphical installer, please refer to the section called "The Graphical Installer”.
In the character-based environment the use of a mouse is not supported.
Here are the keys you can use to navigate within the
various dialogs. The Tab or right
arrow keys move "forward”, and the Shift+Tab or left arrow keys
move "backward” between displayed buttons and selections.
The up and down arrow select
different items within a scrollable list, and also scroll the list
itself. In addition, in long lists, you can type a letter to cause the
list to scroll directly to the section with items starting with the
letter you typed and use Pg-Up and
Pg-Down to scroll the list in sections. The
space bar selects an item such as a checkbox. Use
Enter to activate choices.
... Read more »
Sometimes, especially with older CD-ROM drives, the installer may fail
to boot from a CD-ROM. The installer may also — even after booting
successfully from CD-ROM — fail to recognize the CD-ROM or return
errors while reading from it during the installation.
There are many different possible causes for these problems. We can
only list some common issues and provide general suggestions on how to
deal with them. The rest is up to you.
There are two very simple things that you should try first.
If the CD-ROM does not boot, check that it was inserted correctly and that
it is not dirty.
If the installer fails to recognize a CD-ROM, try just running the option
Detect and mount CD-ROM
a second time. Some DMA related issues with older CD-ROM drives are known to
be resolved in this way.
If this does not work, then try the suggestions in the subsections below.
Most, but not all, suggestions discussed there are valid for both CD-ROM and
DVD, but we'll use the term CD-ROM for simplicity.
If you cannot get the installation working from CD-ROM, try one of the
other installation methods that are available.
Common issues
Some older CD-ROM drives do not support reading from discs that were burned
at high speeds using a modern CD writer.
If your system boots correctly from the CD-ROM, it does not necessarily
mean that Linux also supports the CD-ROM (or, more correctly, the controller
that your CD-ROM drive is connected to).
Some older CD-ROM drives do not work correctly if "direct memory
access” (DMA) is enabled.
Boot parameters are Linux kernel parameters which are generally used
to make sure that peripherals are dealt with properly. For the most
part, the kernel can auto-detect information about your peripherals.
However, in some cases you'll have to help the kernel a bit.
If this is the first time you're booting the system, try the default
boot parameters (i.e., don't try setting parameters) and see if it works
correctly. It probably will. If not, you can reboot later and look for
any special parameters that inform the system about your hardware.
should be emitted early in the process.
total should match the total amount of RAM,
in kilobytes. If this doesn't match the actual amount of RAM you have
installed, you need to use the
mem=ram parameter,
where ram is set to the amount of memory,
suffixed with "k” for kilobytes, or "m” for
megabytes. For example, both mem=65536k and
mem=64m mean 64MB of RAM.
If you are booting with a serial console, generally the kernel will
autodetect this.
If you have a videocard (framebuffer) and a keyboard also attached to
the computer which you wish to boot via serial console, you may have
to pass the
console=device
argument to the kernel, where device is
your serial device, which is usually something like
ttyS0.
Ubuntu Installer Parameters
The installation system recognizes a few additional boot parameters which may be useful.
A number of parameters have a "short form” that helps avoid
the limitations of the kernel command line options and makes entering the
parameters easier. If a parameter has a short form, it will be listed in
brackets behind the (normal) long form. Examples in this manual will
normally use the short form too.
debconf/priority (priority)
This parameter sets the lowest priority of messages to be displayed.
The default installation uses priority=high.
This means that both high and critical priority messages are shown, but medium
and low priority messages are skipped.
If problems are encountered, the installer adjusts the priority as needed.
If you add priority=medium as boot parameter, you
will be shown the installation menu and gain more control over the installation.
When priority=low is used, all messages are shown
(this is equivalent to the expert boot method).
With priority=critical, the installation system
will display only critical messages and try to do the right thing without fuss.
... Read more »
Some users may need specific support because of e.g. some visual
impairment.
USB braille displays are detected
automatically, but most other
accessibility features have to be enabled manually.
On machines that support it, the boot menu emits a beep
when it is ready to receive keystrokes.
Some boot parameters can then be appended to
enable accessibility features. Note that on most architectures the boot
loader interprets your keyboard as a QWERTY keyboard.
USB Braille Displays
USB braille displays should be automatically detected. A textual version
of the installer will then be automatically selected, and support for the
braille display will be automatically installed on the target system.
You can thus just press Enter at the boot menu.
Once brltty is started, you can choose a braille
table by entering the preference menu. Documentation on key
bindings for braille devices is available on the brltty website.
Serial Braille Displays
Serial braille displays cannot safely be automatically detected
(since that may damage some of them). You thus need to append the
brltty=driver,port,table
boot parameter to tell brltty which driver it
should use. driver should be replaced by the
two-letter driver code for your terminal (see the
driver code list).
port should be replaced by the name of the
serial port the display is connected to, ttyS0 is
the default. table is the name of the braille
table to be used (see the table code
list); the English table is the default. Note that the table can
be changed later by entering the preference menu. Documentation on key
bindings for braille devices is available on the brltty website.
Hardware Speech Synthesis
Support for hardware speech synthesis devices is available only alongside
support for graphical installer. You thus need to select the
"Graphical install” entry in the boot menu.
Hardware speech synthesis devices cannot be automatically detected. You
thus need to append the
speakup.synth=driver
boot parameter to tell speakup which driver it should
use. driver should be replaced by the driver code
for your device (see driver code
list). The textual version of the installer will then be
automatically selected, and support for the speech synthesis device will be
automatically installed on the target system.
Board Devices
Some accessibility devices are actual boards that are plugged inside the
machine and that read text directly from the video memory. To get them
to work framebuffer support must be disabled by using the
vga=normalfb=false
boot parameter. This will however reduce the number of available languages.
If desired a textual version of the bootloader can be activated before adding
the boot parameter by typing hEnter.
If you have any other operating systems on your system that you wish to
keep (dual boot setup), you should make sure that they have been properly
shut down before you boot the installer.
Installing an operating system while another operating system is in
hibernation (has been suspended to disk) could result in loss of, or damage
to the state of the suspended operating system which could cause problems
when it is rebooted.
The easiest route for most people will be to use an Ubuntu CD.
If you have a CD, and if your machine supports booting directly off
the CD, great! Simply
configure your system for booting off a CD as described in
the section called "Boot Device Selection”,
insert your CD, reboot, and proceed to the next chapter.
Note that certain CD drives may require special drivers, and thus be
inaccessible in the early installation stages. If it turns out the
standard way of booting off a CD doesn't work for your hardware,
revisit this chapter and read about alternate kernels and installation
methods which may work for you.
If you intend to use the hard drive only for booting and then
download everything over the network, you should download the
netboot/ubuntu-installer/i386/initrd.gz file and its
corresponding kernel
netboot/ubuntu-installer/i386/linux. This will allow you
to repartition the hard disk from which you boot the installer, although you
should do so with care.
For LILO, you will need to configure two
essential things in /etc/lilo.conf:
to load the initrd.gz installer at boot time;
have the vmlinuz kernel use a RAM disk as
its root partition.
For more details, refer to the
initrd(4) and
lilo.conf(5) man pages. Now run
lilo and reboot.
The procedure for GRUB is quite similar. Locate your
menu.lst in the /boot/grub/
directory (or sometimes /boot/boot/grub/) and add an
entry for the installer, for example (assuming /boot
is on the first partition of the first disk in the system):
title New Install
root (hd0,0)
kernel /boot/newinstall/vmlinuz
initrd /boot/newinstall/initrd.gz
From here on, there should be no difference between GRUB
or LILO.
For installing on multiple computers it's possible to do fully
automatic installations using the Ubuntu Installer itself.
Automatic Installation Using the Ubuntu Installer
The Ubuntu Installer supports automating installs via preconfiguration
files. A preconfiguration file can be loaded from the network or from
removable media, and used to fill in answers to questions asked during the
installation process.
The Ubuntu installer has preliminary support for automating installs using
Kickstart files, as designed by Red Hat for use in their Anaconda installer.
This method is not as flexible as the preconfiguration file method above,
but it requires less knowledge of how the installer works.
This section documents only the basics, and differences between Anaconda and
the Ubuntu installer. Refer to the
Red Hat documentation for detailed instructions.
To generate a Kickstart file, install the
system-config-kickstart package and run
system-config-kickstart. This offers you a graphical
user interface to the various options available.
Once you have a Kickstart file, you can edit it if necessary, and place it
on a web, FTP, or NFS server, or copy it onto the installer's boot media.
Wherever you place the file, you need to pass a parameter to the installer
at boot time to tell it to use the file.
To make the installer use a Kickstart file downloaded from a web or FTP
server, add ks=http://url/to/ks.cfg or ks=ftp://url/to/ks.cfg respectively
to the kernel boot parameters. This requires the installer to be able to set
up the network via DHCP on the first connected interface without asking any
questions; you may also need to add ksdevice=eth1 or similar if the
installer fails to determine the correct interface automatically.
Similarly, to make the installer use a Kickstart file on an NFS server, add
ks=nfs:server:/path/to/ks.cfg to the kernel boot parameters. The method
supported by Anaconda of adding a plain "ks" boot parameter to work out the
location of the Kickstart file from a DHCP response is not yet supported by
the Ubuntu installer.
To place a Kickstart file on a CD, you would need to remaster the ISO image
to include your Kickstart file, and add ks=cdrom:/path/to/ks.cfg to the
kernel boot parameters. See the manual page for mkisofs for details.
Alternatively, put the Kickstart file on a floppy, and add
ks=floppy:/path/to/ks.cfg to the kernel boot parameters.
... Read more »
If your machine is connected to a local area network, you may be able
to boot it over the network from another machine, using TFTP. If you
intend to boot the installation system from another machine, the
boot files will need to be placed in specific locations on that machine,
and the machine configured to support booting of your specific machine.
You need to set up a TFTP server, and for many machines a DHCP
server, or BOOTP
server.
BOOTP is an IP protocol that
informs a computer of its IP address and where on the network to obtain
a boot image.
The DHCP (Dynamic Host Configuration Protocol) is a more flexible,
backwards-compatible extension of BOOTP.
Some systems can only be configured via DHCP.
The Trivial File Transfer Protocol (TFTP) is used to serve the boot
image to the client. Theoretically, any server, on any platform,
which implements these protocols, may be used. In the examples in
this section, we shall provide commands for SunOS 4.x, SunOS 5.x
(a.k.a. Solaris), and GNU/Linux.
For an Ubuntu or Debian GNU/Linux server we recommend
tftpd-hpa.
It's written by the same author as the syslinux
bootloader and is therefore least likely to cause issues.
A good alternative is atftpd.
Setting up a DHCP server
One free software DHCP server is ISC dhcpd.
For Ubuntu, the dhcp3-server package is
recommended. Here is a sample configuration file for it (see
/etc/dhcp3/dhcpd.conf):
The installer may be booted using boot files placed on an
existing hard drive partition, either launched from another operating
system or by invoking a boot loader directly from the BIOS.
A full, "pure network” installation can be achieved using this
technique. This avoids all hassles of removable media, like finding
and burning CD images or struggling with too numerous and
unreliable floppy disks.
The installer cannot boot from files on an NTFS file system.
Hard disk installer booting using LILO or
GRUB
This section explains how to add to or even replace an existing linux
installation using either LILO or
GRUB.
At boot time, both bootloaders support loading in memory not
only the kernel, but also a disk image. This RAM disk can be used as
the root file-system by the kernel.
Copy the following files from the Ubuntu archives to a
convenient location on your hard drive, for instance to
/boot/newinstall/.