Linux 作業系統安裝盤的定製

來源:互聯網
上載者:User
Linux 作業系統安裝盤的定製

汪倫偉 (xc_wangwei@163.com),
國防科技大學博士研究生

簡介: 本文闡述如何以一個現有的 RedHat Linux系統安裝盤為藍本,定製符合需要的 Linux 系統安裝盤。

發布日期: 2005 年 3 月 01 日
層級: 初級
訪問情況 : 6010 次瀏覽
評論: 0 (查看 | 添加評論
- 登入)

平均分 (5個評分)
為本文評分

1 引言

通常由於某種實際應用,需要一個包含所有最新動向的RPM包的作業系統發布盤,以備在安裝時一次完成所有的更新操作,或者是想定製一個有自己特色的作業系統發布盤,如將自己開發的應用程式通過建立RPM包,加入到作業系統中,在系統安裝時一次完成,形成包含自己產品的作業系統發布盤。這些都需要重建安裝盤,而且產生安裝盤也是十分必要的,因為作業系統發布商在每一次正式發布後,總會對一些漏洞進行更新處理,有些還是與安全相關的,在重建安裝盤時就可以將這些bug修複添加進你自己定製的安裝盤中,對一些裝置新開發的驅動程式提供支援也需要重建安裝盤。

在一些嵌入式具體應用中,由於其對作業系統的要求較具體,不需要當前作業系統安裝盤中內建的那麼多的功能,如Fedora Core 2當前有4張安裝盤,它包含了許多其它的應用,如office、娛樂和遊戲等等,而一些具體的應用根本不需要這麼多的功能,因此,它們常常需要基於一個版本的作業系統,然後對之進行相應的裁減,使之能滿足具體應用的實際需要,而不需要其它的多餘的功能。因此,通過作業系統安裝盤的定製,可以根據自己或實際的需要,選擇有用的軟體包,組成安裝盤,從而通過定製作業系統的安裝,滿足具體應用的需要。

我們在定製作業系統安裝盤之前,必須有一個藍本作為安裝盤的基礎,比如是Red Hat 9.0安裝盤或Fedora Core 2安裝盤,也可以是Red Hat 9.0或Fedora Core 2安裝盤的iso檔案,這些我們可以從Red Hat的網站或其它一些網站上下載。現假設我們已經有了Fedora Core 2的安裝盤,下面我們先大略看一下Fedora Core 2的安裝盤裡面的內容。

在安裝盤中有一個目錄為Fedora,它包含了發布盤的核心內容,如下:

drwxr-xr-x    2 root     root         2048 May 13 2004 basedrwxr-xr-x    2 root     root        77824 May 13 2004 RPMS

RPMS目錄包含Fedora Core 2發布盤的主要部分,它是一些RPM檔案。RPM包通常包含二進位可執行檔、有關的設定檔和文檔,我們可以參考RPM協助以獲得更多資訊。

base 目錄中包含一些在安裝過程中所需要的檔案,如comps.xml檔案,它定義哪個組件包含哪些RPM包以及RPM包之間的依賴關係,需要注意的是,在comps.xml檔案中表示哪個組件有哪些RPM包採用的是RPM包名,而不是包的檔案名稱。比如perl-5.8.3-18.i386.rpm這個檔案名稱,在comps.xml中所表示的RPM包名為perl。對於comps.xml檔案,我們會在後面作進一步解釋。另一個重要的檔案是hdlist檔案,它包含了RPM目錄中的所有RPM包大部分的標頭檔,這意味著在RPM包中相互依賴關係可以通過讀取hdlist檔案而決定,而不需要讀所有的RPM包。hdlist檔案的另一個作用是將包名映射到檔案名稱,如將perl包名映射到perl-5.8.3-18.i386.rpm,這意味著如果你想更新RPM包或添加你自己的包到RPM目錄中,你就需要更新hdlist這個檔案,這會在後面進行描述。

回頁首

2 RPM操作

RPM(Redhat Package Management)是由RedHat開發的,在Linux系統下的系統包管理工具。它的目標是:使包的安裝和卸載過程更容易,它能夠證實一個包是否已經正確安裝了,可以簡化包的建立過程,可以從原始碼建立整個包,它能用於不同的體繫結構。RPM系統已經成為現在Linux系統下包管理工具事實上的標準,並且它也移植到很多商業的unix系統之下。

RPM包由包標籤對它標識,包標籤包含軟體名,軟體版本,包的發行版本幾部分。在包的內部還包含包的建立時間,包的內容描述,安裝包的所有檔案的大小,數位簽章以證實包的完整性等資訊。RMP包還包含包內的檔案資訊,其中包括:每個檔案的檔案名稱,每個檔案的許可權,檔案的屬組和擁有者,每個檔案的md5校正和,檔案的內容等。

RPM包管理系統提供了下列功能:安裝新的包,卸載舊的包,將一箇舊包升級為新的包,獲得已經安裝包的資訊等。

Red Hat發布盤主要是由一些RPM包組成。RPM包的名字包含一個尾碼:arch.rpm,arch 指的是體繫結構,對於Intel平台的有i386、i586、i686等,你所安裝的包必須要與機器上的共用庫的版本相匹配。如果你發現某個RPM包沒有安裝,你可以自己安裝。任何時候,你都可以(必須是root使用者)安裝RPM包。RPM命令使用輕參考相關資料。

回頁首

3 RPM包建立過程

為了完成RPM包的建立,需要執行以下步驟:

  • 執行spec檔案prep節的命令和宏;
  • 檢查檔案清單的內容;
  • 執行spec檔案build節的命令和宏;
  • 執行spec檔案install節的命令和宏,同時也執行檔案清單中的宏;
  • 建立二進位包檔案;
  • 建立源碼包。

為了執行打包的工作,RPM需要一系列目錄完成建立的工作。正常的目錄結構通常由一個頂級目錄和五個子目錄構成。這五個子目錄分別是:

  1. SOURCES------包含原始的源檔案和補丁檔案。
  2. SPECS--------包含控制RPM包建立過程的spec檔案。
  3. BUILD--------包含源碼解包和軟體建立的目錄。
  4. RPMS---------包含建立過程建立的二進位包檔案。
  5. SRPMS--------包含建立過程建立的源碼包檔案。

除了上述這五個主要的目錄外,在RPMS或SRPMS目錄下通常還會有關於RPM包目標平台的目錄。例如,i386、i586、i686等代表與Intel相容cpu的平台,noarch目錄下的RPM包代表可以在任何平台下執行。

3.1 SPEC檔案

spec檔案是整個RPM包建立過程的中心,它的作用就如同編譯器時的Makefile檔案。spec檔案包含建立一個RPM包必需的資訊,包括哪些檔案是包的一部分以及它們安裝在哪個目錄下。這個檔案一般分為如下的幾節:

(1) Preamle(序言)

序言包含使用者請求包的資訊時所顯示的內容。它可以包含包的功能描述、包的軟體版本、著作權資訊和所屬的包組等。Summary 是一行關於該軟體包的描述,Name 是該軟體包的基名,Version 是該軟體的版本號碼,Release 是 RPM 本身的版本號碼,如果修複了 spec 檔案中的一個錯誤並發布了該軟體同一版本的新 RPM,就應該增加發行版號。License 應該給出一些許可術語(如:"GPL"、"Commercial"、"Shareware"),Group 標識軟體類型。那些試圖協助人們管理 RPM 的程式通常按照組列出
RPM。您可以在usr/share/doc/rpm-4.0.4/GROUPS 檔案看到一個 Red Hat 使用的組列表(假設您安裝的 RPM 版本是 4.0.4)。但是您還可以使用那些組名以外的名稱。Source0、Source1等等給這些源檔案命名(通常為 tar.gz 檔案)。%{name} 和 %{version} 是 RPM 宏,它們擴充成為頭中定義的 rpm 名稱和版本。

要注意的是,你不要在 Source 語句中包含任何路徑。預設情況下,RPM 會在 /usr/src/redhat/SOURCES 中尋找檔案,請將您的源檔案複製或連結到那裡。(要使 spec 檔案盡量可移植的話,應當盡量避免嵌入自己開發機器上的假想路徑。其他開發人員就可以指示 RPM 在別的目錄下尋找源檔案,而不用修改您的 spec 檔案。)

接下來的部分從 %description 行開始。您應該在這裡提供該軟體更多的描述,這樣任何人使用 rpm -qi 查詢您的軟體包時都可以看到它。您可以解釋這個軟體包做什麼,描述任何警告或附加的配置指令,等等。

(2) Prep節

Prep節進行實際的打包準備工作,它是使用節首碼%prep表示的。一般而言,這一節的主要工作是檢查標籤文法是否正確,刪除舊的軟體來源程式,對包含來源程式的tar檔案進行解碼。如果包含補丁(patch)檔案,將補丁檔案應用到解開的源碼中。它一般包含%setup與%patch兩個命令。%setup用於將軟體源碼包解開,執行%patch可將補丁檔案加入解開的來源程式中。

%setup
-n newdir---------將壓縮的軟體來源程式在newdir目錄下解開。
-c ---------------在解開來源程式之前先建立目錄。
-b num------------在包含多個來源程式時,將第num個來源程式解壓縮。
-T----------------不使用預設的解壓縮操作。

例如:

%setup -T -b 0
/*解開第一個來源程式檔案。*/
%setup -c -n newdir
/*建立目錄newdir,並在此目錄之下解開來源程式。*/
%patch
%patchN-------這裡N是數字,表示使用第N個補丁檔案,等價於%patch -P N
-p0-----------指定使用第一個補丁檔案,-p1指定使用第二個補丁檔案。-s------------在使用補丁時,不顯示任何資訊。
-b name-------在加入補丁檔案之前,將源檔案名稱上加入name。若為指定此參數,則預設源檔案加入.orig。
-T------------將所有打補丁時產生的輸出檔案刪除。

(3) Build節

這一節主要用於編譯源碼,它是使用節首碼%build表示的。這一節一般由多個make命令組成。

(4) Install節

這一節主要用於完成實際安裝軟體必須執行的命令,它是使用節首碼%install表示的。這一節一般是由make install指令構成,但是有時也會包含cp、mv、install等指令。

這一節還能指定在使用者安裝的系統上,包安裝時啟動並執行指令碼。這樣的指令碼稱為安裝(卸載)指令碼。它可以指定包安裝前、包安裝後、包除去前、包除去後的系統必須啟動並執行外殼程式段。在使用者安裝的系統上,為了驗證一個包是否已經成功安裝的驗證指令碼也可由這一節指定。

(5) Clean節

這一節所描述的內容表示在完成包建立的工作之後,自動執行此節下的指令碼進行附加的清除工作,它是使用節首碼%clean表示的。一般而言,這一節的內容是簡單地使用rm -rf $RPM_BUILD_ROOT命令,不需要指定此節的其它內容。

(6) 檔案清單

這一節指定構成包的檔案的列表,它是使用節首碼%files表示的。此外,它還包含一系列宏控制安裝後的檔案屬性和配置資訊。

%files 列出應該捆綁到 RPM 中的檔案,並能夠可選地設定許可權和其它資訊。在 %files 中,您可以使用 %defattr 來定義預設的許可權、所有者和組;%defattr(-,root,root) 會安裝 root 使用者擁有的所有檔案,使用當 RPM 從構建系統捆綁它們時它們所具有的任何許可權。

可以用 %attr(permissions,user,group) 覆蓋個別檔案的所有者和許可權。可以在 %files 中用一行包括多個檔案。可以通過在行中添加 %doc 或 %config 來標記檔案。%doc 告訴 RPM 這是一個文檔檔案,因此如果使用者安裝軟體包時使用 --excludedocs,將不安裝該檔案。您也可以在 %doc 下不帶路徑列出檔案名稱,RPM 會在構建目錄下尋找這些檔案並在 RPM 檔案中包括它們,並把它們安裝到 /usr/share/doc/%{name}-%{version}。以
%doc 的形式包括 README 和 ChangeLog 這樣的檔案是個好主意。

%config 告訴 RPM 這是一個設定檔。在升級時,RPM 將會試圖避免用 RPM 打包的預設設定檔覆蓋使用者仔細修改過的配置。

注意:如果在 %files 下列出一個目錄名,RPM 會包括該目錄下的所有檔案。通常這不是您想要的,特別對於 /bin 這樣的目錄。

(7) 改動日誌

這一節主要描述軟體的開發記錄,它是使用節首碼%changlog表示的。這個段的內容是為了開發人員能詳細的瞭解該軟體的開發過程,對於包的維護極有好處。

3.2 建立RPM包

如果我們需要對RPM包作修改,那麼我們首先需要將源碼包取來,比如我們要修改核心,那麼我們可以從網上或光碟片中取到核心的原始碼RPM包,如kernel-2.6.5-1.358.src.rpm,將源碼包解開:rpm -i kernel-2. 6.5-1.358.src.rpm,則該RPM中的內容將存放在目錄/usr/src/redhat/SOURCES和/usr/src/redhat/SPEC目錄中,前者存放的是源碼、補丁以及一些設定檔等,後者存放的是包對應的spec檔案,如kernel-2.6.spec,現在你就可以對核心進行修改。假定我們想另外再對核心打一個補丁,比如說:mypatch-2.6.5.patch,你需要將這個補丁檔案複製到/usr/src/redhat/SOURCES/目錄下,然後編輯kernel-2.6.spec檔案。你需要先在定義補丁檔案的最後加入對你補丁檔案的初始定義,如:

…………Patch10000: linux-2.6.0-compile.patch# Patch10010: linux-2.6.0-module-license.patchPatch10030: mypatch-2.6.5.patch      /*新加入的補丁檔案的定義*/# END OF PATCH DEFINITIONS…………

然後在檔案的後面加入對核心打補丁命令:

…………%patch10000 -p1%patch10030 -p1   /*新加入的打補丁命令*/# END OF PATCH APPLICATIONS…………

如果你還想對核心做其它的修改,你可以修改相應的檔案或添加相應的檔案,然後修改kernel-2.6.spec檔案。當spec檔案修改完成之後,你只需要執行rpmbuild -ba kernel-2.6.spec就可以產生所需要的RPM包了。另外需要注意的是,以產生核心包為例,假如我們想產生kernel-smp-2.6.5-1.358.i686.rpm包,在kernel-2.6.spec檔案中包含有一些開關選項,比如,在檔案的開頭需要定義建立哪些核心的RPM包,如:

%define buildup  1%define buildsmp  0%define buildsource  1

在通常情況下,在執行rpmbuild -ba kernel-2.6.spec 命令後,會建立一個kernel-2.6.5-1.358.i386.rpm、kernel-source-2.6.5-1.358.i386.rpm和源碼RPM包kernel-2.6.5-1.358.src.rpm。因此,當你需要建立支援SMP的核心的RPM包時,需要修改kernel-2.6.spec檔案開頭時的定義為:

%define buildup  1%define buildsmp  1%define buildsource  1%define -target_cpu    i686

此外,在檔案的開頭還需要定義-target_cpu 為i686,從而建立i686的核心RPM包,並且需要對/usr/lib/rpm目錄下面的一些宏重新定義,比如目前的目錄下面的macros檔案,需要重新定義arch 和build_arch為i686。最後,執行命令rpmbuild -ba kernel-2.6.spec --with smp就可以。當然,如果對核心進行了相應的修改,就必鬚生成多個核心RPM包,以適用於多個arch,如kernel-2.4.18-3-i586-smp.rpm, kernel-2.4.18-3-athlon.rpm等。

回頁首

4 作業系統安裝盤的定製過程

你需要將原來作業系統發布盤上的內容拷貝到本機硬碟中,根據有幾張發布盤而產生幾個目錄,比如Fedora Core 2有四張盤,你則需要在系統上產生四個目錄,如disc1、disc2、disc3、disc4,分別將這四張盤上內容拷貝到這四個目錄中,然後對相應的RPM包進行更新。

首先找到你想更新的RPM包,將新的RPM替換舊包。當然你也可以根據你的需要新增或刪除RPM包,需要注意的是,你需要在comps.xml檔案中將新增加或刪除的RPM包名加入某個組件中,並且注意其與其它RPM包的依賴關係,也就是說你所放置的包的位置要恰當,否則它會依賴於在它之前而沒有加入系統的某個RPM包。

4.1 編輯comps.xml檔案

在產生安裝盤之前,需要注意對comps.xml檔案進行修改。這個檔案用來告知安裝程式anaconda,使用者選擇了某個組是應該有哪些包需要安裝,定義了在安裝過程中,包是如何被捆綁在一起的。在Red Hat 8.0以前版本的發布盤中,對應的檔案為comps,它只是一個簡單的文字檔,在Red Hat 8.0之後的版本中,用comps.xml代替了原來的comps檔案。comps.xml是一個XML檔案,易於對內容進行分析和說明。

comps.xml檔案開始是說明xml的版本和DTD斷言,然後進入以<comps>標記開始的檔案的主體內容。如:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd"><comps>

comps.xml主要由三部分組成,首先是組列表,它描述了在安裝過程中需要的不同的組(或組件),包括組名、組的描述和包含的RPM包;其次是組的階層,它將組分成不同的類,並定義了組的一個順序,從而可以決定哪些組需要先安裝;最後為一系列RPM包以及它們之間的依賴關係。

下面分別介紹comps.xml檔案的這三部分:

(1) 組列表

在系統安裝時,需要用到一個組中的一些屬性,下面就是屬性列表以及它們如何使用。一個組被定義在<group>和</group>標記之內.

一個簡單的組定義可以是:

<group>  <id>somegroup</id>  <name>Sample Group</name>  <default>true</default>  <uservisible>false</uservisible>  <description>This is a silly sample group</description>  <packagelist>    <packagereq type="mandatory">bash</packagereq>    <packagereq type="default">cpio</packagereq>  </packagelist></group>

下面分別說明組定義中一些參數的含義:

  • id:組的id僅僅是在comps.xml檔案中作為該組的一個標識,這是必須的;
  • name:表示使用者可以看到的組的名字,它也是必須的;
  • default:它表示在系統安裝過程中,當選擇定製(custom)安裝時,該組是否在預設情況下被選中。如果沒有說明,則預設情況下為不選中。
  • uservisible:它表示該組在預設情況下是否在安裝時可以看到,如果沒有說明,預設設定為YES,為可以看到。
  • description:它表示對該組進行簡短的描述,這是必須的;
  • packagelist:它說明在該組內的一系列安裝包,這也是必須的。
    packagereq:包名
    屬性:
    • type:當進行安裝時,判定對應的包是否是組的"強制"部分、或"預設"部分或"可選"部分。它可以是"mandatory"、"default"或"optional"之一。
    • requires:它說明只有當它所需要(依賴)的包也安裝情況下,此包才安裝進系統。

(2)組階層

它描述了組的樹狀階層,組階層定義在<grouphierarchy>和</grouphierarchy>標記之間,由定義的<category>標記組成類。

一個簡單的組階層可以如下所述:

<grouphierarchy>  <category>    <name>Random Groups</name>    <subcategories>      <subcategory>somegroup</subcategory>    </subcategories>  </category></grouphierarchy>

一個類由下面這些屬性群組成:

  • name: 它表示類名,是必須的;
  • subcategories: 它表示此類的一些子類,由一列表<subcategory>和</subcategory> 元素組成
    • subcategory: 前面定義的組的id

(3)RPM包

此部分說明要安裝的RPM包,它定義在<package>和</package>標記之內。一個簡單的RPM包部分可以如:

<package>  <name>bash</name>  <dependencylist>    <dependency>mktemp</dependency>    <dependency>bash</dependency>    <dependency>glibc</dependency>    <dependency>libtermcap</dependency>  </dependencylist></package>

  • name:它指的是RPM包名,是必須的。
  • dependencylist:它說明此包對應的依賴的RPM包。
    • dependency:此包需要的包的名字

4.2 產生完整的comps.xml檔案

上述說明的comps.xml檔案中的RPM包部分是是自動產生的,為了形成完全的comps.xml檔案,需要在系統中安裝comps-extras RPM包,然後進行下面的操作:

  • 將comps.xml檔案中的原來的RPM包部分刪除;
  • 運行:
    /usr/share/comps-extras/getfullcomps.py comps.xml /path/to/tree arch >/root/filelist在此,/path/to/tree是Red Hat Linux作業系統安裝盤內容儲存的地方,arch指的是體繫結構,為i386。注意的是,假定comps.xml已經存放/path/to/tree/arch/RedHat/base/目錄下,將此輸出重新導向到一個臨時檔案,如/root/filelist。
  • 將comps.xml檔案中最後一行內容(為</comps>)刪除
  • 將前面產生的臨時檔案添加到comps.xml中
  • 再將</comps>添加到comps.xml檔案中

通過新增你的包到comps.xml檔案,你可以根據你的需要做你自己的發布盤,確信你的包在預設情況下會被安裝。需要注意的一件事是你更新的包與其它包的依賴關係,這是你需要處理的,要注意你更新的包所應該放置的位置。另外,不要在檔案中隨意增加或刪除其餘的空格。在修改comps.xml之前,也最好對最初的comps.xml做個備份,以備恢複使用。

4.3 重新編譯安裝程式,調整安裝階段

安裝程式是不可能一次就載入進來的,必須分階段進行,通常我們就稱為"stage"。第一個階段所用程式很小,只有這樣才能從一張磁碟片、tftp伺服器等等上面載入。通常這個階段程式包含的只有一個精簡過的Linux核心和在後續步驟當中必要的一些驅動程式(比如SCSI)。

要採用一個新的RedHat安裝,就會需要很多的映像,最明顯的就是引導安裝盤本身(從軟碟機或者光碟機安裝)的boot.img,但是我們也需要對從硬碟、網路檔案系統等安裝方式提供支援。

RedHat就此提供了很好的指令碼命令,只需一個簡單的操作就可以完成所有的操作。這些指令碼的工作就是把某些RPM包的內容提取出來,然後用來產生各安裝步驟所用程式的映像。

所再強調的是,我們必須保證安裝了anaconda-runtime:

#rpm -i anaconda-runtime-xxxxx-i386.rpm

接著進入目錄/usr/lib/anaconda-runtime,這裡我們會看到一些非常有用的指令碼,比如:

  • mk-images.i386:包涵有建立啟動磁碟時i386的專門設定(通常情況下,網路和pcmcia)以及輔助磁碟驅動程式。在此您可以改變開機映像中所包含的模組,比如說在網路啟動磁碟有:
    ……NETWORKMODULES="$COMMONMODULES nfs 3c59x eepro100 tulip pcnet32ne2k-pci 8139too"……..

  • buildinstall 這是主要的。
    #cd  /usr/lib/anaconda-runtime#./buildinstall ~/disc1/

    這個指令碼命令會在~/disc1/images目錄下更新一些的檔案。

4.4 產生新的hdlist檔案

當安裝時,安裝程式需要依賴光碟片上的Fedora/base/hdlist檔案,它包含的是所有可用的RPM包的必要資訊,這些資訊在安裝過程當中是用來顯示每一個包的用途以及解決使用者選擇軟體包後的依賴性問題。

用以產生hdlist檔案的程式叫做genhdlist,它是由anaconda-runtime這個包產生的。現在的genhdlist多了一個新的參數:--withnumbers,是用來記錄hdlist檔案中每個RPM包的媒介代號。

分步處理的過程如下:

#rpm -i anaconda-runtime-xxxxx-i386.rpm#cd /usr/lib/anaconda-runtime#./genhdlist -- withnumbers ~/disc1  ~/disc2 ~/disc3  ~/disc4

整個過程只需要執行一個指令碼,見附錄一:kernel-update.sh。

如果你在系統中添加了RPM包,那麼在產生安裝盤之前,最好將這四張盤上的內容複寫到一個目錄下,然後修改附錄一的指令檔,運行指令碼,先網路安裝一次,看是否存在包的依賴關係問題。如果沒有,則可以產生安裝盤。

回頁首

5 產生iso映象

當前面系統進行網路安裝成功後,則可以產生iso映象,然後進行刻盤,執行的操作如下:

# build disk 1cd  ~/disc1     /*假設我們將第一張盤的內容放置在此外*/mkisofs -R -J -T -no-emul-boot -boot-load-size 4 -boot-info-table -V fedora     -b isolinux/isolinux.bin  -c isolinux/boot.cat -o /iso/exm-disc1.iso  ./*使用mkisofs工具產生iso映象,將產生的iso映象放在/iso目錄中*/# build disk 2cd  ~/disc2     /*採用同樣的方法,產生第二個iso,依次。*/mkisofs -R -J -T -V fedora -o /iso/exm-disc2.iso .

在產生iso映象之後,需要對它進行測試,你可以將它掛接到某個地方,比如:

mount -o loop /iso/exm1-disc1.iso  /mnt

在產生安裝iso(exm-disc1.iso)之後,我們可以將它複製到windows系統中,採用燒錄程式進行燒錄,然後可以從光碟片安裝,進行安裝測試。

回頁首

附錄一:kernel-update.sh

#!/bin/sh# current working directoryBASE=`pwd`# generate hdlistsmkdir -p $BASE/SOURCESecho   echo Copying disc1 to SOURCES directory, please wait...cp -Rf $BASE/disc1/* $BASE/SOURCES echo Copying disc2 to SOURCES directory, please wait...cp -Rf $BASE/disc2/* $BASE/SOURCESecho Copying disc3 to SOURCES directory, please wait...cp -Rf $BASE/disc3/* $BASE/SOURCESecho Copying disc4 to SOURCES directory, please wait...cp -Rf $BASE/disc4/* $BASE/SOURCESecho   echo Make sure anaconda, anaconda-runtime is installed...rpm -U $BASE/SOURCES/Fedora/RPMS/anaconda-*.rpm# generate hdlists*cd /usr/lib/anaconda-runtime./genhdlist --withnumbers $BASE/disc1 $BASE/disc2 $BASE/disc3  $BASE/disc4# generate the package ordering./pkgorder $BASE/SOURCES i386 |tee /root/pkgorder.txt./buildinstall  --pkgorder /root/pkgorder.txt --version 1 --product "Fedora"    --release "Fedora" $BASE/SOURCES$BASE/SOURCEScp -apRf $BASE/SOURCES/images/* $BASE/disc1/imagescp -apRf $BASE/SOURCES/isolinux/* $BASE/disc1/isolinuxcp -apRf $BASE/SOURCES/RedHat/base/* $BASE/disc1/RedHat/baseecho Cleaning up...rm -rf $BASE/SOURCES
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.