发行版是如何制作的？
yufei兄弟能否讲述一下magic linux的制作过程。你们是在rh上来制作自己的rpm包吗？然后再独立出来，单独安装，是否是这样。然后在这个基础上编译属于ML自己的rpm？是否可以用LFS来制作发行版呢？兄弟如果愿意，是否可以讲讲？ 两位版主这么保守啊，连这个问题都不敢回答吗？还是觉得magiclinux是一个商品，不想让其他兄弟也来制作自己的发行版？ 公社正在组织会议研讨MagicLinux的协同开发问题。如果你感兴趣你可以参加进来。 如果不敢兴趣，也可以去读anaconda的原代码，就什么都明白了。Re: 发行版是如何制作的？
yufei兄弟能否讲述一下magic linux的制作过程。你们是在rh上来制作自己的rpm包吗？然后再独立出来，单独安装，是否是这样。然后在这个基础上编译属于ML自己的rpm？是否可以用LFS来制作发行版呢？兄弟如果愿意，是否可以讲讲？制作一个发行版很容易：
首先你要对Linux有一个了解，从系统管理，服务器配置，性能调整，程序开发等各方面有一定的基础。然后对安装程序，打包处理等有一些基本功，然后就是对代码的修改，和对软件的挑选。
我们现在根本就不需要rh了，因为所有的rpm包完全可以在M上建立，最初的方式试尽可能作一个小的系统，然后构建完整框架,这些工作作完就基本不是rh了。
如果你觉得自己有足够的能力和精力来进行，你完全可以进行一个发行版的开发。
公社的协同开发组织起来之后，自然要跟参与者沟通，但是绝对不会跟组织以外的人讲，首先我想不到讲的理由，其次，我对中国人很有信心，如果你讲了，明天就可以出几十个发行版。 我愿意参与！
97年开始玩linux，半年前想做一个自己用的安装版，一直在收集资料。 How to create a single CD for fast and easy customized installation.
Installing Linux is a relatively easy task. However, I was faced with the task of installing it on multiple machines repeatedly, which is time consuming and prone to errors. This problem affected our whole group and other groups that relied on us. So I started using Red Hat Kickstart to automate the installs. This helped, but there still was room for improvement. What I ultimately wanted was an automated installation that would fit on one CD, dynamically partition the hard drives and contain all of the updated packages. I wanted to be able to start an installation then walk away from the machine, returning only when it was done. To accomplish this, I supplemented Kickstart with a customized version of the Red Hat installation program, Anaconda.
Although not officially supported, Red Hat has made available several tools and documentation to assist in customizing an installation. I describe a few of the possible ways to do this here, which should give the reader enough information to get started.
The following topics are covered in this article: replacing packages with updates, reducing the installation size to fit on one CD, utilizing Kickstart in the custom installation and creating a custom message screen.
The reader should have a good understanding of Linux installations in general. I also assume that no esoteric hardware is being used, as other customizations may be needed to accommodate such hardware.
Setting Up the Build Machine
The first step is to prepare the build computer. Because the installer tools are specific to a particular release, the build computer needs to have the same Red Hat release as the one used on the target(s). For our example, Red Hat 8.0 is being used. There are some differences between Red Hat 8.0 and previous versions, and you need to investigate them if you use a previous version.
Once the build computer has the correct release installed, the Anaconda packages need to be installed. These usually are not installed by default, so they need to be manually installed. They are located on the second CD of the standard Red Hat distribution and are named anaconda, anaconda-runtime and anaconda-help (optional).
The next step is to create a directory structure where the installation files will be located. The partition should have adequate space available, approximately 3GB. The actual location is based on your preference; for this article, the base directory is located at /RH80. Under this directory, we create directories for each of the CDs:
mkdir -p /RH80/CD{1,2,3}
We are not concerned with the source packages, so CD4 and CD5 are not included.
We make an additional directory where we can create the custom installation:
mkdir /RH80/ONE_CD
Now we can copy the contents of the CDs to the respective directories. Mount the first CD, then issue this command:
cp -a /mnt/cdrom/* /RH80/CD1/
Repeat this step for CD2 and CD3.
Copy the contents of the CD directories to the ONE_CD directory, but hard link them instead of actually copying the files. This saves space and is quicker:
cd /RH80
cp -al CD1/* ONE_CD/
cp -al CD{2,3}/RedHat/RPMS/* ONE_CD/RedHat/RPMS/
You'll get an overwrite TRANS.TBL message; you can answer no.
Selecting the Packages
Next we trim down the contents of the ONE_CD directory so it fits on one CD. I assume the CD size to be 700MB. I will not go into detail on how to do this, as the list of files to remove from the distribution is different from one installation to another. However, here are some tips for trimming down the distribution:
* Don't include the source RPMs.
* Remove the dosutils directory, as these will be automated installs.
* Remove any unnecessary packages. This can be complicated, because you need to make sure that the dependencies are still intact.
You should keep a record of the files that were removed. You can use this list in case you need to back out, and you will need it later if you edit the comps.xml file.
For the package selection, I logged to a file all of the base and core group packages with their dependencies (according to the comps.xml file). In order to find this information, I used the script getGroupPkgs.py (see Resources):
cd /RH80/ONE_CD/RedHat/base
getGroupPkgs.py comps.xml > /RH80/pkglist
Any additional package names can be appended to the end of this file. After my list was complete, I removed the packages not on the list by using the syncRpms.py script (see Resources). The arguments are the package directory and the list of packages is generated from getGroupPkgs.py. This script removes the packages not listed in the package list and prints out the package names. We redirect that to a file so we have a log:
cd /RH80
syncRpms.py ONE_CD/RedHat/RPMS/ pkglist > pkgs_rem
We can monitor the installation size by using the du command. The -h option displays the result in human readable format, and the -s option gives a summary of the whole directory tree:
du -hs /RH80/ONE_CD
The hdlist files actually decrease in size after they are regenerated (see below), because we removed many of the packages. This in turn reduces the size of the CD image.
The tricky part about removing packages is they may break dependencies. Even though getGroupPkgs.py resolved the dependencies base on the comps.xml file, they are not guaranteed to be accurate. Adding additional packages may break dependencies as well. One way to verify their accuracy is to create a temporary RPM database, and then do a test install on that database with the packages you have selected:
cd /RH80/ONE_CD/RedHat/RPMS
mkdir /tmp/testdb
rpm --initdb --dbpath /tmp/testdb
rpm --test --dbpath /tmp/testdb -Uvh *.rpm
Look for any error messages regarding failed dependencies. If any appear, resolve the dependencies by either adding or removing files that caused the discrepancy, and repeat the above test.
Once the package dependencies have been resolved, you can download the package updates pertinent for your installation. Put these files under a separate directory:
mkdir -p /RH80/updates/RPMS/
Remove the old files from the build directory and then link the updated files to the build directory. Do this for each updated package (where old_rpmfile is the previous version of the package):
cd /RH80/ONE_CD/RedHat/RPMS/
rm
# ... remove each old rpm
cd /RH80/updates/RPMS/
cp -l
# ... do this for each rpm
You should keep a record of the updated packages, in case you need to back them out. It's also a good idea to check the dependencies and size one more time, in case they changed after the packages were updated.
Next, we check the internal checksum of each package with the -K option to rpm. First we need to import the key:
cd /RH80/ONE_CD/RedHat/RPMS
rpm --import /usr/share/rhn/RPM-GPG-KEY
rpm -K *.rpm | grep "NOT *OK"
This isn't strictly necessary, but because we downloaded package updates, this verifies they are valid.
Preparing the Installation Files
Once all of the packages have been updated, we need to regenerate the hdlist files. They contain only the headers of the packages, which allows Anaconda to retrieve the header information more quickly. Because we updated packages, we need to regenerate these files with the genhdlist tool, which is part of the anaconda-runtime package:
/usr/lib/anaconda-runtime/genhdlist /RH80/ONE_CD/
Next we need to handle the comps.xml file. This file defines package groups and package dependencies (although they are not guaranteed). The file structure was changed in Red Hat 8.0 to be XML-based; in previous releases it was only a simple text file with some obscure tags. We need to ensure that packages defined within groups are included in our installation. We need to be concerned only with groups we are installing. If packages are missing (or if packages were added), we need to edit the comps.xml file (see Resources). Because we chose all of the packages in the Core and Base groups, however, we don't need to edit this file. We simply need to specify those groups under the %packages directive in the Kickstart file. See Listing 1 for an excerpt from the Kickstart file.
Listing 1. Excerpt from the Kickstart File
Technically, we can leave out the @Core and @Base groups, as they are installed by default. They are included here for illustrative purposes.
Creating a Custom Message Screen
We also want to create a custom message screen to give the user special instructions. The message screens are kept in the boot.img file (for CD-ROM installs) under the images directory. This is a DOS filesystem, so we can mount it to get to the contents:
cd /RH80/ONE_CD/images
mount -o loop -t msdos boot.img /mnt/boot
Looking in /mnt/boot, you see six message files: boot.msg, options.msg, general.msg, param.msg, rescue.msg and snake.msg. We create our own message file and call it custom.msg, an arbitrary name. Because snake.msg isn't really used, we replace that entry within syslinux.cfg with custom.msg. Edit syslinux.cfg in /mnt/boot and replace F7 snake.msg with F7 custom.msg.
A few other modifications were made to the syslinux.cfg file; refer to Listing 2. The default entry was changed from linux to ks. If the timeout occurs or if the user presses Enter at the boot prompt, then the ks label is used. Additionally, the timeout value was decreased from 600 to 60, so the installation can start sooner if there is no input from the user. The display entry was changed as well. Instead of boot.msg being the initial message screen, we wanted our custom message to be displayed. For the append line under the ks label, we added two things. The first is the keyword text, to enable text-based installs. Then we changed the keyword ks to ks=cdrom:/ks.cfg. This hard codes the Kickstart location so the user doesn't have to specify it at the boot prompt.
Listing 2. Modified syslinux.cfd File
Next we create our custom.msg file. Listing 3 shows our custom.msg. The contents of the file can be marked up, such as adding color around words. For example, ^O09Custom^O02 changes the color of Custom to blue, and ^O02 changes it back. See the syslinux reference in the Resources section for more information.
Listing 3. Custom Message
Once we have composed the custom message, we need to umount the boot image:
umount /mnt/boot
Building the CD
Before actually creating the CD, you may want to test it by doing a network install. See the Red Hat Kickstart documentation on how to do this.
We want this custom installation to be automated, so we put the Kickstart file on the CD itself. You can create the Kickstart file with any text editor, or you can use the GUI tool called Kickstart Configurator.
In the %pre section, add a shell script to probe the hard drives and dynamically create the partition information based on the number of drives. We take advantage of the fact that Kickstart executes the %pre section and then re-reads the Kickstart file. When it reads it for the second time, it includes the /tmp/partinfo file where the %include directive is located (see Listing 1). The /tmp/partinfo file is the output from the script. We use the list-harddrives command, which lists the available hard drives and their sizes. Having the partition created dynamically frees us from having to create multiple Kickstart files that hard code the partition information.
Once the Kickstart file is created, name it ks.cfg and place it in the root directory of our installation tree (/RH80/ONE_CD/). It is possible to create more than one Kickstart file and place all of them on the CD. Different Kickstart files might address different hardware configurations.
We can now create the ISO image. From our previous steps, the distribution should be small enough to fit on one CD and contain all of the updated packages. The mkisofs program creates the image, and then we can copy the image to the CD. The command to create the ISO image is:
cd /RH80/ONE_CD
mkisofs -r -T -J
-V "My Custom Installation CD"
-b images/boot.img
-c images/boot.cat
-o /RH80/mydist.iso
/RH80/ONE_CD
Refer to Table 1 for a description of the options.
Table 1. Options Used for mkisofs
The last parameter to mkisofs is the source directory of the contents that need to be included in the image file (e.g., our custom installation directory). Several other parameters are available that you may want to use. For example, the -A, -P and -p options add additional labeling information to the image. The -m and -x options also allow you to exclude certain directories and file patterns from the image. See the mkisofs man page for additional information.
Next, add a checksum to the ISO image. This is not strictly necessary, but it provides a way for end users to check the integrity of the CD. The tool to add a checksum to the ISO image is called implantisomd5. To add a checksum to the ISO image, use the following command:
implantisomd5 /RH80/mydist.iso
A companion tool, checkisomd5, can be used to verify the checksum for you:
checkisomd5 /RH80/mydist.iso
The CD also can be verified during the installation. After booting from the CD, the user can issue this command:
linux mediacheck
Now we can burn the image to the CD. I assume the CD writer is already set up on your system. We use cdrecord below, but you can use other programs as well. The command is invoked as:
cdrecord -v speed=4 dev=0,0,0 /RH80/mydist.iso
The speed and dev options depend on your system. The device for the dev argument can be determined by using the -scanbus option to cdrecord:
cdrecord -scanbus
Using the CD
Once the image is burned onto the CD, insert the CD into the target machine and boot the machine. You should get the custom message that you created earlier. At this point, you can either press Enter at the boot prompt or let it timeout. When it times out it uses the default label, which we specified as ks (Kickstart).
If we did everything right, the installation should proceed without user interaction. In my experience, the installation takes approximately ten minutes. This may differ depending on your exact configuration.
Conclusion
With a combination of Kickstart and a customized Anaconda, a powerful and flexible installation can be created. This installation greatly improved cycle time and reduced errors for my project. I was able to install multiple machines, multiple times almost effortlessly. In this article, I touched on only a few ways to take advantage of Kickstart and Anaconda, but there are many other possibilities. I encourage those interested to read the documentation in the Resources section and to join the Kickstart and Anaconda mailing lists for further information.
Re: 发行版是如何制作的？
公社的协同开发组织起来之后，自然要跟参与者沟通，但是绝对不会跟组织以外的人讲，首先我想不到讲的理由，其次，我对中国人很有信心，如果你讲了，明天就可以出几十个发行版。
我有点明白为什么一直以来，我们大陆linux在民间的发展为什么总落后于台湾的原因了(可能现在有些改观了)，我们都喜欢藏私，喜欢分门立派，你搞你的，我干我的。协同开发，这是大家的协同开发，应该是面对所有的人，什么叫组织以外的人？难道我作为一个初学者想了解这方面的知识，就一定要进到组织吗？自己觉得知识应该是share的，大家觉得如何？
希望不要见怪，不对之处还请原谅。
Re: 发行版是如何制作的？
我有点明白为什么一直以来，我们大陆linux在民间的发展为什么总落后于台湾的原因了(可能现在有些改观了)，我们都喜欢藏私，喜欢分门立派，你搞你的，我干我的。协同开发，这是大家的协同开发，应该是面对所有的人，什么叫组织以外的人？难道我作为一个初学者想了解这方面的知识，就一定要进到组织吗？自己觉得知识应该是share的，大家觉得如何？
希望不要见怪，不对之处还请原谅。
我觉得qin_ray老兄说得有道理。
如果你觉得这个是你的辛苦的劳动，需要得到大家的支持与尊敬。我想可以通过别的方式进行保护。但是我反对藏私，这已经违背的linux的开发初衷。更何况众人拾柴火焰高吗？请版主再考虑一下。
得罪之处，请莫见怪。我这人有什么就说什么。不会“藏私”
*^-^* 代码永远是GPL,任何人都可以看到，没有任何问题。
如果你能够参与进来，你可以得到你想要的所有的东西，没有任何条件和代价。
如果要藏私就绝对不会有全部经过修改的SRPMS CD3。
从那里你可以得到Magic Linux修改过的所有的东西。
但是，很多人为什么对关心制作方法而不是参与进来让他作的更好一些或者提交自己的建议和意见？
谁可以回答我这个问题！ 如果开发组'藏私', 又何必公开源代码呢?
和台湾人做比较, 这有点说不过去吧. 台湾人可以很容易地到西方国家(美国, 德国)去, 当然, 很多人只是去旅游, 但同时也意味着可以很方便地学习. 大陆的留学生求学途中很少回国, 而台湾学生很多都在假期回台湾, 虽然这个自身的经济条件有关, 不过这和两地拿到签证的难易程度更有关系吧. 很多台湾学生学完后都会马上回台湾, 中国学生就算回国的, 也要先在美工作了几年, 拿到绿卡后才回国吧(很多人怕回来后很难再出去啊, 这个问题不是出在我们政府身上, 因为我们政府批护照倒是挺快的,难得是签证嘛, 谁叫我们是社会主义国家 :mrgreen: ), 这样两地和西方的学术交流哪个更通畅也可以想象.不是物理界一个得到诺贝尔的李xx回到台湾当了研究院的院长吗?中国大陆没有这样的人吧.
我不是在比较本土的人才和留学回来的, 但人才不是越多越好吗?
另外本来国外玩Linux的人同情台湾的就居多, 所以也不排除私下给他们技术支援的情况. (记得RedHat 前段时间的"国旗事件"吗? 因为RedHat删除了台湾的旗帜, linux论坛上多少人抨击Red Hat为了商业利益而象中国大陆示媚, 在www.linux.com上的论坛, 一个专栏作家就讽刺Red Hat属于"Free World"的一员, 却向一个极权独裁政府示好.)
我说这么多是我离题了, 但我觉得几位因为开发组没有回答如何开发发行版而批评他们'藏私'的'命题'也离题了, 毕竟作为Red Hat, SuSe, Mandrake的注册用户, 并直接向其他unix/linux开发团体(Debian, FreeBSD, OpenBSD, Slackware) 订购的我, 写信去问他们如何制作发行版光盘的话, 我估计他们也会以不是他们服务范围的回答不予理睬, 开发者也许个人有兴趣给我的回信也是让我自己去网上查找. 同时，我再补充两句，制作方法只有一条也就是唯一的一条：静下心来读代码，耐着性子作测试。
所有需要的资料都已经给你了，你还向我们要什么！！？
同时我声明：不要在这个论坛里出现这样的问题了。如果有类似的问题请你打开src自己找答案。我们不在回答类是这样的问题。 同时，我再补充两句，制作方法只有一条也就是唯一的一条：静下心来读代码，耐着性子作测试。
所有需要的资料都已经给你了，你还向我们要什么！！？
同时我声明：不要在这个论坛里出现这样的问题了。如果有类似的问题请你打开src自己找答案。我们不在回答类是这样的问题。
呵呵。我想是我误会了。不过你也误会我了。
有你这个解释。我当然没话说了。
我水平很差。但真的很想参与到你们开发中来。
帮着做文档也行呀。
呵呵。我想是我误会了。不过你也误会我了。
有你这个解释。我当然没话说了。
我水平很差。但真的很想参与到你们开发中来。
帮着做文档也行呀。
等公社定下协作模式，开通协作服务之后，我们欢迎大家都参与进来，共同交流。光靠我们几个，magic肯定坚持不了多久。 代码永远是GPL,任何人都可以看到，没有任何问题。
如果你能够参与进来，你可以得到你想要的所有的东西，没有任何条件和代价。
如果要藏私就绝对不会有全部经过修改的SRPMS CD3。
从那里你可以得到Magic Linux修改过的所有的东西。
但是，很多人为什么对关心制作方法而不是参与进来让他作的更好一些或者提交自己的建议和意见？
谁可以回答我这个问题！
同时，我再补充两句，制作方法只有一条也就是唯一的一条：静下心来读代码，耐着性子作测试。
所有需要的资料都已经给你了，你还向我们要什么！！？
完全同意两位的看法，可能是我一开始就太关心制作方法了，总想知道怎么做出来的，因而忘记了最重要的方面(参与进来让他作的更好一些或者提交自己的建议和意见)。还请不要见怪~~