Thursday, May 03, 2012

LiveCDCustomization


Why customize LiveCDs

You may wish to customise the Ubuntu Desktop LiveCd to:
  • make your own Linux / Ubuntu distribution
  • show off a particular application
  • localise to a certain language
  • remove software packages
  • add software packages
  • update software packages
  • change system defaults (theme, icons, desktop background, panels, browser homepage, etc)

How to Customise the Ubuntu Desktop CD

The easiest way to create a custom LiveCD is to use Ubuntu Customization Kit. What follows is the manual way of accomplishing the same.
You might also want to create a LiveCD from an existing installation; in this case,Remastersys is for you.
IconsPage/warning.png This guide is for the Desktop LiveCd; there is another page referring to customisation of the Alternative Install Cd & the Server Install Cd. Also, there is a guide on how to create a LiveCd without using an existing LiveCd.

System Requirements

  • At least 3-5 GB of free space
  • At least 512 MB RAM and 1 GB swap (recommended)
  • squashfs-tools
  • genisoimage, which provides mkisofs
  • An Ubuntu kernel with squashfs support (present in Ubuntu 6.06 and later)
  • QEMU/KVM, VirtualBox or VMware for testing (optional)
IconsPage/warning.png When customizing 9.10 Karmic Koala (or later) in an 9.04 Jaunty Jackalope (or earlier) environment, squashfs-tools must be updated to version 4.0. Conversely, the version of squashfs-tools in Ubuntu 9.10 is not compatible with earlier versions of Ubuntu.
IconsPage/warning.png The architecture (Amd64 or i386) to be stored on the LiveCD should be the same as the architecture used to perform the customization, or the LiveCD may not run. It is not trivial to customize an AMD64 LiveCD using an i386 operating system, for example.

Install pre-requisities

  • Make sure that you have installed the needed tools
sudo aptitude install squashfs-tools genisoimage

Obtain the base system

Note: the example shown here uses the ubuntu-9.04-desktop-i386.iso Desktop CD. Replace it with the name of your iso. For example, if you have a ubuntu-11.04-desktop-i386.iso image, the command:
mv ubuntu-9.04-desktop-i386.iso ~/livecdtmp
would be changed to:
mv ubuntu-11.04-desktop-i386.iso ~/livecdtmp
  • Move or copy it into an empty directory
mkdir ~/livecdtmp
mv ubuntu-9.04-desktop-i386.iso ~/livecdtmp
cd ~/livecdtmp

Extract the CD .iso contents

Mount the Desktop .iso
mkdir mnt
sudo mount -o loop ubuntu-9.04-desktop-i386.iso mnt
Extract .iso contents into dir 'extract-cd'
mkdir extract-cd
sudo rsync --exclude=/casper/filesystem.squashfs -a mnt/ extract-cd

Extract the Desktop system

Extract the SquashFS filesystem
sudo unsquashfs mnt/casper/filesystem.squashfs
sudo mv squashfs-root edit

Prepare and chroot

If you need the network connection within chroot
sudo cp /etc/resolv.conf edit/etc/
Depending on your configuration, you may also need to copy the hosts file
sudo cp /etc/hosts edit/etc/
sudo mount --bind /dev/ edit/dev
sudo chroot edit
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
(these mount important directories of your host system - if you later decide to delete the edit/ directory, then make sure to unmount before doing so, otherwise your host system will become unusable at least temporarily until reboot)
To avoid locale issues and in order to import GPG keys
export HOME=/root
export LC_ALL=C

Customizations

Apt-get

Prerequisites

In 9.10, before installing or upgrading packages you need to run
dbus-uuidgen > /var/lib/dbus/machine-id
and
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

Tasks

To view installed packages by size
dpkg-query -W --showformat='${Installed-Size}\t${Package}\n' | sort -nr | less
When you want to remove packages remember to use purge
aptitude purge package-name

Custom Background for GNOME

Generally background files are located in /usr/share/backgrounds. Copy your png file there, adjust owner and file access, and edit the files:
  1. /usr/share/gnome-background-properties/ubuntu-wallpapers.xml and
  2. /usr/share/gconf/defaults/16_ubuntu-wallpapers or other files in the same directory. by changing the string/usr/share/backgrounds/warty-final-ubuntu.png to point to your file
Eventually change or add attributes to other configuration files such as: /var/lib/gconf/debian.defaults/%gconf-tree.xml or/etc/gconf/gconf.xml.defaults/%gconf-tree.xml).
Historical: More for Dapper...

Change gconf values (fonts, panels etc.)

To make any change on the gconf attributes you must add the value that you want in the file /etc/gconf/gconf.xml.defaults/%gconf-tree.xml. Adding a value in that file will change the default values of Gnome or other applications, so you can change fonts, backgrounds, themes, cursors etc.
Instead of editing the file with gedit or another text editor, you can use the gconftool-2, under the chroot environment, running the following line:
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --type string --set yourkey "yourvalue"
where stringyourkey and yourvalue must be the type, key and value that you want to change...

Making several gconf changes

Editing gconf by setting each value separately takes too much time. There is a better way:
Make a test user and adjust the settings as you wish. Run
gconftool-2 --dump /the/settings/branch/you/need > ~/live/your-new-settings.xml
sudo chown root:root ~/live/your-new-settings.xml
sudo mv ~/live/your-new-settings.xml ~/live/edit/your-new-settings.xml
and then, in the chroot environment, run
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --load /your-new-settings.xml
rm /your-new-settings.xml
This way you can import the whole branch, e.g. /apps/panel - all settings for Gnome's panels. Note that this way you import not only the keys, but also their descriptions, so all GConf descriptions will be changed to the language which was set for the test user, and there will be no way to safely change them back. Some programs (for example, keyboard shortcuts in Preferences menu) use descriptions from GConf.

Change default language of gfxboot

This customization must be done outside the chroot.
sudo aptitude install dpkg-dev uck
apt-get source gfxboot-theme-ubuntu gfxboot
cd gfxboot-theme-ubuntu*/
make DEFAULT_LANG=fi
sudo cp -af boot/* ../extract-cd/isolinux/
Change "fi" to your preferred locale. Note that this does not change which languages are available in the F2 menu. For more info about gfxboot customization, see Ubuntu Customization Kit.
  • A other way to change the default language of gfxboot without rebuild the packages is to create a file name lang in the isolinux directory containing your locale's name.

Customization limits

After customization make sure that there are no users with an UID > 999. Otherwise your image won't boot because no initial user is available (see /usr/share/initramfs-tools/scripts/casper-bottom/10adduser). While in chroot:
awk -F: '$3 > 999' /etc/passwd
If you get any hits, try changing the uid:
usermod -u 500 $hit

Miscellaneous Defaults

You may wish to edit the files in /etc/default to change system behavior at startup. You might also edit /etc/profile, /etc/bash.bashrc, and /etc/bash_completion to change login settings for all users on the system. You cannot directly edit defaults for the live cd user (e.g., casper,ubuntu, or user) since that account is created at boot time. You can directly edit root's default files (/root in the chroot environment).
If you wish to change the default timezone used by the live cd, run:
dpkg-reconfigure tzdata
If you have added a locale and wish to make it the default, update /etc/default/locale. You may have to compile the locale:
locale-gen new_locale
update-locale LANG=new_locale LANGUAGE=new_locale LC_ALL=new_locale
These changes must be made as root in the chroot environment.

Advanced Customizations

Live CD Kernel

If you want to customize further the boot process, you can change the livecd kernel, by copying the vmlinuz and initrd you want in place of the ones you find in extract-cd/casper.
i.e.
sudo cp edit/boot/vmlinuz-2.6.15-26-k7 extract-cd/casper/vmlinuz
sudo cp edit/boot/initrd.img-2.6.15-26-k7 extract-cd/casper/initrd.gz
Note that the initial ramdisk filename for newer releases (since 9.10) is casper/initrd.lz (not .gz).

Removing the (Casper) Autologin

The autologin feature of the Jaunty/9.04 live CD is a bit of an on-the-fly boot-hack. After extracting the initrd.gz, you need to edit the casper-bottom/25configure_init script and then recreate the initrd.gz file, replacing the original in extract-cd/casper. The process to do so goes like this:
# cd extract-cd/casper
# mkdir tempdir
# cd tempdir
# gunzip -dc ../initrd.gz | cpio -imvd --no-absolute-filenames
# cp scripts/casper-bottom/25configure_init scripts/casper-bottom/25configure_init.orig
# vi scripts/casper-bottom/25configure_init
Now look for line 25 which has the conditional statement to test $USERNAME.
Line 25 performs a conditional evaluation and if it evaluates to true, it will execute the code within the if block. The if block contains code to modify files used in the boot process to create the live cd autologin.
To disable the autologin feature, Remove $USERNAME, but just leave the quotes. The -n modifier tests the $USERNAME string to see if it's length is non-zero. By removing the variable, and leaving two double quotes, this statement evaluates to false because the two double quotes effectively make a zero-byte string. Be sure to leave no whitespace between the quotes because whitespace will make the evaluation true and execution wil fall into the if block.
21:log_begin_msg "$DESCRIPTION"
22:
23:# Arrange for shells on virtual consoles, rather than login prompts
24:
25:if [ -n "$USERNAME" ]; then
After making the change, line 25 will look like this:
25:if [ -n "" ]; then
Save the file and quit the editor. Then, from extract-cd/casper/tempdir run the following command to re-create the initrd.gz file. There are other methods for re-creating the initrd.gz file on this page which may work also.:
# cp ../initrd.gz ../initrd.gz.orig
# find . | cpio -o -H newc | gzip -9 > ../initrd.gz
This will create a new initrd.gz file with no auto login. You can then continue to remaster the CD as described on this page. Be sure to create a user and password to login with before you remaster the cd. If you do not, you will not be able to login after booting!
Also, I have read a few articles mentioning that Karmic (9.10) uses initrd.lz instead of initrd.gz. I do not know if this is true, but should mention it in case you are not getting the expected results. To unpack the initrd.lz file, you need to do this:
# cd extract-cd/casper
# mkdir lztempdir
# cd lztempdir
# lzma -dc -S .lz ../initrd.lz | cpio -imvd --no-absolute-filenames
And to re-create the initrd.lz file:
# cp ../initrd.lz ../inird.lz.orig
# find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../initrd.lz

Boot init

You have to edit the files in edit/usr/share/initramfs-tools/scripts/casper-bottom/* For example you can change the hostname or the livecd user.
i.e.
sudo nano edit/usr/share/initramfs-tools/scripts/casper
and edit the username or hostname
sudo nano edit/usr/share/initramfs-tools/scripts/casper-bottom/10adduser
to edit even the livecd user's password.
If you're customizing 10.04, you need to edit variables in /etc/casper.conf for the user and host names instead of modifying the scripts
P.S. in order to obtain an encrypted password, you have to use the mkpasswd program that's shipped with whois package!

Rebuilding initrd

After you've modified the kernel, init scripts or added new kernel modules, you need to rebuild the initrd.gz file and substitute it into the casper directory.
sudo chroot edit
mkinitramfs -o /initrd.gz 2.6.15-26-k7
(replace the kernel version with the one that the CD will boot with - this can be found in edit/lib/modules) *** do I need to mount proc, sys, devpts after chroot here ? Gordon
Exit from the chroot jail and move this file to extract-cd/casper:
exit
mv edit/initrd.gz extract-cd/casper/

Cleanup

Be sure to remove any temporary files which are no longer needed, as space on a CD is limited. A classic example is downloaded package files, which can be cleaned out using:
aptitude clean
Or delete temporary files
rm -rf /tmp/* ~/.bash_history
Or delete hosts file
rm /etc/hosts
Or nameserver settings
rm /etc/resolv.conf
If you installed software, be sure to run
rm /var/lib/dbus/machine-id
and
rm /sbin/initctl
dpkg-divert --rename --remove /sbin/initctl
from within the chroot environment.
now umount (unmount) special filesystems and exit chroot
umount /proc || umount -lf /proc
umount /sys
umount /dev/pts
exit
sudo umount edit/dev
  • Note: if "umount /proc" command fails, "umount -lf /proc" will be used to retry automatically.

Producing the CD image

Assembling the file system

Regenerate manifest
chmod +w extract-cd/casper/filesystem.manifest
sudo chroot edit dpkg-query -W --showformat='${Package} ${Version}\n' > extract-cd/casper/filesystem.manifest
sudo cp extract-cd/casper/filesystem.manifest extract-cd/casper/filesystem.manifest-desktop
sudo sed -i '/ubiquity/d' extract-cd/casper/filesystem.manifest-desktop
sudo sed -i '/casper/d' extract-cd/casper/filesystem.manifest-desktop
Compress filesystem
sudo rm extract-cd/casper/filesystem.squashfs
sudo mksquashfs edit extract-cd/casper/filesystem.squashfs -nolzma
  • Note: The -nolzma option is only available from Hardy , and was removed in Karmic. Also, the squashfs has to be generated using a version of mksquashfs that is compatible with the kernel used on the CD you are customizing. For example, you cannot generate a jaunty squashfs on karmic, as the jaunty kernel is not able to mount a squashfs prepared using mksquashfs from karmic.
For slightly higher compression at the cost of compression time, you can increase the block size:
sudo mksquashfs edit extract-cd/casper/filesystem.squashfs -b 1048576
Update the filesystem.size file, which is needed by the installer:
printf $(sudo du -sx --block-size=1 edit | cut -f1) > extract-cd/casper/filesystem.size
Set an image name in extract-cd/README.diskdefines
sudo vim extract-cd/README.diskdefines
(you can use "sudo nano extract-cd/README.diskdefines" if you have difficulties understanding vim)
Remove old md5sum.txt and calculate new md5 sums
cd extract-cd
sudo rm md5sum.txt
find -type f -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt
Create the ISO image
sudo mkisofs -D -r -V "$IMAGE_NAME" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ../ubuntu-9.04.1-desktop-i386-custom.iso .

Testing the CD

Test using qemu emulator
qemu -cdrom ubuntu-9.04.1-desktop-i386-custom.iso -boot d -m 512
Or if you have hardware acceleration for kvm
kvm -cdrom ubuntu-9.04.1-desktop-i386-custom.iso -boot d -m 512
You can also test with virtualbox-ose, which is free software and available in the Ubuntu universe repository.

Troubleshooting

Some experience problems virtualizing the iso after changing the livecd linux kernel. If you do, go click F6 when the boot screen is showing. Move the cursor between splash quiet and -- and write: all_generic_ide

Burning the image to CD

Simple! Just do
cdrecord dev=/dev/cdrom ubuntu-9.04-desktop-i386-custom.iso

Additional uses for the image

Comments

If you have any comments or questions, please feel free to add them here.
If you are answering a question, please rewrite the question into a tip that answers the question. (to help keep things to the point.)
New questions at the bottom (I guess.)

I have created an small Customization Example (named Firebird Live CD) by adding an firebird2.1-superand flamerobin packages (this apply to ubuntu Hardy Heron also it was tested with xubuntu 8.04) http://flamerobin.blogspot.com/2008/08/creating-flamerobinfirebird-livecd-with.html

Warning: qemu did not work for me as given in the guide above. Even the normal 8.04 live cd would not boot correctly. Every time, I would get thrown into the ash shell (busybox, initramfs) and while there, a "cat /casper.log" would reveal that it was "Unable to find a medium containing a live filesystem". Just use virtualbox-ose. It actually works with virtualbox. However, after using apt-get to install virtualbox-ose, I had to run "sudo depmod" again in order for the vboxdrv module to be found by modprobe. Hope that helps!

Warning: Squashfs is currently in development and is thus not finalized as a format. This means you cannot assume a filesystem.squashfs created using the Ubuntu 9.04 version of makesquashfs will be compatible with the squashfs drive an older live CD. I was customizing an Ubuntu 7.10 LiveCD and when testing it always booted it an (initramfs) prompt--the squashfs was not getting mounted as /. I had to build from within an Ubuntu 7.10 chroot to get it to work.
--Bob/Paul

I have created an small Customization Example (named Firebird Live CD) by adding an firebird-super-server and flamerobin packages (this apply to ubuntu dapper drake) http://flamerobin.blogspot.com/2006/05/creating-flamerobinfirebird-live-cd.html I created an updated guide with Ubuntu Festy Fawn also with an iso download for the Firebird/Flamerobin live cd http://flamerobin.blogspot.com/2007/09/creating-flamerobinfirebird-livecd-with.html

I have created tool for automatic remastering of live CD images. See http://uck.sourceforge.net/ .
Features:
  • GUI for simple creation of localized CDs (including changing gfxboot and installing language packs)
  • Script for customization of ISO, SquashFS and initrd on live CD.

http://www.atworkonline.it/~bibe/ubuntu/custom-livecd.htm seems to have some nice info. no license that I can see so we would need to ask permission from the author to us its material.

If you want to make the CD boot faster, you might try sorting the files so that they are in the CD in the order that they are accessed:http://lichota.net/%7Ekrzysiek/projects/kubuntu/dapper-livecd-optimization/

Great How To. I am having one issue however. I would like to use custom xorg.conf and sources.list files. Any tips on doing this? Thanks.
  • Simply, copy the files to edit/etc/ in the same way (and at the same time) that you copy in the resolv.conf and hosts files.
  • I have found that copying xorg.conf doesn't work, as the boot-time scripts overwrite it. Besides, you can't guarantee that a particular xorg.conf will run on all hosts. I'm currently trying to get the binary NVIDIA drivers to work out of the box if an NVIDIA card is present. If I figure out how to fix the xorg.conf, I'll post it here. --JeremyVisser

I've managed to get Synaptic running from within the chroot environment, but it does hang when I try to apply packages. What you do is run "Xnest -ac :1" to get an Xnest server to run on display :1 without access control so anyone can connect to it. Then, in the chroot environment, run "export DISPLAY=:1" to get programs to use the display. Then, type "metacity &" to be able to move windows. Finally, run "synaptic".
It works fine until you try to apply packages, where it hangs for me. --JeremyVisser

Shouldn't the mkinitramfs command use the casper scripts, like "mkinitramfs -o initrd.gz 2.6.15-23-386 -d /usr/share/initramfs-tools"?

There are tricks on how you can get to feel the GNOME system in your chroot environment.
1. Copy your xorg.conf in the chrooted "etc/X11/" directory.
cp /etc/X11/xorg.conf edit/etc/X11/
2. Create generic devices on your chroot system using MAKEDEV
cd /dev/
MAKEDEV generic
3. Start X or restart gdm
/etc/init.d/gdm start
Supposed you want to make modifications on the Desktop, that will be used by all the new users, just change your $HOME to /etc/skel/ and start gdm or X.
export HOME=/etc/skel/
If you want to load all the other stuff GNOME needs (i.e, dbus, avahi, network-manager), just boot as (single-user mode), and start dbus in your chrooted environment.
/etc/init.d/dbus start
An example of the whole procedure. (under single-user mode)
sudo /etc/init.d/networking restart
sudo cp /etc/resolv.conf edit/etc/
sudo cp /etc/X11/xorg.conf edit/etc/X11/
sudo chroot edit
mount -o none /proc
mount -o none /sys
export HOME=/etc/skel/
cd /dev/
MAKEDEV generic
/etc/init.d/dbus start
/etc/init.d/gdm start
--- joelbryan

Hello,
I am about to build a new Livecd and have a question: When I change the username, hostname and the user's password the user login automatically during booting the livesystem. But this is not desired. Is it correct, that I have to enter a password under a Desktop LiveCD when I delet the encrypted password in /usr/share/initramfs-tools/scripts/casper-bottom/10adduser ?
Thanks
Changing username and password will not change login behaviour, because this is done in /usr/share/initramfs-tools/scripts/casper-bottom/15autologin

Having trouble starting a MySQL server from within the chroot jail. Any suggestions?
- Dave
Hey,
I am trying to make a customized live cd of Kubuntu 6.06 that will be completly preconfigured, so that when the user clicks on the install icon on KDE the installer should do everything by itself, meaning that the installer should not ask any questions to the user.
To do this I am trying to write a preseed file to tell the installer the information that it needs.
The problem is that even with this preseed file I could only tell the installer what is the username that it should use, the rest of the information is simply ignored by the installer.
I must be doing something wrong and would appreciate any and all help given me.
Thanks, Komyg
PS: Should I post my preseed file here?

If the livecd is not going to be used for the purposes of installing what files can be removed? Can the "pool" files containing the .debs be removed too?
- Mike

If I want to put in my LiveCD applications that aren't in the sources.list (like ooffice 2.2 or perl audio converter), what cain I do?
- Isoldanne
When you're in the chroot you can install applications just like you would on a live system. If you install from source you can feel free to delete the source tarbal and make folders after you do 'make install'.
- Bob/Paul

To get desired /etc/X11/xorg.conf one can modify the /usr/bin/dexconfThis script generates xorg.conf automatically in liveCD sessionaccording to the booted machine.
For example:
# diff ~/bin/dexconf /usr/bin/dexconf
268,269c268
<       Option          "XkbLayout"     "us,il"
<       Option          "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"
---
>       Option          "XkbLayout"     "$XKB_LAYOUT"
-- yotam

I cant do chroot. When i run it a get this error
chroot: cannot run command `/bin/bash': No such file or directory
Please help me out
  • I had the same problem because the filesystem that I was working on was FAT32 instead of EXT2 or EXT3. Because of that, /bin/bash was not an executable I guess. If that is your case also, then please try again on a partition that is EXT2 or EXT3 (the Linux type of partition). Good luck, --vvim

Hi, I've created a simple script to ease remastering the Kubuntu Live CD. It uses aufs to avoid copying all the files back and forth.
Maybe it will be usefull to others too. The script must be run as root.
CD="${1:-kubuntu-9.04-desktop-i386.iso}" ; shift
# exit after any error:
set -e

which mkisofs mksquashfs tempfile sed

WDIR=`mktemp -d $PWD/kubuntu-remastered.XXXXXXXXXX`
ISO="$WDIR/${CD##*/}"
ISO="${ISO%.iso}-remastered-KDM.iso"
EXIT=""
function addExit {
    EXIT="$@ ; $EXIT"
    trap "$EXIT" EXIT HUP TERM INT QUIT
}
function mnt {
    local margs="$1" ; shift
    local mp="$WDIR/$1"
    for D in "$@" ; do
        mkdir -v -p "$WDIR/$D"
    done
    mount -v $margs "$mp"
    addExit "umount -v $mp"
}

# mount the CD image
mnt "-t auto $CD -o loop,ro" cd

# mount compressed filesystem
mnt "-t squashfs $WDIR/cd/casper/filesystem.squashfs -o ro,loop" sq

# create joined writable filesystem for the new CD
mnt "-t aufs -o br:$WDIR/cd-w=rw:$WDIR/cd=ro none" cd-u cd-w

# create joined writable filesystem for the new compressed squashfs filesystem
mnt "-t aufs -o br:$WDIR/sq-w=rw:$WDIR/sq=ro none" sq-u sq-w

echo ">>> Updating CD content"

(
    cd sq-u

    # DO YOUR CUSTOMIZATION STUFF HERE, CHROOT, MODIFY FILES, ETC.
    # ...
    # ...

)

echo ">>> Compressing filesystem"
mksquashfs $WDIR/sq-u/ $WDIR/cd-u/casper/filesystem.squashfs -noappend

echo ">>> Recomputing MD5 sums"
( cd $WDIR/cd-u && find . -type f -not -name md5sum.txt -not -path '*/isolinux/*' -print0 | xargs -0 -- md5sum > md5sum.txt )

echo ">>> Creating ISO image $ISO"
mkisofs \
    -V "Custom KUbuntu Live CD" \
    -r -cache-inodes -J -l \
    -b isolinux/isolinux.bin \
    -c isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -o "$ISO" \
    $WDIR/cd-u

# The trap ... callbacks will unmount everything.
--- Petr Pudlak

I need to know how to configure the live cd so that it does not use SWAP!
Please help me!
-- iceman

Hi, I've been experiencing problems with aptitude and I'm pretty sure its because I'm doing all this stuff on NTFS partition (according to this threadhttp://ubuntuforums.org/showthread.php?t=521905). But I have no other choice,coz' I've got less then 1,7GB on my ext3 partition. Any suggestion ? THX
Error messages I've been getting, when trying to install or update aptitude:
"E: Couldn't make mmap of 25165824 bytes - mmap (19 No such device) W: Unable to munmap E: The package lists or status file could not be parsed or opened."
-heethen (heethen at centrum dot cz)

I would suggest creating an ext3 filesystem within your NTFS partition. To create the file, type
dd if=/dev/zero of=/mnt/hda1/workspace.img bs=1024 count=$((1024*1024*15))
Where I assumed your NTFS partition was on hda1, and you wanted to call the new filesystem workspace.img (it's really just a file within NTFS), and that you wanted 15Gb of room to work. (You don't need that much, but with 15Gb you should have plenty of room.) Then you format the new filesystem with the command
sudo /sbin/mkfs.ext3 /mnt/hda1/workspace.img
then create a mountpoint
sudo mkdir /mnt/workspace
then mount the new filesystem
sudo mount -o loop /mnt/hda1/workspace.img /mnt/workspace
You can then use as much space on the NTFS partition as you want, and have all the benefits of ext3 (like getting the *** thing to work). --Tom

Editing gconf by setting each value separately takes too much time. There is a better way:
Make a test user and adjust the settings as you wish. Run
gconftool-2 --dump /the/settings/branch/you/need > ~/live/your-new-settings.xml
sudo chown root:root ~/live/your-new-settings.xml
sudo mv ~/live/your-new-settings.xml ~/live/edit/your-new-settings.xml
and then, in the chroot environment, run
gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --load /your-new-settings.xml
rm /your-new-settings.xml
This way you can import the whole branch, e.g. /apps/panel - all settings for Gnome's panels.
---Jacob Popov ubuntu-9.04-desktop-i386.iso

Is there no way to copy the user's gconf-values to the default gconf-values in the chrooted environment? This would be a lot easier than writing commands.

It took me a long time to find the details for configuring a static IP on the live CD without doing it in the root file system. This enables you to create a few boot options with different static details and a DHCP on but all from the same rootfs.
There is a casper parameter which is in the form:
ip=IFACE,ADDRESS,NETMASK,GATEWAY[:IFACE,ADDRESS,NETMASK,GATEWAY]*
--silid


I think I have discovered how to do this:
1) Edit accordingly /usr/share/initramfs-tools/scripts/casper-bottom/23networking
2) Run update-initramfs -u -k $version
- Robert
In order to get the livecd to boot from a static address found in the /etc/network/interfaces file.
I edit the /etc/network/interfaces file and add a static address for the interface eth0.
auto eth0
iface eth0 inet static
address 10.xxx.xxx.xxx
netmask 255.255.255.0
gateway 10.xxx.xxx.1
edit somepath/isolinux/text.cfg add ip=frommedia after splash
label live
  menu label ^Try Ubuntu without any change to your computer
  kernel /casper/vmlinuz
  append  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz quiet splash ip=frommedia --
This was a little hard to find. Thanks Robert Nicholas A. Schembi Pittsburgh PA USA

I've tried installing adobe flash player but while it installs fine on chroot, and then shows as installed when booting from CD. Firefox thinks it is not installed and I need to install it manually. Anybody come upon a similar problem

I tried to customize Ubuntu Hardy by installing the RT kernel and did the changes as written in the howto... it goes well, but booting in vbox is really slow. What could be the cause? I tried is once again and also in another vbox installation, but still that problem. Would be nice if someone can point me to an solution! thanks in advance see also thread: http://ubuntuforums.org/showthread.php?p=7334890#post7334890 edit: I think it has something to do with the fact that it is an RT kernel (from Hardy) ... Someone with experience with adding custom RT kernels?

I wrote a script to automate the extraction / chroot / regeneration processes: http://david.decotigny.fr/wiki/wakka.php?wiki=RemasterUbuntu . It has been tested on a jaunty x86_64 host for a jaunty i386 CD image.

To put the default user in the "video" group, 
printf "\nADD_EXTRA_GROUPS=1\nEXTRA_GROUPS="video"\n" >> /etc/adduser.conf 

In order to edit a Karmic LiveCD in any release prior to Karmic, it looks like you will need to upgrade squashfs-tools to support SquashFS v4.0:
root@maxwell:/home/Z_Custom# unsquashfs mnt/casper/filesystem.squashfs
Filesystem on mnt/casper/filesystem.squashfs is (4:0), which is a later filesystem version than I support!
I installed squashfs-tools_4.0-1 from the Karmic release into my Intrepid installation and it seems to be fine now. Maybe we should update these directions to reflect that?
Sincerely,
--John D. Zollo

Hi.. How can I add an a Post Installation script? I mean, I want to execute a script just after the installation process. THis script is simple and set a few things to customize the installation.
Any ideas?
Best Regards
-- Alejandro

Hallo, I'm trying to remaster ubuntu 9.10 livecd. I'm following instruction from this page. When I'm trying to boot from customized system it's seems I can't login to the system, so I can't got the system running.
I am following instruction from limitation part about user id. And make sure there are none of users has uid more then 999. But, after making the squashfs file system I got a message that told me about a user with uid 1000. Actually my host system has a user with uid 1000. I'm using this user to remaster ubuntu livecd.
Does my uid (1000) that I used for remastering the livecd make the new live cd can't login? If it does, how to fix it? Am I must use another user with uid less then 999 to remaster the livecd?
Best Regards
asw_te

Hello, what is the best way to remaster the Karmic release LiveCD (in VirtualBox) to include all the latest updates (more than 150) including new kernel and udev? The kernel changed from 2.6.31-14 to 2.6.31-16 and also udev.
apt-get autoremove removes the old headers, but I have to purge the old kernel manually (apt-get purge linux-image-2.6.31-14-generic).
The first problem is, update-initramfs -u -k all still runs for the old kernel, too. Only aptitude reinstall udev seems to stop this (depmod -a && dpkg --configure -a && dpkg-reconfigure udev does not help).
The second problem is, how do I prepare initrd and isolinux to run and install from a subdirectory (to create a multi-boot DVD)? The base of the DVD is Ubuntu, so / contains ubuntu-9.10-desktop-i386.iso, /kubuntu contains kubuntu-9.10-desktop-i386.iso and so on. Most things run fine when I introduce the prefix to scripts/casper and /isolinux/text.cfg:
LIVE_MEDIA_PATH=casper
$path/.disk/casper-uuid
append  file=/cdrom/preseed/kubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash --
becomes
LIVE_MEDIA_PATH=kubuntu/casper
$path/kubuntu/.disk/casper-uuid
append  file=/cdrom/kubuntu/preseed/kubuntu.seed boot=casper initrd=/kubuntu/casper/initrd.lz quiet splash --
But the prefixed distributions show only an Install Ubuntu 9.10 link on the desktop, not Kubuntu (Xubuntu, LUbuntu, ...).
Thanks, René Leonhardt

Hi!
I was hoping to be able to remaster the Ubuntu Live disc so that I can stick it into almost any computer, have it boot up but NOT go into the GUI, just auto login and run a media player with arguements (like a stream address). Was hoping to be able to make my own easy internet radio appliance. Give old pentium computers with soundcards to businesses and they can play my station on their PA for free!
-- Matt

I updated the Karmic Live CD with the latest updates inside chroot using aptitude with update, dist-upgrade, purge linux-image-2.6.31-14-generic, install zsh zsh-doc, install ubuntu-restricted-extras, and enabled DVD playback.
The resulting iso file turned out larger than a CD, and I put it on a USB Disk. The system boots fine, has the latest updates and can play restricted formats 'out of the box'. When I travel, I can just carry a USB Disk instead of a computer!
All releases including Ubuntu 9.10 Karmic Koala now have newer kernels available via updates. The kernel in the live CD *MUST* match the ones inside squashfs. If it does not, you get strange problems (like the wireless interface not being detected or CDs not being recognized)
i.e. for Karmic
sudo cp edit/boot/vmlinuz-2.6.31-16-generic extract-cd/casper/vmlinuz
sudo cp edit/boot/initrd.img-2.6.31-16-generic extract-cd/casper/initrd.gz
Since Karmic uses initrd.lz, I had to uncompress the .gz file and put it back in .lz format.
cd extract-cd/casper
sudo mv initrd.lz inird.lz.orig
gzip -dc initrd.gz | sudo lzma -7 > initrd.lz
cd ~/live
To conserve space, you can remove the original initrd files before changing the directory back
sudo rm -f inird.lz.orig initrd.gz
Best, Pradeep Sekar

I have a few questions, I am remastering a copy of 9.04 for a community school program i ran into a few problems
#1 how do you remove the option to update to 9.10 in the update manager #2 how do you get the CD to be recongnized in ubiquity installer as the named distro instead of ubuntu 9.04 (when i go to reinstall the softare still says it is a ubuntu 9.04 cd) #3how do you install a new kernel into the live cd and install part, i was able to upgrade it to 28.18 but when i try putting 31 on it ...it just wont boot.
#4 i have a repos server, i edit the sources.list but ubuntu repos are still the primary, how do i change that over?
#5 finally, i took out gnome games, and i want to add a list of eduacational games, but i want that as a optional install. (some computers won have game son there) is there a way to add the /.Games folder without actaully having data in it? i tried doing this in the chroot adn root menu and it still does not show up on install...
Thank you
ashlessburn

Can anyone tell me how I can take out the option of installing the Live CD at boot. I just want them to be able to use it, not install.
Thanks
--Steve

You can edit the boot options in extract-cd/isolinux/text.cfg Delete all lines and sub-lines of a label you don't like: For example you can delete:
label live-install
   menu label ^Install Ubuntu
   kernel /casper/vmlinuz
   append  file=/cdro...
-- jancelis

To remove the autologin, you make us work in the extract-cd directory. Does this mean that this process has to be the last one ? Do we have to do it after all the modifications on the edit directory ? Do we have to first create the new user in the chroot ? thx --lsga

I'm having trouble properly adding a repository. How do you add one to a live cd? --Muscovy

Hi, I'm working on a unnattended install CD using Ubuntu Lucid 10.04, and I found that if you erase /sbin/initctl the automatic install doesn't run. Also the instruction to generate the initctl using dpkg-divert is not working. So be careful...
Alejandro

I customize the live cd and install apache2 , webmin ,,, but how to make it start after the automatic-login ?
Gordon

I use a version of Ubuntu that does not automatically Start the graphical system (startx command) How can I add that to be run at boot?
RJ

I am currently working on a minor update given 10.10 is out. Unfortunately, I got held up and now time has run out. Mainly I wanted to make the scripts more copy/paste friendly. So I added a few env-variables and use those throughout the script. I've done the replacements already, but I didn't get aroud to do some testing.
In the meantime, I'll dump my current version into the above link to save my work.
exhuma

aptitude can't purge packages.
The program 'aptitude' can be found in the following packages:
  • aptitude
  • aptitude-gtk (You will have to enable component called 'universe')
Try: apt-get install

Unable to find a medium containing a live file system (SOLUTION)
When creating a live-usb with Unetbootin from Windows (Vista/7) you sometimes get this error. A friend of mine suggested another solution than all of the above. Create the USB stick with Unetbootin from a Linux (Ubuntu) box and NOT a windows system. Apparently something is different between the two because now my system just boots flawlessly!
SantanaNL

Regarding the "Unable to find a medium containing a live file system"--
I had this same problem when trying to install Ubuntu 10.04, 10.10, and 10.10 netbook edition on a netbook using a USB stick. I tried creating all three using 10.10's boot disk creator, 11.04's boot disk creator, Unetbootin on 11.04, and Unetbootin on Windows 7. In all cases, I was able to make it to the usb boot menu and would select 'Install'. The Ubuntu logo would show that it was processing for a while and then fail with the above message in a terminal.
In the end, it wasn't a problem with the iso or the created USB stick. The USB drive just wasn't mounted (or would become unmounted after I tell it to go through the 'Install' procedure. Since I couldn't figure out how to boot the usb from the provided terminal, I just tried removing and reinserting the USB drive once I saw the Ubuntu logo and the progress blips.
I was able to get past this problem twice, so far, with this solution.
bananax182

For all of you semi new maybe not quite as knowledgeable Ubuntu users, as myself, the live CD environment does not utilize all of the typical repositories that it would as if you installed it. You might need to add the particular repository of interest to install a program for your live CD.
For instance, I wanted to create a live CD with dcfldd on it. I had to edit etc/apt/sources.list within the chrooted environment to add the universe repository. I uncommented the following to lines in etc/apt/sources.list to install dcfldd:
deb http://archive.ubuntu.com/ubuntu natty universe
deb-src http://archive.ubuntu.com/ubuntu natty universe
Then just updated apt and installed as normal:
apt-get update
apt-get install dcfldd
Sorry if everyone already knew this. I just figured it may be helpful to users like myself.
mrgrant

Hi Smile :) I'm sure people appreciate comments such as your MrGrant. Otherwise people might feel they are the only ones suffering from something or maybe feel they are to blame. 
On a normal LiveCd there is an "installer" icon. DOes anyone know how i can get that icon onto a normal Ubuntu desktop? I have done a full install to a large usb-stick and installed things like "GPartEd" but i definitely miss havign that installer icon & functionality. Regards from Tom Smile :)

I am looking to update or see an update to this guide that addresses a custom launcher on unity. So the idea is once the desktop and unity have resolved to the scree, I can click on a custom launcher with out looking in dash to find it. This message should be replaced with this information, in case someone else beats me to the punch.
Chad

I am a total beginner. How do I take my current computer configuration and turn it into a install CD? Thanks!
Nick Smile :) (Sorry if my question sounds dumb)

Hi Nick :)
This link might help
but i would avoid it. It's not dumb, just tricky. 
Instead you can back-up all your settings, config files/folders and data by backing up the /home folder. You can move your /home to a new partition to separate your data (including configs and stuff) from the Operating System. That allows you to re-install the OS without messing anything up
It's even possible to have 2 different Operating Systems sharing the same /home although it's not recommended.
Better places to ask questions are 
and Launchpad
Regards from
Tom Smile :)

I think this entry could be improved by adding some explanation of what we are trying to accomplish with these commands. Pretty much any time it says "you need to use" or "remember to" it would be great to know why. Just my two cents.
Mike

Saturday, March 31, 2012

How to Get Your Change Into the Linux Kernel

http://git.kernel.org/?p=virt/kvm/kvm.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD



 How to Get Your Change Into the Linux Kernel
  or
 Care And Operation Of Your Linus Torvalds



For a person or company who wishes to submit a change to the Linux
kernel, the process can sometimes be daunting if you're not familiar
with "the system."  This text is a collection of suggestions which
can greatly increase the chances of your change being accepted.

Read Documentation/SubmitChecklist for a list of items to check
before submitting code.  If you are submitting a driver, also read
Documentation/SubmittingDrivers.



--------------------------------------------
SECTION 1 - CREATING AND SENDING YOUR CHANGE
--------------------------------------------



1) "diff -up"
------------

Use "diff -up" or "diff -uprN" to create patches.

All changes to the Linux kernel occur in the form of patches, as
generated by diff(1).  When creating your patch, make sure to create it
in "unified diff" format, as supplied by the '-u' argument to diff(1).
Also, please use the '-p' argument which shows which C function each
change is in - that makes the resultant diff a lot easier to read.
Patches should be based in the root kernel source directory,
not in any lower subdirectory.

To create a patch for a single file, it is often sufficient to do:

 SRCTREE= linux-2.6
 MYFILE=  drivers/net/mydriver.c

 cd $SRCTREE
 cp $MYFILE $MYFILE.orig
 vi $MYFILE # make your change
 cd ..
 diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch

To create a patch for multiple files, you should unpack a "vanilla",
or unmodified kernel source tree, and generate a diff against your
own source tree.  For example:

 MYSRC= /devel/linux-2.6

 tar xvfz linux-2.6.12.tar.gz
 mv linux-2.6.12 linux-2.6.12-vanilla
 diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
  linux-2.6.12-vanilla $MYSRC > /tmp/patch

"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch.  The "dontdiff" file is included in the kernel tree in
2.6.12 and later.  For earlier kernel versions, you can get it
from .

Make sure your patch does not include any extra files which do not
belong in a patch submission.  Make sure to review your patch -after-
generated it with diff(1), to ensure accuracy.

If your changes produce a lot of deltas, you may want to look into
splitting them into individual patches which modify things in
logical stages.  This will facilitate easier reviewing by other
kernel developers, very important if you want your patch accepted.
There are a number of scripts which can aid in this:

Quilt:
http://savannah.nongnu.org/projects/quilt

Andrew Morton's patch scripts:
http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
Instead of these scripts, quilt is the recommended patch management
tool (see above).



2) Describe your changes.

Describe the technical detail of the change(s) your patch includes.

Be as specific as possible.  The WORST descriptions possible include
things like "update driver X", "bug fix for driver X", or "this patch
includes updates for subsystem X.  Please apply."

The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management
system, git, as a "commit log".  See #15, below.

If your description starts to get long, that's a sign that you probably
need to split up your patch.  See #3, next.



3) Separate your changes.

Separate _logical changes_ into a single patch file.

For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
or more patches.  If your changes include an API update, and a new
driver which uses that new API, separate those into two patches.

On the other hand, if you make a single change to numerous files,
group those changes into a single patch.  Thus a single logical change
is contained within a single patch.

If one patch depends on another patch in order for a change to be
complete, that is OK.  Simply note "this patch depends on patch X"
in your patch description.

If you cannot condense your patch set into a smaller set of patches,
then only post say 15 or so at a time and wait for review and integration.



4) Style check your changes.

Check your patch for basic style violations, details of which can be
found in Documentation/CodingStyle.  Failure to do so simply wastes
the reviewers time and will get your patch rejected, probably
without even being read.

At a minimum you should check your patches with the patch style
checker prior to submission (scripts/checkpatch.pl).  You should
be able to justify all violations that remain in your patch.



5) Select e-mail destination.

Look through the MAINTAINERS file and the source code, and determine
if your change applies to a specific subsystem of the kernel, with
an assigned maintainer.  If so, e-mail that person.

If no maintainer is listed, or the maintainer does not respond, send
your patch to the primary Linux kernel developer's mailing list,
linux-kernel@vger.kernel.org.  Most kernel developers monitor this
e-mail list, and can comment on your changes.


Do not send more than 15 patches at once to the vger mailing lists!!!


Linus Torvalds is the final arbiter of all changes accepted into the
Linux kernel.  His e-mail address is . 
He gets a lot of e-mail, so typically you should do your best to -avoid-
sending him e-mail. 

Patches which are bug fixes, are "obvious" changes, or similarly
require little discussion should be sent or CC'd to Linus.  Patches
which require discussion or do not have a clear advantage should
usually be sent first to linux-kernel.  Only after the patch is
discussed should the patch then be submitted to Linus.



6) Select your CC (e-mail carbon copy) list.

Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.

Other kernel developers besides Linus need to be aware of your change,
so that they may comment on it and offer code review and suggestions.
linux-kernel is the primary Linux kernel developer mailing list.
Other mailing lists are available for specific subsystems, such as
USB, framebuffer devices, the VFS, the SCSI subsystem, etc.  See the
MAINTAINERS file for a mailing list that relates specifically to
your change.

Majordomo lists of VGER.KERNEL.ORG at:
 

If changes affect userland-kernel interfaces, please send
the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
a man-pages patch, or at least a notification of the change,
so that some information makes its way into the manual pages.

Even if the maintainer did not respond in step #5, make sure to ALWAYS
copy the maintainer when you change their code.

For small patches you may want to CC the Trivial Patch Monkey
trivial@kernel.org which collects "trivial" patches. Have a look
into the MAINTAINERS file for its current manager.
Trivial patches must qualify for one of the following rules:
 Spelling fixes in documentation
 Spelling fixes which could break grep(1)
 Warning fixes (cluttering with useless warnings is bad)
 Compilation fixes (only if they are actually correct)
 Runtime fixes (only if they actually fix things)
 Removing use of deprecated functions/macros (eg. check_region)
 Contact detail and documentation fixes
 Non-portable code replaced by portable code (even in arch-specific,
 since people copy, as long as it's trivial)
 Any fix by the author/maintainer of the file (ie. patch monkey
 in re-transmission mode)



7) No MIME, no links, no compression, no attachments.  Just plain text.

Linus and other kernel developers need to be able to read and comment
on the changes you are submitting.  It is important for a kernel
developer to be able to "quote" your changes, using standard e-mail
tools, so that they may comment on specific portions of your code.

For this reason, all patches should be submitting e-mail "inline".
WARNING:  Be wary of your editor's word-wrap corrupting your patch,
if you choose to cut-n-paste your patch.

Do not attach the patch as a MIME attachment, compressed or not.
Many popular e-mail applications will not always transmit a MIME
attachment as plain text, making it impossible to comment on your
code.  A MIME attachment also takes Linus a bit more time to process,
decreasing the likelihood of your MIME-attached change being accepted.

Exception:  If your mailer is mangling patches then someone may ask
you to re-send them using MIME.

See Documentation/email-clients.txt for hints about configuring
your e-mail client so that it sends your patches untouched.

8) E-mail size.

When sending patches to Linus, always follow step #7.

Large changes are not appropriate for mailing lists, and some
maintainers.  If your patch, uncompressed, exceeds 300 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.



9) Name your kernel version.

It is important to note, either in the subject line or in the patch
description, the kernel version to which this patch applies.

If the patch does not apply cleanly to the latest kernel version,
Linus will not apply it.



10) Don't get discouraged.  Re-submit.

After you have submitted your change, be patient and wait.  If Linus
likes your change and applies it, it will appear in the next version
of the kernel that he releases.

However, if your change doesn't appear in the next version of the
kernel, there could be any number of reasons.  It's YOUR job to
narrow down those reasons, correct what was wrong, and submit your
updated change.

It is quite common for Linus to "drop" your patch without comment.
That's the nature of the system.  If he drops your patch, it could be
due to
* Your patch did not apply cleanly to the latest kernel version.
* Your patch was not sufficiently discussed on linux-kernel.
* A style issue (see section 2).
* An e-mail formatting issue (re-read this section).
* A technical problem with your change.
* He gets tons of e-mail, and yours got lost in the shuffle.
* You are being annoying.

When in doubt, solicit comments on linux-kernel mailing list.



11) Include PATCH in the subject

Due to high e-mail traffic to Linus, and to linux-kernel, it is common
convention to prefix your subject line with [PATCH].  This lets Linus
and other kernel developers more easily distinguish patches from other
e-mail discussions.



12) Sign your work

To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as a open-source patch.  The rules are pretty simple: if you
can certify the below:

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

 (d) I understand and agree that this project and the contribution
     are public and that a record of the contribution (including all
     personal information I submit with it, including my sign-off) is
     maintained indefinitely and may be redistributed consistent with
     this project or the open source license(s) involved.

then you just add a line saying

 Signed-off-by: Random J Developer 

using your real name (sorry, no pseudonyms or anonymous contributions.)

Some people also put extra tags at the end.  They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off. 

If you are a subsystem or branch maintainer, sometimes you need to slightly
modify patches you receive in order to merge them, because the code is not
exactly the same in your tree and the submitters'. If you stick strictly to
rule (c), you should ask the submitter to rediff, but this is a totally
counter-productive waste of time and energy. Rule (b) allows you to adjust
the code, but then it is very impolite to change one submitter's code and
make him endorse your bugs. To solve this problem, it is recommended that
you add a line between the last Signed-off-by header and yours, indicating
the nature of your changes. While there is nothing mandatory about this, it
seems like prepending the description with your mail and/or name, all
enclosed in square brackets, is noticeable enough to make it obvious that
you are responsible for last-minute changes. Example :

 Signed-off-by: Random J Developer 
 [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
 Signed-off-by: Lucky K Maintainer 

This practise is particularly helpful if you maintain a stable branch and
want at the same time to credit the author, track changes, merge the fix,
and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one
which appears in the changelog.

Special note to back-porters: It seems to be a common and useful practise
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
here's what we see in 2.6-stable :

    Date:   Tue May 13 19:10:30 2008 +0000

        SCSI: libiscsi regression in 2.6.25: fix nop timer handling

        commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream

And here's what appears in 2.4 :

    Date:   Tue May 13 22:12:27 2008 +0200

        wireless, airo: waitbusy() won't delay

        [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]

Whatever the format, this information provides a valuable help to people
tracking your trees, and to people trying to trouble-shoot bugs in your
tree.


13) When to use Acked-by: and Cc:

The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.

If a person was not directly involved in the preparation or handling of a
patch but wishes to signify and record their approval of it then they can
arrange to have an Acked-by: line added to the patch's changelog.

Acked-by: is often used by the maintainer of the affected code when that
maintainer neither contributed to nor forwarded the patch.

Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
has at least reviewed the patch and has indicated acceptance.  Hence patch
mergers will sometimes manually convert an acker's "yep, looks good to me"
into an Acked-by:.

Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code.  Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives.

If a person has had the opportunity to comment on a patch, but has not
provided such comments, you may optionally add a "Cc:" tag to the patch.
This is the only tag which might be added without an explicit action by the
person it names.  This tag documents that potentially interested parties
have been included in the discussion


14) Using Reported-by:, Tested-by: and Reviewed-by:

If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution.  Please
note that this tag should not be added without the reporter's permission,
especially if the problem was not reported in a public forum.  That said,
if we diligently credit our bug reporters, they will, hopefully, be
inspired to help us again in the future.

A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named.  This tag informs maintainers that
some testing has been performed, provides a means to locate testers for
future patches, and ensures credit for the testers.

Reviewed-by:, instead, indicates that the patch has been reviewed and found
acceptable according to the Reviewer's Statement:

 Reviewer's statement of oversight

 By offering my Reviewed-by: tag, I state that:

   (a) I have carried out a technical review of this patch to
      evaluate its appropriateness and readiness for inclusion into
      the mainline kernel.

  (b) Any problems, concerns, or questions relating to the patch
      have been communicated back to the submitter.  I am satisfied
      with the submitter's response to my comments.

  (c) While there may be things that could be improved with this
      submission, I believe that it is, at this time, (1) a
      worthwhile modification to the kernel, and (2) free of known
      issues which would argue against its inclusion.

  (d) While I have reviewed the patch and believe it to be sound, I
      do not (unless explicitly stated elsewhere) make any
      warranties or guarantees that it will achieve its stated
      purpose or function properly in any given situation.

A Reviewed-by tag is a statement of opinion that the patch is an
appropriate modification of the kernel without any remaining serious
technical issues.  Any interested reviewer (who has done the work) can
offer a Reviewed-by tag for a patch.  This tag serves to give credit to
reviewers and to inform maintainers of the degree of review which has been
done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.


15) The canonical patch format

The canonical patch subject line is:

    Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:

  - A "from" line specifying the patch author.

  - An empty line.

  - The body of the explanation, which will be copied to the
    permanent changelog to describe this patch.

  - The "Signed-off-by:" lines, described above, which will
    also go in the changelog.

  - A marker line containing simply "---".

  - Any additional comments not suitable for the changelog.

  - The actual patch (diff output).

The Subject line format makes it very easy to sort the emails
alphabetically by subject line - pretty much any email reader will
support that - since because the sequence number is zero-padded,
the numerical and alphabetic sort is the same.

The "subsystem" in the email's Subject should identify which
area or subsystem of the kernel is being patched.

The "summary phrase" in the email's Subject should concisely
describe the patch which that email contains.  The "summary
phrase" should not be a filename.  Do not use the same "summary
phrase" for every patch in a whole patch series (where a "patch
series" is an ordered sequence of multiple, related patches).

Bear in mind that the "summary phrase" of your email becomes a
globally-unique identifier for that patch.  It propagates all the way
into the git changelog.  The "summary phrase" may later be used in
developer discussions which refer to the patch.  People will want to
google for the "summary phrase" to read discussion regarding that
patch.  It will also be the only thing that people may quickly see
when, two or three months later, they are going through perhaps
thousands of patches using tools such as "gitk" or "git log
--oneline".

For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary.  It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.

The "summary phrase" may be prefixed by tags enclosed in square
brackets: "Subject: [PATCH tag] ".  The tags are not
considered part of the summary phrase, but describe how the patch
should be treated.  Common tags might include a version descriptor if
the multiple versions of the patch have been sent out in response to
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
comments.  If there are four patches in a patch series the individual
patches may be numbered like this: 1/4, 2/4, 3/4, 4/4.  This assures
that developers understand the order in which the patches should be
applied and that they have reviewed or applied all of the patches in
the patch series.

A couple of example Subjects:

    Subject: [patch 2/5] ext2: improve scalability of bitmap searching
    Subject: [PATCHv2 001/207] x86: fix eflags tracking

The "from" line must be the very first line in the message body,
and has the form:

        From: Original Author 

The "from" line specifies who will be credited as the author of the
patch in the permanent changelog.  If the "from" line is missing,
then the "From:" line from the email header will be used to determine
the patch author in the changelog.

The explanation body will be committed to the permanent source
changelog, so should make sense to a competent reader who has long
since forgotten the immediate details of the discussion that might
have led to this patch.  Including symptoms of the failure which the
patch addresses (kernel log messages, oops messages, etc.) is
especially useful for people who might be searching the commit logs
looking for the applicable patch.  If a patch fixes a compile failure,
it may not be necessary to include _all_ of the compile failures; just
enough that it is likely that someone searching for the patch can find
it.  As in the "summary phrase", it is important to be both succinct as
well as descriptive.

The "---" marker line serves the essential purpose of marking for patch
handling tools where the changelog message ends.

One good use for the additional comments after the "---" marker is for
a diffstat, to show what files have changed, and the number of
inserted and deleted lines per file.  A diffstat is especially useful
on bigger patches.  Other comments relevant only to the moment or the
maintainer, not suitable for the permanent changelog, should also go
here.  A good example of such comments might be "patch changelogs"
which describe what has changed between the v1 and v2 version of the
patch.

If you are going to include a diffstat after the "---" marker, please
use diffstat options "-p 1 -w 70" so that filenames are listed from
the top of the kernel source tree and don't use too much horizontal
space (easily fit in 80 columns, maybe with some indentation).

See more details on the proper patch format in the following
references.


16) Sending "git pull" requests  (from Linus emails)

Please write the git repo address and branch name alone on the same line
so that I can't even by mistake pull from the wrong branch, and so
that a triple-click just selects the whole thing.

So the proper format is something along the lines of:

 "Please pull from

  git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus

  to get these changes:"

so that I don't have to hunt-and-peck for the address and inevitably
get it wrong (actually, I've only gotten it wrong a few times, and
checking against the diffstat tells me when I get it wrong, but I'm
just a lot more comfortable when I don't have to "look for" the right
thing to pull, and double-check that I have the right branch-name).


Please use "git diff -M --stat --summary" to generate the diffstat:
the -M enables rename detection, and the summary enables a summary of
new/deleted or renamed files.

With rename detection, the statistics are rather different [...]
because git will notice that a fair number of the changes are renames.

-----------------------------------
SECTION 2 - HINTS, TIPS, AND TRICKS
-----------------------------------

This section lists many of the common "rules" associated with code
submitted to the kernel.  There are always exceptions... but you must
have a really good reason for doing so.  You could probably call this
section Linus Computer Science 101.



1) Read Documentation/CodingStyle

Nuff said.  If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.

One significant exception is when moving code from one file to
another -- in this case you should not modify the moved code at all in
the same patch which moves it.  This clearly delineates the act of
moving the code and your changes.  This greatly aids review of the
actual differences and allows tools to better track the history of
the code itself.

Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl).  The style checker should be viewed as
a guide not as the final word.  If your code looks better with
a violation then its probably best left alone.

The checker reports at three levels:
 - ERROR: things that are very likely to be wrong
 - WARNING: things requiring careful review
 - CHECK: things requiring thought

You should be able to justify all violations that remain in your
patch.



2) #ifdefs are ugly

Code cluttered with ifdefs is difficult to read and maintain.  Don't do
it.  Instead, put your ifdefs in a header, and conditionally define
'static inline' functions, or macros, which are used in the code.
Let the compiler optimize away the "no-op" case.

Simple example, of poor code:

 dev = alloc_etherdev (sizeof(struct funky_private));
 if (!dev)
  return -ENODEV;
 #ifdef CONFIG_NET_FUNKINESS
 init_funky_net(dev);
 #endif

Cleaned-up example:

(in header)
 #ifndef CONFIG_NET_FUNKINESS
 static inline void init_funky_net (struct net_device *d) {}
 #endif

(in the code itself)
 dev = alloc_etherdev (sizeof(struct funky_private));
 if (!dev)
  return -ENODEV;
 init_funky_net(dev);



3) 'static inline' is better than a macro

Static inline functions are greatly preferred over macros.
They provide type safety, have no length limitations, no formatting
limitations, and under gcc they are as cheap as macros.

Macros should only be used for cases where a static inline is clearly
suboptimal [there are a few, isolated cases of this in fast paths],
or where it is impossible to use a static inline function [such as
string-izing].

'static inline' is preferred over 'static __inline__', 'extern inline',
and 'extern __inline__'.



4) Don't over-design.

Don't try to anticipate nebulous future cases which may or may not
be useful:  "Make it as simple as you can, and no simpler."



----------------------
SECTION 3 - REFERENCES
----------------------

Andrew Morton, "The perfect patch" (tpp).
  

Jeff Garzik, "Linux kernel patch submission format".
  

Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
  
  
  
  

NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
  

Kernel Documentation/CodingStyle:
  

Linus Torvalds's mail on the canonical patch format:
  

Andi Kleen, "On submitting kernel patches"
  Some strategies to get difficult or controversal changes in.
  http://halobates.de/on-submitting-patches.pdf

--

Monday, March 19, 2012

Wednesday, February 01, 2012

[轉錄]C/C++ 的多維動態陣列



http://ehome.hifly.to/showthread.php?threadid=357


多維動態陣列在 C 中 大概只能用 malloc,但這在一維時尚
不構成問題,但需要多維陣列時怎麼辦呢?這算是程式論壇
最常被問到的問題之一了。
我把它整理了相關的回覆,都只用二維做說明,更多維的陣列
類推即可。
就從 C 談起吧!

動態產生一個[m][n]陣列 Array 的方法 
code:
int i; int **Array; Array= (int **)malloc(m*sizeof(void *)); for (i=0; i Array[i]=(int *)malloc(n*sizeof(int *));

這樣你就有一個 int Array[m][n]; 可以用了
是C 喔!不是 C++
但這不夠好,若你要的是一個較大的mXn陣列,那麼太多的malloc
會使記憶體碎片化(memory fragment)!沒關係,窮則變,變則通!
問題既出在for loop不斷的 memory allocation,就從那兒下手: 
code:
int i; int **Array, *pData; Array= (int **)malloc(m*sizeof(int *)); pData= (int *)malloc(m*n*sizeof(int)); for (i=0; i Array[i]=pData;

注意到嗎?這次只用了二次的malloc。
當要release memory也只要free Array[0] 和 Array 就成了!
(注意先free Array[0] 再 free Array)
如果嫌兩個alloc/free還是太多,也可簡單併成一個: 
code:
int i; int **Array, *pData; Array= (int **)malloc(m*sizeof(int *)+m*n*sizeof(int)); for (i=0,pData= (int *)(Array+m); i Array[i]=pData;

要 free 時只要 free Array 就行了,帥吧?
如果用的是C++,那可用的方法就更多了!

《幼幼班》嘗試錯誤的階段
?> int Array[][] = new int [10][20];//這樣行ㄇ?
當然不行! int Array[][]不是一個指標,而且只能有
一維為不定大小。

《小班》終於會從1數到100了
?> 那...
?> int *Array[] = new int [10][20];//這樣行ㄇ?
有點想法了!但可惜的是 '*' 在 C++的語法是修飾前面的
識別字,所以 int *Array[]的意思是 "Array是一個 int 指標
的一維陣列!"

如果能使那個 '*' 以獨立指標型態去宣告Array,就會變成
"Array是一個指標,指向一維 int 的陣列",而我們知道指標
本身就可以當做一維的陣列,那麼是不是就成了"Array是一個二維
的int陣列"?
對了!這正是我們要的!問題是怎麼讓'*'成為獨立指標型態,
不會去修飾前面的int識別字?答案是使用括號:
int (*Array)[20] = new int [10][20];//這是正解!

但問題又來了, new 運算子可以使用 new int [m][n],但
int (*Array)[20] 的 [20]卻沒辦法以 [n] 來取代,所以就
沒辦法做到不定大小的宣告了。所以這只能算是小班的答案,
要做到不定大小的動態多維宣告,加上 STL 的運用,是不錯
的想法。

《中班》vector 模板的運用
vector *array=new vector[m];
for (int i=0; i
嘿嘿...不錯吧!?不定大小的二維陣列,而且每個維度還
可以隨時調整大小喔!
不過還是有缺點ㄟ!!那行 for loop 看起來有點礙眼,不能
拿掉嗎?拿掉的話,基本上Array 還是二維陣列,但第二維
並沒有預留空間放東西你可以用push.back等成員函式來增加
空間和存放data,但不能在還沒有空間時使用像
array[5][3]=3; 這種陣列的存取方式。沒更好的方法了嗎?
vector 不是有預留空間大小的建構子嗎?像一維的宣告:
vector *Array= new vector (n);
//這不是預留了 n 個元素的陣列了嗎?
只可惜,這是一維的宣告,若你嘗試做這樣的宣告:
vector *Array= new vector [m](n);
編譯器會給你無情的嘲諷:陣列不能呼叫帶參數的建構子!
這是很令人失望的!為十麼不行?不是邏輯的問題,或許下
一版本的C++會可以這樣宣告吧!但為今之計只能自力救濟
了。

《大班》使用模板在模版中
仔細觀察下面的宣告:
vector > Array(m, vector(n));

不用懷疑!這是相當於宣告一個動態二維不定大小的 int Array[m][n];
不相信的話你可以在m,n範圍內存取 Array[i][j] 看看。
若你能一眼看出這是在幹嘛,那麼你早已超出大班的程度了!
若你暫時不知所云,也沒關係,你可以安全的使用它帶給你的好處。
只是你也只好留在大班留班查看了 ^_^

解釋這個宣告,其實不難,但首先你要對模版的使用有相當的了解,當然
還要對 vector 模版的建構子不能陌生。這樣子自然很容易可以看得懂它。
了然於胸了嗎?恭喜你,大班可以畢業了 ^_@


註:大班的答案是Duncan在練功房提出的解答,注意到兩個
兩個角括號中間的空白了嗎?(> >)
               ^-------這裡要有空白
不加空白的話會被語法解析為右移運算子。