4.3 Linux under microscope.
Section contents:
4.3.1. BIOS rule in booting.
When you turn the computer on, Basic Input/Output System (BIOS)
will count and check RAM, and initiate devices.
Then it search for boot loader in a sequence as specified
by BIOS setup, usually floppy, CDROM then hard disk,
hard disk could be configured to be first for more security.
Where and for what ? the first sector of any disk is called
Boot record, this will be read and make sure it has a mark (called Magic Number),
if it's there then it's loaded into memory and executed,
if it's not found BIOS checks for next disk in sequence,
if it's never founded it display an error message.
A hard disk has a boot record for every partition, non will
be read by BIOS, the disk has another record called Master Boot Record (MBR)
that's the one the BIOS checks for.
The MBR holds a very small program (in the size of a sector, just 512 byte!)
called Boot loader, to be specific 'first stage boot loader'.
You could connect two disks on the same IDE belt to the motherboard.
Usually there are two sockets (place) to connect two of those belts
to the motherboard this means we could put 4 IDE disks, the two
sockets are numbered, we call the one with the smaller number 'primary'
and the other 'secondary'. The order of disks on one belt is
selected by putting a Jumper (a small metalic connector covered with plastic
placed to close a circuit and used as a switch)
in some specific place on the disk to sspecify if it's the 'master' disk
or the 'slave' disk, the way you should put the jumper is found on the disk,
and it's specific to manufacturer.
The disk in which the BIOS search for MBR is primary master.
In Linux, the primary master disk is called hda,
primary slave is called hdb, secondary master is called hdc,
secondary slave is called hdd, the first partition of hda
is called hda1.
Each time you connect a new hard disk or switch its place
you have to enter BIOS setup and tell it about that, some
BIOSs could be configured to automatically checks the disk
type but this slows the booting time, each time you boot
BIOS do a stupid slow check to detect disk types.
Linux does not need a functional BIOS configuration for disk type,
it do a smarter faster check each time you boot to detect disks,
but this procedure helps MS Windows to be able access to disks,
if you don't use it, you could at BIOS setup disable all disks except the
one with booting data (MBR and boot loader files), this will save few
seconds of BIOS boot time!
4.3.2. The boot loader.
The boot loader might be a program that asks you to select the OS you want to boot
from a list of installed systems like BootMagic, but in usual DOS or Windows
their usual boot loader is a non-interactive program that has the physical
address of system files 'COMMAND.COM', 'IO.SYS' and 'MSDOS.SYS'
to be loaded, it will ignore other systems on other partitions,
it could not pass any option to the system, for that we say it's not a
Multi-boot system, it has the following disadvatages:
- It could not boot if any of those three files where
touched by any mean (eg. moved to other direcory then brought back to their
original location) because it keeps their physical address(cyl/head/sect)
of them and uses the BIOS to acces them.
- Those files should be in the first disk and partition visible to DOS/Windows
(ie. the one called C), if you have Windows installed somewhere else
it will put some files on C, by formattin the C the Windows placed
elsewhere will not boot.
There are many boot loaders for Linux, including
LILO, GRUB, SysLinux and Isolinux. Linux Loader (LILO)
is the most common one, it could offer a prompt, colored console menu
or graphical menu with 640x480 BMP background image at 16 color
or 320x200 PCX image at 256 color (distribution specific),
it could boot Linux and pass it arguments, it could boot
Windows and do some tricks to be able to boot Windows on the second primary
partition (maybe called D) by hidding the first (mabye called C).
If you made any change to any file used
by LILO (eg. the background image), then you have to rerun it
by typing 'lilo' as root, then it will update the new file
location.
GRUB from GNU, is aimed in the first place to replace LILO!
and to boot Linux, in the second place. GRUB has many features
as LILO like telling lies to Windows by hidding partitions,
passing options not only to Linux but also to OS/2 and
many UNIX-like systems as GNU/Hurd and FreeBSD.
The most wonderful feature of GRUB is that it could
access to file systems inculding FAT and ext3 among other,
so there is no need to rerun GRUB when changing the background
image or modifying the configuration file, also it could
boot systems not found in the configuration file through a BASH-like
command line useful for rescue.
SysLinux is used in rescue floppies because it could access to FAT
file systems, while IsoLinux is the most common to boot CDROMs.
LoadLin is a program running under DOS (but not Windows)
that could load Linux kernel into memory and boot it removing everything else.
It's very userful when you don't want to repratition your disk nor changing
your boot loader, it comes with some distributions like SOT.
An amazing infamous fact that Linux could boot without a boot loader,
but then you can't pass it arguments, to test this put a floppy
and type the follwoing:
bash# dd if=/boot/vmlinuz of=/dev/fd0 bs=1024
kernel panic : can't find root file system
4.3.3. The kernel.
There are two type of Linux kernels; 'vmlinuz' and 'bz2Image'
according to the compression method, bz2 kernels are used for large kernel
having many or all drives built-in it.
The file is called kernel image, 'vmlinuz' usually is just link to a file like 'vmlinux-2.4.24' that
specify version number (and the vendor), the followin are examples of kernel images:
/boot/vmlinuz
/boot/vmlinuz-2.4.18
/boot/vmlinuz-2.4.20-mdk-9
/boot/bz2Image
/boot/bz2Image-2.4.18
/boot/bz2Image-2.4.20-ErrorMsg-3
vmlinuz-2.5.56 testing
vmlinuz-2.4.21 stable
It's good to mention that a file called 'vmlinux' (ends with x not z)
is just an intermediate file (found on Red Hat Linux) and could
be safely remove (I wonder why do they keep it).
4.3.4. Passing arguments to kernel.
The boot loader could pass some options to the kernel, the kernel
receives them, if the value of some option is not specified then
it use the defaults, to know or change the default value for a kernel
image use the following 5 tools: rdev, swapdev, ramsize, vidmode,
and rootflags, they mean:
- rdev : root device
- rdev : swap device
- ramsize : ram disk size (0 if non)
- vidmode : vedio mode (for text console)
- rootflags: mount root disk ( read only ) or ( read & write )
to know more about them type:
bash$ man rdev
bash$ rdev /boot/vmlinuz
A RAM disk could be used in making a rescue floppy disk or to
load important drivers (modules) before mounting the root file sytem,
for example the kernel shiped with Red Hat Linux 8.0 does not support ext3
directely and it's installed on an ext3 file system, then how it
could read the root file system ? they create a small disk image
of ext2 file system (which is supported) they put in it files
having the driver for ext3, they call it 'initrd' (initial RAM disk),
it could be made by 'mkinitrd' tool or manually as a usual RAM disk,
see next subsection. Although 'initrd' is a RAM disk, we don't use
rdev to set it, it should be loaded by the boot loader
(eg. LILO) which means it should be visible to BIOS.
After mounting the initial RAM disk, the kernel searches for a script
called '/linuxrc' which should contain steps needed
to make the kernel ready to boot, for example to make it able to see the
root file system for example using 'modprobe' to load the ext3 module,
loading the ethernet module and running a DHCP client to get an IP
address then mounting a remote NFS file system (to be the root file system)
or even running 'losetup' to set /dev/loop0
to point to some file of some encryption.... and many more special
cases where the root file system is not avaliable or ready
and need some preparing before mounting. The kernel switches the root
directory from the initrd to the real one (as specified by root parameter
or 'rdev' default), and the initrd will become mounted to '/initrd'
(which should exist) in the new environment instead of root.
I was wondering why does Red Hat do all that instead of just
putting ext3 in the kernel, specialy that they offer no other native
system like reiserfs or xfs ? The reason is that they support
LVM and RAID which needs initrd to be used, but this is not an execuse
for not putting their only native file system (besides ext2) ext3 support directely in the kernel
 Tip
I did some experments on little kernels found on some distributions installation
floppies by putting them in '/boot' to be used to boot the system installed on
the hard disk then I observed the results, usually many featured was turned off (eg. sound)
but in case of the kernel found on Debian installation floppy,
it did not boot giving a kernel panic that it can't mount the root file system
even though it's ext2, that was because it does not have built-in support
for any thing including IDE where the ext2 system exists!
You can pass many more arguments to the kernel like:
| root=/dev/hda7 |
making hda7 the root file system |
| ro |
mount it for read only in order to check it safely |
| rw |
mount it for read and write |
| load_ramdisk=1 |
enable the RAM disk (0 to disable it) |
| prompt_ramdisk=1 |
give you a chance to replace the kernel floppy with the second
floppy with RAM disk, useful for rescue disks |
| ramdisk_size=4096 |
the size of RAM disk is 4096KB |
| ramdisk_start=400 |
The offset of the RAM disk from the begining of the floppy. |
| init=/sbin/init |
the first program to execute will be /sbin/init |
| mca-pentium |
Needed by IBM-95 Microchannle, to overcome a bu in it. |
| panic=10 |
restart the computer after 10 seconds of a kernel panic
(eg. when you ask it to mount hda8 as root but there is no hda8)
|
| quiet |
the kernel does not print any message, you could use the tool 'dmesg'
to read the booting messages later. |
| reboot=warm |
tell the BIOS not to count memory,check disks...etc when restarting
the computer next time, in contrary of cold |
| vga=ask |
the kernel will ask about the console screen mode (number of raws and columns) |
| ram=64m |
some BIOS report less RAM size than the actual size,
this option is used to pass the real size of RAM, in the example it's 64MB. |
| hda=cyl,head,sec |
in case of you like to pass different geometry for hda |
| sound=sound-driver |
specifying the module for very old non-PNP ISA sound cards. |
| idle=poll |
used to make an SMP kernels on a system of multiple CPUs faster
(needs more power) |
notice that there are no space before nor after '=' sign.
4.3.5. Creating rescue disks.
The kernel detects every thing (hard disks, CDROM drivers, Video adaptor,..etc)
it process parameters passed by the boot loaders, for example one may ask something
not to be detected. The root file system is not yet mounted,
the kernel searches for a commpressed image of file system to be loaded
into RAM (here comes the name RAM disk) and mount it as root, it looks for
it where specified by some boot-time parameters (eg. ramdisk_size and ramdisk_start)
if any or by 'rdev' tools. This disk image could be created
with the right size by dd tool, then formated to
a supported file system with mke2fs or mkfs.minix
then mount it, then put the needed files (tools,configuration,documentation,...etc)
into it, then umount it and compress the image and add it to the kernel,
type the following commands to create a toy rescue 'bash' disk.
Tip
This is just a toy educational rescue disk, for a real one use ready solution
from your distribution or try 'tomsrtbt' single floppy distribution.
 Warning
Be aware! this procedure will not damage your distribution, but any typing mistake will.
bash$ su
bash# dd if=/dev/zero of=~/fsImage bs=1024 count=4096
4096+0 records in
4096+0 records out
bash# mkfs.minix ~/fsImage
bash# mkdir /mnt/test
bash# mount -o loop -t minix ~/fsImage /mnt/test
bash# cd /mnt/test
bash# mkdir bin usr tmp var proc sbin lib etc
bash# cp /bin/bash /mnt/test/bin/
bash# cd /mnt/test/sbin && ln -s ../bin/bash init
bash# cd ~
Tip
notice how we have linked 'init' to point to 'bash', so that when the
kernel starts it, it's actually running BASH! you will not be asked
for a password, no virtual terminal, no getty's and no CTRL+ALT+DEL,
it's just BASH.
continue :
bash# ldd /bin/bash
# notice the libraries and copy them
bash# cp -avi /lib/libc.*so* /mnt/test/lib
bash# cp -avi /lib/ld.so /mnt/test/lib
bash# cp -avi /lib/libncurses.*so* /mnt/test/lib
bash# umount /mnt/test
bash# gzip -9 < ~/fsImage > ~/fsImage.gz
bash# dd if=/boot/vmlinuz-old-with-minix-support of=floppy.img bs=1k
399+0 records in
399+0 records out
bash# dd if=fsImage.gz of=floppy.img bs=1k seek=400
bash# rdev floppy.img /dev/fd0
bash# rdev -R floppy.img 0
bash# rdev -r floppy.img $((16384+400))
bash# dd if=floppy.img of=/dev/fd0 bs=1k
bash# dd if=/boot/vmlinuz-big-new of=/dev/fd0 bs=1k
bash# rdev /dev/fd0 /dev/fd0
bash# rdev -r /dev/fd0 49152
# label it first disk, and put the second on then type
bash# dd if=fsImage.gz of=/dev/fd0 bs=1k
# label it second disk
Tip
Do not confuse initial RAM disk (initrd) with RAM disk, because
the root in the first will be usual hard disk partition after
a preperation stage where a compressed file system
image (usually found on /boot/initrd-ver) is
loaded by boot loader having '/linuxrc' script to be executed, but
in the RAM disk case, it's loaded by kernel to be the root file system
(not a stage) where 'init' will be executed.
As what you may notice 4MB is usually not enough to include
full featured GNU tools (init,sh,ls,cp,...etc) and fully loaded GNU C library,
as a solution to thus BusyBox is introduced as a single binary with multiple
functionality, it could act as many basic tools depending on the name used to
call it (here comes the name multi-call binary), so if 'ls' is a link pointing
to 'busybox', then it will list files! so just copy 'busybox' to your rescue file
system and make links point to it having tool names (type 'busybox' to list them).
You could also use compile binaries you include to be linked with
DietLibc (see www.fefe.de/dietlibc/) to save more space.
Tip
It's much easer to load the RAM disk through the boot loader (eg. SYSLINUX)
than joining it with the kernel and using 'rdev', simply put the kernel image
file along with the compressed RAM disk image as an initrd file in a
floppy, configure the boot loader
to load the initrd and set root to be the RAM disk '/dev/ram0' (or '/dev/rd/0' for
devfs kernels).
Back to the process of booting Linux, if no RAM disk were found
or it was asked not to look for it, then it will mount the root file system
passed by 'root' parameter or (in case no root parmeter passed) fixed by 'rdev',
it's prefared to be mounted for read only ('ro' parameter)
so that it could be checked (unless we are using a RAM disk)
to prevent a programing trying to modify the file being checked
because Linux is multi tasking OS.
4.3.6. 'init' program and run-levels.
The kernel runs '/sbin/init', and pass it the
rest arguments passed by the boot loader that the kernel could not
process, mainly runlevel number which is from 1 to 5 (0 and 6 are
reserved to shutdown the computer or restart it),
usually having the followin meanings (depending on 'inittb' of the distribution):
- 1 : single user mode
- 2 : multi user mode
- 3 : not used or multi user mode with network
- 4 : not used or X11 mode without network
- 5 : X11 mode
in Debian all runlevels from 2 to 5 have (initially) the same meaning
which is X11 mode with network and the default is 2, almost all other
distributions have 5 to be the default runlevel.
If you pass 'root=/dev/hda7 ro 2' then the kernel will
understand every thing except 2 which mean it pass 2 to 'init'.
4.3.7. 'inittab' file.
'init' will read a configurtion file found on '/etc' called
'inittab' (ie. /etc/inittab), type 'man inittab'
to read its manual page, every line (except comments) have the following
format: [ID]:[RUNLEVEL]:[ACTION]:[COMMAND],
where ID is a meaningless comment, RUNLEVEL is the number of runlevel
this line referes to, ACTION indicates when or how the command is executed
(and specify the meaning of the line) for example it could be 'sysinit'
which mean to execute it once (regardless of runlevel), 'wait'
to execute it and wait termination when entering/leaving runlevel,
'shutdown' to be executed before turning off the computer,
'ctrlaltdel' when pressing those keys, 'powerfail'
in case of power failur, 'powerokwait' when power is back,
'once' to be executed once in a runlevel or 'respown'
to keep restarting it after each termination.
A line to set the defualt runlevel to 5 looks like:
this line having 'id' as comment (short for 'init default')
just for the sake of readability, runlevel to be 5,
and 'initdefault' for action, no command is needed.
Usually, 'inittab' is not the right place to put boot-time commands,
it just specify the right script for that condition (or runlevel),
those scripts are called initializeing scripts or boot scripts,
notice the following 'inittab' line:
si::sysinit:/etc/rc.d/rc.sysinit
unicode_start /usr/lib/kbd/consolefonts/LatArCyrHeb16.pcf.gz
- /etc/rc.d/rc.S : Signle user mode
- /etc/rc.d/rc.M : Multi-user mode
- /etc/rc.d/rc.X : Graphical X11 mode
or the SysV as in Red Hat,Mandriva or Debian (unless 'file-rc' package is installed)
they would be a single script '/etc/rc.d/rc' that receive
an agrument that tell it the runlevel so it could act accordingly, 'inittab' entries for them looks like:
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
4.3.8. 'fstab' file.
One of the boot scripts will execute 'mount -a'
which reads the file systems table 'fstab'
(full filename /etc/fstab) which have the following format:
# this is /etc/fstab by <alsadi[at]gmail.com>
# this is a comment
| # device | mount-point | type | options | dump pass |
| /dev/hda7 | / | ext3 | defaults,errors=remount-ro | 0 1 |
| /dev/hda1 | /mnt/win_c | vfat | defaults,umask=0 | 0 0 |
| /dev/fd0 | /mnt/floppy | auto | defaults,noauto,user | 0 0 |
| /dev/cdrom | /mnt/cdrom | iso9660 | defaults,noauto,ro,user | 0 0 |
| proc | /proc | proc | defaults | 0 0 |
| /dev/hda8 | none | swap | sw | 0 0 |
bash$ man fstab
bash$ man mount
bash$ mount
bash$ cat /proc/mounts
bash$ su root
password :
bash# fdisk -l
bash# cat /proc/partitions
bash# mkdir /mnt/win_c
bash# mount /dev/hda1 /mntt/win_c -t auto
bash# exit
4.3.9. Services
As we have discussed 'rc' script will start or stop system services,
they are scripts that run special programs called Daemons (Disk And Execution Monitor
also mean ghost because of the claimed super natural power of UNIX)
in the background. Those services are put in a directory corresponding to the
runlevel, for example '/etc/rc.d/rc2.d/' (replace 2 with runlevel number).
'rc' will stop services having names starting with K (for KILL)
and start those starting with S (for START), for example all
service scripts in runlevel 0 or 6 (restart and shutdown)
will start with K, while in runlevel 5 most of them will start with S.
Of course, only those among them having execution permission.
The actual service script exists in '/etc/rc.d/init.d/'
and those in the runlevel directory are just links, for exmaple,
the service script to initiate random generator is '/etc/rc.d/init.d/random'
could be found to be linked as '/etc/rc.d/rc2.d/S51random',
S to denote START and 51 is used to control the order of running this script.
The service script accepts arguments like: 'start', 'stop',
'restart', 'status' or 'state'.
For exmaple , to stop a service pass it stop argument.
The following script segment could be the part of the 'rc' script
that start and stop services in some runlevel:
# part of simple rc
# take runlevel from argument 1
runlevel=$1
# distro links "/etc/rc$runlevel.d/" to "/etc/rc.d/rc$runlevel.d/"
# like /etc/rc.d/rc2.d/ & /etc/rc2.d/
for i in /etc/rc$runlevel.d/K*
do
[ -x $i ] && $i stop
done
for i in /etc/rc$runlevel.d/S*
do
[ -x $i ] && $i start
done
Tip
The statement '[ -x $i ]' means to check if the file '$i' is executable
(permission is granted to execute it), if this check succeeded
then run whatever after '&&'.
Tip
Your distribution 'rc' scripts are much more complicated,
they have functions (usually found on '/etc/init.d/functions') used to
make its output nice looking (eg. printing green [OK])
and to translate them to your local language.
Debian offer 'start-stop-daemon' tool that is used by 'rc' script,
it's much smarter that it provide many many options, for example,
before starting a daemon it make sure that it's not currentely running
while when stopping it, this tool prevent trials to start it in the
intermediate time. In Red Hat based distributions you could type
'service' followed by service name followed by the argument,
for example 'service gpm start'.
A service script trying to stop its service could use 'kill' to terminate
the daemon, undo some work or release some resources (eg. calling 'umount').
While to start it, it could run the daemon (eg. talkd), activate
some resources (eg. 'mount'), adding a module (runtime loadable
parts of the kernel) to the kernel using 'insmod' or 'modprobe',
modules sometimes called drivers but this is not accurate since
it could add support for an encryption algorithm.
Modules are found in a subdirectory of '/lib/modules'
having the name of kernel release version (the output of 'uname -r')
where you find .o files or .ko files (in 2.6), to activate a module
type 'modprobe foo', where foo is the module object file basename without .o (or .ko),
to list currentely loaded modules use lsmod, to remove one type
'rmmod foo', to know more about some module type 'modinfo -d foo'
and to know about its arguments type 'modinfo -p foo' (where foo is just like 'modprobe'),
while 'insmod' is the old way to insert modules before 'modprobe'.
Distributions use tools (like 'kudzu' from Red Hat and 'discover' which is used in Debian)
to detect hardware and insert the right module with 'modprobe'.
Many boot and services scripts in most distributions are configurable
through environment variables having their value specified in a file
found on a sub tree of /etc/sysconfig/ in Red Hat based distributions
or '/etc/defaults/ in Debian, those files are sourced (included)
by the script through 'source' shell built-in (also called dot operator).
Distributions come with a GUI application to manage services
(enable/disable a service in some runlevel)
usually found on menu->system settings->services
(eg. system-config-services in Fedora Core),
also one could use distribution-independent packages like
'ksysv' and 'gnome-system-tools'.
Red Hat based distributions (including Fedora and Mandriva) offer a console
tool called chkconfig to manage services
to enable 'gpm' in runlevels 2 and 3 type: 'chkconfig --level 23 gpm on'
to disable it in other runlevels (0,1,4,5,6) type 'chkconfig --level 01456 gpm off'.
It's not difficult to do it manually, to configure a service from scratch,
create a link to its script in directories corresponding to runlevels
you want it to be enabled (eg. 2-5) starting with S followed by sequence
two digit number from 00-99 followed by service name (eg. 'ln -s /etc/init.d/gpm /etc/rc2.d/S57gpm'),
and starting with K in other runlevels (eg. 0 and 6, with something like 'ln -s /etc/init.d/gpm /etc/rc0.d/S42gpm'),
then grant the right to execute it (eg. 'chmod +x /etc/init.d/gpm'),
To disable it in all runlevels just forbid executing it (eg. 'chmod -x /etc/init.d/gpm').
If a service is confgured right and you just want to enable it
in some runlevel rename the link there to start with S, to disable it
in that runlevel rename it to start with K, but notice that the number
should be changed to be 99 minus the old number
because what starts last should be stopped first.
For simplifictions and cross distribution compatabilty symbolic links
are used, '/etc/rc1.d' points to '/etc/rc.d/rc1.d'
(other runlevels similarily) and '/etc/init.d' points to
'/etc/rc.d/init.d' (what is a link in a distribution could
be the real directory in another).
Examples for services are 'apm' or 'acpi' for power management (and laptop battary),
'alsa' for sound drivers, 'gpm' for console mouse, 'atd' schedule a job at
specific time and many others.
4.3.10. Virtual terminals and Login.
Usually a number of virtual terminals (also VT or pseudo terminals) are opened
try moving between them with CTRL+ALT+Fn (where Fn is F1, F2,..etc.),
their number is specfied in inittab by lines like this:
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
The ttyN device (eg. tty1 ) represents the virtual terminal,
try the following commands:
Press CTRL+ALT+F1 and login
bash$ echo "Hello Ali"
Hello Ali
bash$ echo "Hello Ali" >> /dev/tty2
# Nothing printed , press ctrl+alt+F2 ,and woo
Each Virtual terminal is opened by a program called 'getty'
usually a minimized one called 'mingetty', it prints a welcome (colored) message
(found on '/etc/issue', but don't bother editting this file
because it will be generated and over written by some lines of 'rc.sysinit' since
this message may contian kernel version and other information that may vary
from boot to another) then it asks for user login name and password,
confirm it, then moves to his home directory and
executes his default shell (command interpreter) usually '/bin/bash'
which could be changed using 'chsh'.
Local user account informations are saved in 'passwd' database which looks like:
root:x:0:0::/root:/bin/bash
operator:x:11:0:operator:/root:/bin/bash
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
myname:x:1000:100:mygroup:/home/myname:/bin/bash
Tip
We were not discussing X Windows system, but in runlevels without X (eg. 2 in some distributions).
The UID of root user is always 0 and GID of root group is also 0.
Notice the existence of users you did not ask for, they are for
managing relations between programs so that we could control
a program privileges by controlling the privileges of the corresponging user,
they have '/bin/nologin' as their default shell (or other program that
prevent them from loggin into your system) and they have small UIDs (less than 100, I think).
To change your password type 'passwd', or other user (if you are root)
pass it his login name:
The Passwd database is world readable (so that one could know the UID of
some user, for example), because of that the password (although it's encrypted)
is saved in other file called shadow that it root only readable,
both are writble only by root could modify it (permissions 644 and 600 respectively),
The owner of those files should be the root user and it's advices
to be owned by root group too.
bash# cd /etc
bash# ls -l passwd shadow
-rw-r--r-- 1 root admin 30 Feb 2003 passwd
-rw-r--r-- 1 root admin 30 Feb 2003 shadow
bash# chmod 644 passwd
bash# chmod 600 shadow
bash# chown root:root passwd shadow
ls -l /etc/passwd
-rw-r--r-- 1 root root 30 Feb 2003 passwd
-rw------- 1 root root 30 Feb 2003 shadow
The shell sources (ie. 'includes' or roughely speeking 'exectes')
the following files:
/etc/profile
/etc/profile.d/*.sh (only exectable)
~/.bashrc (from user home directory, this is BASH specific)
export PATH=/bin:/usr/bin:/sbin:/usr/sbin:.
alias ls="ls --color -F -h"
alias df="df -h"
alias cp="cp -i"
- set PATH; a list of directories separated by semicolon
to look for binaries in case of specifing basename only,
notice that the current directory '.' (if included) has to
be that last place for security.
- BASH will replace each 'ls' you type with 'ls --color -F -h'
so that it will display colorized lists.
- BASH will ask 'df' to display free size in human readable format;
so that 1024 becomes 1K and larger use Mega or Giga of bytes
- 'cp' becomes interactive and confirm before overwriting files.
4.3.11. Starting X.
Once gettys are launched before you notice the login prompt,
X Windows system starts (in a suitable runlevel, eg. 5)
because a line in 'inittab' may look like (from Slackware)
x:5:respawn:/etc/rc.d/rc.X
if [ -x /usr/bin/gdm ]
/usr/bin/gdm
elseif [ -x /usr/bin/kdm ]
/usr/bin/kdm
elseif [ -x /usr/bin/xdm ]
/usr/bin/xdm
else
echo "error blah blah"
fi
- KDM part of KDE and the default one in Mandrake,
some versions of Mandrake use a modified one besides the original one.
- GDM part of GNOME and default in Red Hat Linux and Fedora Core
- XDM super ugly, difficult to configure, part of X11 implementation (eg. XFree86)
- WDM styled over WindowMaker
Mandriva puts a similar script in a service called 'dm' (short for display manager).
Debian simiply starts X through you favorite dispaly manager
as a regular service called xdm, gdm, kdm or wdm,
where at most one of them will be executed.
the diplay manager itself starts X by calling a script
(could be '/etc/X11/xinit/xserverrc' in your distribution)
that have a line like 'exec /usr/bin/X11/X -dpi 100'
Debian pass it -nolisten tcp to disable listening to
TCP network ports (eg. 6000) for security.
Your requested session (eg. GNOME or KDE) is started through '/etc/X11/Xsession'.
If you log into a runlevel without X, you could start X by
typing 'startx' which use 'xinit'
that includes '/etc/X11/xinit/xinitrc' and
try to start the session defined by '~/.xinitrc'
(if any) or the system defualt session defined by '/etc/X11/Xsession'
4.3.12. Graphics before or without X.
Long long ago, Red Hat Linux 7.x installer booting shows a penguin logo before
starting X! (even before starting 'init'). Mandrake Linux since 8.2 (if not before)
display a progress bar on a background image, and in many Linux Live CDs you may
see a transparent shadow of a penuin in the background of the console and there are
many many rows of text in the console screen!
This is done through Linux frame buffer device (http://linux-fbdev.sf.net),
to activate it simply add the right module using 'modprobe' followed by module name,
they are found in 'video' subdirectory, type 'ls /lib/module/$(uname -r)/kernel/video'
to list them, type 'modprobe vga16' or 'modprobe vga16fb' (in 2.6 kernel)
to start a 640x480x4 (16 color) frame buffer.
You may find a generic one called vesa built into your kernel (no need to any module)
that is activted through 'vga=0301' in the boot loader LILO or GRUB
(in case of unusual card that does not support VESA standards or there exists
a better specific module, you may need to add 'video=XXXX'),
The hexadecimal number 0311 (unlike the usual notation, 0 for hexdecimal not octal)
specifies the resolution mode to be 640x480x16, you may use the decimal notation
785 (without the leading 0) for the same purpose. The following table lists
main resolution number in hexadecimal.
Colours 640x400 640x480 800x600 1024x768 1152x864 1280x1024 1600x1200
--------+--------------------------------------------------------------
4 bits | ? ? 0302 ? ? ? ?
8 bits | 0300 0301 0303 0305 0161 0307 031C
15 bits | ? 0310 0313 0316 0162 0319 031D
16 bits | ? 0311 0314 0317 0163 031A 031E
24 bits | ? 0312 0315 0318 ? 031B 031F
32 bits | ? ? ? ? 0164 ?
The tool 'fbset' could be used to adjust frame buffer parameters
later like resolution and visible area (it does not work for generic VESA frame buffer driver).
To display general information about the current mode type 'fbset'
without arguments, for all supported resolutions type 'fbset -i'
and pass x to display timing information (needed by X configuration).
To change to some mode pass fbset its identifier (as found on /etc/fb.modes)
for example 'fbset 800x600@65', another method is to use
'g' followed by X and Y resolutions and virtual X and Y resolutions
then color depth in bits, for example 'fbset -g 800 600 800 600 16'.
To move the visible part pass it 'move' followed by one of
right, left, up or down followed by 'step' then number of pixels to move.
Pass it accel followed by true or false to enable or disable acceleration.
If you have more than one frame buffer device (video card) you may like
to specify wich the device with '-fb' option,
for example fbset -i -fb /dev/fd0',
see fbset(1), fb.modes(5), fbdev(4) manuals.
XFree86 3.x (and before) comes with different backend X servers
while recent implementations like XFree86 4.x (and X.org) have single
server with many drivers (as modules). The graphical installer of Red Hat Linux 7.x
uses XFree86 3.x but the installer run only one single server (in
installaton stage) that work
for many video cards simply by having the backend X server to be
frame buffer X server (XF86_FBDev) using the kernel frame buffer devices
(like generic VESA module)
but after instllation the server specific to the video card will be used.
Although the kernel documentation for frame buffer device
(Maintained by Geert Uytterhoeven) claims that: "The Frame buffer X server (XF86_FBDev)
is the most notable application program for the frame buffer device."
but this is no more true in 4.x, because the single XFree86 4.x server
support wider range of adapters with better acceleration and
the VESA driver for XFree86 4.x is much better than the kernel VESA
frame buffer (at least one could change resolution), noadays no major
distribution uses frame buffer device X server by default.
Frame buffer is still used, in many distributions, to provide nice looking
booting progress indicator with background image before starting X and to
provide very high resolution text console (over a background image).
Tip
The graphical boot process in Fedora Core does not use frame buffer device
but X.
Frame buffer device could be useful for embedded systems like GtkFB
and Qt/Embedded applications (eg. Qtopia application framework, see www.trolltech.com/products/qtopia).
There is a different but related project called Direct frame buffer
that seems to have accelerated frame buffers (I'm not sure).
Another method to have graphics without X is SVGA library,
It uses direct access to the video hardware providing basic
low-level operation on standard VGA and SVGA graphics modes.
It only works with some video hardware, its main applications
is console games like 'lxdoom'.
References
|
Best viewed with free web browsers
You may get more high quality software
from here for free
Generously Hosted by www.JadMadi.net
|
