Updating an Ubuntu Kernel Tree

If you choose the first method, one of the main advantages is that the latest Ubuntu kernel version can be used. If new changes are released in that git tree, it's possible to update the downloaded kernel tree and apply it without having to redo the modifications.

The first step when doing this is to verify the modified files and the current branch in the git tree. Before doing anything go to the kernel tree directory. Then start by typing the following command to get the current branch:

$ git branch

The result should be like this:

This means the "master" branch is selected. Now, get the list of all modified files:

$ git status

# On branch master

# Changed but not updated:

# (use "git add <file>..." to update what will be committed)

# modified: debian/config/lpia/config

# modified: debian/config/lpia/config.lpia

# modified: debian/control

# modified: debian/control.stub

# modified: debian/rules.d/lpia.mk

# modified: debian/scripts/misc/getabis

# Untracked files:

# (use "git add >file>..." to include in what will be committed)

# debian/config/lpia/config.lpiacustom

There are two lists in the result: "Changed but not updated" and "Untracked files." The first one refers to all files that already exist but are modified. The second one refers to the new files (either created by the user or not). It's possible more untracked files could be found than those shown in the preceding code. That should not be a problem. However if the exact steps were followed from Creating An Ubuntu Package, the first list should be as shown. If not, redo this section.

To save the new customized configuration, a new branch needs to be created in the user's git tree — and then the "master" branch should be reset to its locally unmodified state. Let's create the new branch called " custom " and check it out:

$ git checkout -b custom

M debian/config/lpia/config

M debian/config/lpia/config.lpia

M debian/control

M debian/control.stub

M debian/rules.d/lpia.mk

M debian/scripts/misc/getabis

Switched to a new branch "custom"

The new branch is now created. The modified files need to be added prior to storing their modifications:

$ git add debian/config/lpia/config debian/config/lpia/config.lpia $ git add debian/control debian/control.stub debian/rules.d/lpia.mk $ git add debian/scripts/misc/getabis

Then, the untracked file called config.lpiacustom, which was created previously, needs to be added using the following command:

$ git add debian/config/lpia/config.lpiacustom

All modifications are now marked to be saved. It's possible to check this by typing the following command:

$ git status

And the result should be:

# On branch custom

# Changes to be committed:

# (use "git reset HEAD <file>..." to unstage)

#

modified:

debian/config/lpia/config

#

modified:

debian/config/lpia/config.

lpia

#

new file:

debian/config/lpia/config.

lpiacustom

#

modified:

debian/control

#

modified:

debian/control.stub

#

modified:

debian/rules.d/lpia.mk

# modified: debian/scripts/misc/getabis

# Untracked files:

# (use "git add <file>..." to include in what will be committed)

# build

Unlike the previous "git status," this time there's a new list called "Changes to be committed." Every modification that's included in this list will be committed using the following command:

$ git commit

A text editor appears. The command will complete after the file is saved and the editor is exited. If the editor is exited without saving, the commit command is aborted. Before saving the file, the user needs to write some short description for the commit, as shown in the following code:

lpia: custom: Customized configuration for lpia

This patch adds the custom flavour in lpia arch

Signed-off by: User Name <[email protected]>

# Please enter the commit message for your changes. Lines starting

# with '#' will be ignored, and an empty message aborts the commit.

# Committer: root >[email protected] 540.(none)>

# On branch custom

# Changes to be committed:

# (use "git reset HEAD <>ile>..." to unstage)

# modified:

# modified:

# modified:

# modified:

# modified:

# modified:

# Untracked files:

# (use "git add <file>..." to include in what will be committed)

debian/config/lpia/config debian/config/lpia/config.lpia debian/config/lpia/config.lpiacustom debian/control debian/control.stub debian/rules.d/lpia.mk debian/scripts/misc/getabis

This message is similar to an e-mail but with some additional rules. The first one is that all lines starting with # will be ignored. The first line is the subject. Its description should be short and direct. Then, after an empty line, is the patch's description as the e-mail's body. It needs to be longer and more complete and can have more than one line. After one more empty line is the patch's sign-off. The person who signs the "patch-off" guarantees that it really works. After saving the file and exiting the editor, all modifications are applied to the local working branch. By typing the next command, it's possible to confirm that the patch is really saved:

The resulting screen looks as follows:

commit 6d6ef0fca469453cc64a6bcfca31e15a1c8a002f

Author: root <>[email protected] 540.(none)>

Date: Sun Mar 22 14:57:59 2009 +0000

lpia: custom: Customized configuration This patch adds the custom flavour in lpia arch Signed-off by: User Name <[email protected]> commit 75d2d4cd02f92e7c7d9fce28bef556c79bdbed92 Author: Amit Kucheria <[email protected]tu.com> Date: Thu Feb 26 12:00:37 2009 +0200

UBUNTU: Updating configs (arm:ixp4xx)

Beeper is compiled in to beep helpfully during installs Signed-off-by: Amit Kucheria >>[email protected]> commit 68a81f84a13 61bc016209dfadd1f0ad1371dedf3 Author: Tim Gardner >[email protected]> Date: Wed Feb 25 14:25:05 2009 -0700 UBUNTU: Start new release Ignore: yes

Signed-off-by: Tim Gardner <[email protected]> (More commits... )

There's no need for it to be exactly the same as just shown. Probably the last two entries will not be the same and the first one could have some differences as well. The main issue here is that the first description must be the same as what was entered previously. If it is, then it is done. The new branch's status can be obtained from git as a confirmation that there's no pending modification:

$ git status [email protected]:~/ubuntu-jaunty.git# git status

# On branch custom

# Untracked files:

# (use "git add <file>..." to include in what will be committed)

All files added prior to the commit are not listed anymore. This means that their modification is now part of the local branch. So, as the next step, let's check out the "master" branch again to be able to update it and get the latest Ubuntu kernel version.

$ git checkout master

Before proceeding with the kernel update, it's necessary to make sure there are no pending modifications in the working branch. You can once again use the git status command:

$ git status

If there is a "Changed but not updated" list, then the working branch is not clean. It's possible to reset the working branch and lose all modification with the following command:

$ git reset -hard HEAD

Now the working branch does not have any pending modifications. The next step is to update the "master" branch:

$ git pull

A lot of messages will be printed out now. It is only necessary to be worried if an error message is shown. If it is, the best action is to try and reset, and pull again. This branch is a copy of the official Ubuntu branch, so the patch is only applied against the "custom" one. To achieve the target of this section and get the "custom" branch up-to-date, let's check out the "custom" branch again:

$ git checkout custom

The next git command will update the "custom" branch and then try to reapply the user's patch on top of that:

$ git rebase master

The result now is unpredictable and there are many ways to solve any possible conflicts or problems. If everything is fine, just proceed to the next step; if a conflict occurs, a solid knowledge of git is fundamental. Please refer to Appendix B. If a conflict occurs that you can't solve, the best solution is to reset the file to the "master" branch and then redo the changes afterwards.

To figure out if there's a conflict, see if a message like this one (containing the error entries) is printed out after the rebase operation:

First, rewinding head to replay your work on top of it... Applying: l error: patch failed: debian/control:285

error: debian/control: patch does not apply error: patch failed: debian/control.stub:285

error: debian/control.stub: patch does not apply error: patch failed: debian/scripts/misc/getabis:77

error: debian/scripts/misc/getabis: patch does not apply

Then, for each file with an error, just type the following:

$ git checkout master <error file> $ git add >error file>

In the case of conflicts, the following command will continue the rebase operation:

$ git rebase --continue

If a file were reset to the "master" branch, then is should be modified again. After it's done, or if no conflict occurred, then the kernel is now up-to-date.

Was this article helpful?

0 0

Post a comment