+ -
当前位置:首页 → 问答吧 → 在i686上做的lfs能用到i586上么?

在i686上做的lfs能用到i586上么?

时间:2008-01-07

来源:互联网

想作个用在pc104上的系统
i586 300Mhz 128MRAM

无奈直接lfs编译太慢

想用
机子A: p4 1.7
or
机子B: cy D 2.66

在cf卡上作lfs,然后插到104上用
可以吗?

不能clfs
原因:找不到手册,下不到cd(上不了外网)....

作者: updavy   发布时间: 2008-01-07

可以的。不过内核编译选项必须对目标机正确。

作者: linux001   发布时间: 2008-01-07

是按 lfs 手册的步骤就可以么?

可是什么时候设置内和参数呢?

看手册中没有设置内核参数阿....

作者: updavy   发布时间: 2008-01-07

如果你使用的 LFS 手册上的方法在 i686 的机器上做 LFS ,这时的 uname -m 为 i686 ,echo $MACHTYPE 为 i686-pc-linux-gnu 。这样的拿到 i586 的机器上是用不了的。

你用 CLFS 的方法吧。
cross-lfs.org/view
如果你要做 Intel/AMD x86 的, i486 / i586 / i686 下载 这手册就可以了:
wget -rcnp cross-lfs.org/view/svn/x86

作者: tfkdmwmqtr   发布时间: 2008-01-08

谢谢:)

svn 是什么?

我手头只有lfs livecd 6.2-5

用这个cd作那种clfs好呢?(clfs应该没有专门的livecd吧)

作者: updavy   发布时间: 2008-01-08

引用:
作者: updavy
谢谢:)

svn 是什么?

我手头只有lfs livecd 6.2-5

用这个cd作那种clfs好呢?(clfs应该没有专门的livecd吧)
svn的就是开发版本。用的是最新的源码包,包括内核(非测试版本)。
这里说的 svn 专指CLFS的手册中的 svn 版本。CLFS中使用的源码包都是正式发布版本,svn版的手册每几天或一星期左右会修改一次。

GNU/Linux发行版:
  Slackware的32位版 , echo $MACHTYPE 输出结果为 i486-xxx-linux-gnu ,uname -m 不记得了。
  openSUSE 的32位版,echo $MACHTYPE 输出结果为 i586-suse-linux-gnu , uname -m 输出为 i686 。
  Fedora 的32位版,echo $MACHTYPE 输出结果为 i386-xxx-linux-gnu , uname -m 输出为 i686 。
所以,我想这里的几种系统架构还是有关系的,虽然我并不清楚什么叫“架构”。
因为我没有 i586 或更老的机器,也无法试验我做的 i686 能不能在 i586 的机器上使用。如果你有兴趣可以试试 i686 的拷贝到 i586的机器上能不能正常运行?

livecd 用 lfslivecd 就可以了,只要满足开发环境的要求。
一般 LFS 或 CLFS 手册的首页都有个 Host System Requirements 的。如果是做CLFS,只要这些开发工具的版本不是过旧或过新的就成。至于主系统的系统架构,以及内核是x86 的32位或64位等均无特别要求。
http://cross-lfs.org/view/svn/x86
http://cross-lfs.org/view/svn/x86/prologue/hostreqs.html

lfslivecd-6.2-5 应该还能够胜任。
你只需要下载手册和需要的文件就可以了:
下载x86手册:
mkdir -v CLFS
wget -rcnp cross-lfs.org/view/svn/x86
读手册:
lynx cross-lfs.org/view/svn/x86/index.html

下载 需要的文件:
http://cross-lfs.org/files/wget/svn
上面这个链接中 all.list 是所有的链接列表(含 x86 , x86_64 , x86_64-64 以及 MIPS 的 32/64bit 等等)。其实,x86 以及 x86_64 ,x86_64-64 和 MIPS 等,他们需要的源码包相差只有几个,差别较多的是补丁(主要用于制作交叉编译环境),所以不妨选all.list一并下载了。

wget -c http://cross-lfs.org/files/wget/svn/all.list
查看这个 all.list
more all.list
备份一份,因为准备修改它,防出错:
cp -av all.list{,_bak}
将 all.list 文件中的所有以 http: 和 ftp 开头的替换为 wget -c http: 或 wget -c ftp:
sed -i 's@http:@wget -c http:@g' all.list
sed -i 's@ftp:@wget -c ftp:@g' all.list
创建存放 svn 软件包的目录
mkdir -v svn
cd svn
sh ../all.list

上面的软件包也可以在 cross-lfs.org/files/packages/svn 中下载到。

另外,gpm这个控制台下的鼠标,需要 linux-headers-2.6.22.6 或更新的内核头文件。而现在的内核头文件是从内核源代码中提取的。
解决,新版本内核头文件gpm编译不通过的问题:
临时换 2.6.22.6 的头文件

在 CLFS 完成基础系统之后,如果需要编译 gpm 可以这样做:
mv -v /usr/include{,_$(uname -r)}
cp -av /usr/include{_$(uname -r),}

安装 linux-headers-2.6.22.6 覆盖 cp -av 的头文件目录:
文件的下载链接在先前版本比如 2.0 中找,或在 cross-lfs.org/files/packages/ 找

wget -c http://cross-lfs.org/files/packages/sysroot-0.0.1/linux-headers-2.6.22.6-09032007.tar.bz2

tar xvf linux-headers-2.6.22.6-09032007.tar.bz
cd linux-headers*

install -dv /usr/include
cp -av include/{asm-generic,linux,mtd,scsi,sound} /usr/include/
cp -av include/asm-i386 /usr/include/asm

如上法安装 2.6.22.6 的内核头文件之后可以编译 gpm 了,编译完gpm这个控制台下的鼠标支持之后,再换回先前的新版本内核头文件:
将现在的改名,后面加上 _2.6.22.6 版本号:
mv -v /usr/include{,_2.6.22.6}
再将先前的改加来:
mv -v /usr/include{_$(uname -r),}

如有软件编译不能通过,仍然可以用较旧的内核头文件,或更旧的。

作者: tfkdmwmqtr   发布时间: 2008-01-08

楼上的这位兄弟看来对lfs还是挺有研究的`~~支持一个,学习了

作者: strangk   发布时间: 2008-01-08

svn 是版本控制程序吧,以前是 cvs 比较流行。一般用 svn 得到的东西,是属于开发中的。

作者: CHII   发布时间: 2008-01-08

引用:
作者: tfkdmwmqtr
svn的就是开发版本。用的是最新的源码包,包括内核(非测试版本)。

GNU/Linux发行版:
  Slackware的32位版 , echo $MACHTYPE 输出结果为 i386-xxx-linux-gnu ,uname -m 不记得了。
  openSUSE 的32位版,echo $MACHTYPE 输出结果为 i586-suse-linux-gnu , uname -m 输出为 i686 。
  Fedora 的32位版,echo $MACHTYPE 输出结果为 i386-xxx-linux-gnu , uname -m 输出为 i686 。
所以,我想这里的几种系统架构还是有关系的,虽然我并不清楚什么叫“架构”。
因为我没有 i586 或更老的机器,也无法试验我做的 i686 能不能在 i586 的机器上使用。如果你有兴趣可以试试 i686 的拷贝到 i586的机器上能不能正常运行?

livecd 用 lfslivecd 就可以了,只要满足开发环境的要求。
一般 LFS 或 CLFS 手册的首页都有个 Host System Requirements 的,只要这些开发工具的版本不是过旧或过新的就成。至于主系统的系统架构,以及内核是x86 的32位或64位等均无特别要求。
http://cross-lfs.org/view/svn/x86
http://cross-lfs.org/view/svn/x86/pr.../hostreqs.html

lfslivecd-6.2-5 应该还能够胜任。
你只需要下载手册和需要的文件就可以了:
下载x86手册:
mkdir -v CLFS
wget -rcnp cross-lfs.org/view/svn/x86
读手册:
lynx cross-lfs.org/view/svn/x86/index.html

下载 需要的文件:
http://cross-lfs.org/files/wget/svn
上面这个链接中 all.list 是所有的链接列表(含 x86 , x86_64 , x86_64-64 以及 MIPS 的 32/64bit 等等)。其实,x86 以及 x86_64 ,x86_64-64 和 MIPS 等,他们需要的源码包相差只有几个,差别较多的是补丁(主要用于制作交叉编译环境),所以不妨选all.list一并下载了。

wget -c http://cross-lfs.org/files/wget/svn/all.list
查看这个 all.list
more all.list
备份一份,因为准备修改它,防出错:
cp -av all.list{,_bak}
将 all.list 文件中的所有以 http: 和 ftp 开头的替换为 wget -c http: 或 wget -c ftp:
sed -i 's@http:@wget -c http:@g' all.list
sed -i 's@ftp:@wget -c ftp:@g' all.list
创建存放 svn 软件包的目录
mkdir -v svn
cd svn
sh ../all.list

上面的软件包也可以在 cross-lfs.org/files/packages/svn 中下载到。

另外,gpm这个控制台下的鼠标,需要 linux-headers-2.6.22.6 或更新的内核头文件。而现在的内核头文件是从内核源代码中提取的。
解决,新版本内核头文件gpm编译不通过的问题:
临时换 2.6.22.6 的头文件
非常感谢!

我想用6.2的livcd尝试一下clfs1.0
毕竟正式版bug少,还有就是自己解决系统问题的能力弱

再次谢谢您的指教

作者: updavy   发布时间: 2008-01-08

引用:
作者: updavy
非常感谢!

我想用6.2的livcd尝试一下clfs1.0
毕竟正式版bug少,还有就是自己解决系统问题的能力弱

再次谢谢您的指教
用 svn 版。CLFS-1.0 太古老了。1.0 和 2.0 的手册可以下载来看看,做系统就不合算了。1.0和2.0的软件包和补丁可以下载备用。
这一期的CLFS的SVN版很顺利的。

作者: tfkdmwmqtr   发布时间: 2008-01-08

CLFS 的 svn 版,有一处补丁打不上,用前一个补丁 readline-5.2-fixes-3.patch 。 在 clfs-sysroot 的手册中有下载链接,所以先前版本的 1.0.0 以及 2.0.0 以及 clfs-sysroot 中的都下载一下。下载的文件放到同一个源码目录中,避免重复下载,浪费磁盘空间。

改:
readline-5.2-fixes-4.patch
readline-5.2-fixes-3.patch

下载:
http://svn.cross-lfs.org/svn/repos/cross-lfs/branches/clfs-sysroot/patches/readline-5.2-fixes-3.patch

作者: tfkdmwmqtr   发布时间: 2008-01-08

引用:
作者: tfkdmwmqtr
CLFS 的 svn 版,有一处补丁打不上,用前一个补丁 readline-5.2-fixes-3.patch 。 在 clfs-sysroot 的手册中有下载链接,所以先前版本的 1.0.0 以及 2.0.0 以及 clfs-sysroot 中的都下载一下。下载的文件放到同一个源码目录中,避免重复下载,浪费磁盘空间。

改:
readline-5.2-fixes-4.patch
readline-5.2-fixes-3.patch

下载:
http://svn.cross-lfs.org/svn/repos/c...-fixes-3.patch
我先从clfs1.0开始了....
还是很感谢你

发现clfs1.0的手册中没有指定SBU

刚刚测试了一下 编译 cross binutils 耗时7min
而编cros gcc static 的时间却是17分钟

不知道是否正常....

作者: updavy   发布时间: 2008-01-09

正常的。
只要保证把手册看懂就没问题。

作者: tfkdmwmqtr   发布时间: 2008-01-09

引用:
作者: tfkdmwmqtr
正常的。
只要保证把手册看懂就没问题。
clfs1.0.0编译到第十章 安装基本系统了

glibc 的测试 无异常

刚刚编译binutils make check 的时候有几处错误

===========ld summary ==============
# of expected passes 271
#of unexpected failures 1
#of expected failures 4
/sources/binutils-build/ld/ld-new 2.17

make [4]: *** [check-DEJAGNU] Error 1
make[3]: *** [check-am] Error 2
make [2]: *** [check-recursive] Error 1
make [1]: *** [check-ld] Error 2
make: *** [do-check] Error 2

这个unexpected failures 正常么?
不知道能不能继续进行下去

可以继续安装
不知道后面会不会有影响..

作者: updavy   发布时间: 2008-01-10

没关系。
看手册上怎么说的, check 是会有一些错误提示的。
通常都跳过 check 和 test ,浪费时间。就是提示check有错,难道就不能用了?就是提示 check 有错难道就重新来过?这显然是不应该的。所以跳过 check ,如果你明白 check 是干嘛,或者说知道 check 的必要性,大可以去 check 。因为我不懂程序,不会编程,没有必须 check 的理由,所以我跳过 check 。

作者: tfkdmwmqtr   发布时间: 2008-01-10

引用:
作者: tfkdmwmqtr
没关系。
看手册上怎么说的, check 是会有一些错误提示的。
通常都跳过 check 和 test ,浪费时间。就是提示check有错,难道就不能用了?就是提示 check 有错难道就重新来过?这显然是不应该的。所以跳过 check ,如果你明白 check 是干嘛,或者说知道 check 的必要性,大可以去 check 。因为我不懂程序,不会编程,没有必须 check 的理由,所以我跳过 check 。
手册上强烈要求check
又没有详细的errors list
尴尬,

glibc binutils gcc 的check分别用了35 7 157 min
特别是gcc太长了....

还好,就是binuitils 的check有点小情况,其他两个没有提示好多error

作者: updavy   发布时间: 2008-01-11

接下来的40多个软件包都要装,还真是麻烦

有些包不是启动必需的吧

怎么精简一下呢?


看了第一个dependency,感觉很奇怪

Autoconf
Installation depends on: Bash, Coreutils, Grep, M4, Make, Perl, Sed and Texinfo
Test suite depends on: Automake, Diffutils, Findutils, GCC and Libtool
Must be installed before: Automake

怎么会需要perl呢!!主要不想装类似perl这样的东西,感觉用不上

想用dependency中的 must be installede before 选项来自己去掉一些包,不知道可行不

作者: updavy   发布时间: 2008-01-11

安装一次就够费时间的了,还要去做check,太不值得了。
又不是要给公司用,不需要那么严谨。

我也不想装perl,但别人的要用,就没办法不装了。

作者: sofire   发布时间: 2008-01-11

系统放到pc104上主要是跑c程序

可是看dependency的话

找来找去可以去掉的只有texinfo (man要时常看看,tar gzip bzip2打包解包,其他的不是库就是系统相关....),不过ms kbd 和 gawk 没啥用,也没有包依赖他们,

最可气的是perl....,autoconf要依赖它,尽管不清楚autoconf怎么用,还是想装它 shadow 也可以去掉吧

达人给分析分析能省略什么包

作者: updavy   发布时间: 2008-01-11

look at ' if you are going to boot '

作者: tfkdmwmqtr   发布时间: 2008-01-11

引用:
作者: tfkdmwmqtr
look at ' if you are going to boot '
The boot method is needed when you are building on a different architecture. For example, if you are building a
PowerPC system from an x86, you can't chroot. The chroot method is for when you are building on the same
architecture. If you are building on, and for, an x86 system, you can simply chroot. The rule of thumb here is if
the architectures match and you are running the same series kernel you can just chroot. If you aren't running the
same series kernel, or are wanting to run a different ABI, you will need to use the boot option.

对于这段我的理解是如果前面的CLFS-HOST CLFS-TARGET 不都是x86的话 下面的chroot命令就不能执行 只能再在 /tools以及$CLFS下 建立一些启动的必须工具然后把$CLFS下的所有文件打包安装到目标机器上再进行其他软件的编译

很多疑问:
首先,要是host 跟 target结构不同,going to boot 之后根据手册顺序执行,所有的第五部分的9 10两章的软件岂不是都要在目标机器上进行编译,那编译时间非常人能忍受
第二,第七章中going to boot 中已经安装的包(zlib e2fsprogs sysvinit udev etc.) 在第十章中不用再安装了吧?
第三,/tools下面的工具是用/cross-tools下面的工具编译的吧?(猜测,不知道要到什么地方能看到clfs的原理,我现在能理解到的只是/croos-tool下面的编译工具是用宿主机的编译工具编译的; 然后用export PATH=/croos-tools:/bin:/usr/bin 屏蔽了宿主机PATH下的同名工具,再用export CC=$CLFS_TARGET-gcc" 这样的命令设定 building basic tools时使用的编译工具的类型)既然going to boot时编译的工具能在宿主机上直接使用,那为什么不用/cross-tools下的工具直接编译出目标系统的标准文件结构,还要经过building basic tools这个中间过程呢?(going to boot 和 building basic tools 两部分的编译环境是一样的阿,为什么不把/tools 下的basic tools 直接编译到$CLFS中呢?)

作者: updavy   发布时间: 2008-01-11

如果,目标系统的 target (系统架构)与host的不一样,host如果想 chroot 到 目标系统,必須要内核同时支持 host 和目标系统的 target (系统架构)。
比如,我的 i686 现在的 uname -m 是 i686 ,而 目标系统是 x86_64-64 ( 纯64位单一的库),此时是不可以的。但是,我用 x86_64 的内核启动 i686 的系统之后,是可以 chroot 到 x86_64-64 的。因为, x86_64 的内核是向下兼容的,支持 i386 / i486 / i586 / i686 / x86_64 。
所以,关键的还在内核。
如果你的主系统的 echo $MACHTYPE 是 x86 ( i386 / i486 / i586 / i686 ) ,你的目标系统是 x86_64 ,你想 chroot 到目标系统内核需要同时支持 host 和 目标系统。否则只能 to boot 。
你要做的是 i586 应该是不受此限的。总之,你先备份你的 工具链( cross-tools 和 tools )。后面的目标系统具有实验性质了。我没有做过 i586 ,所以不敢说我说的一定对。i686 的内核在 i586上是否也能用?这个得用了才知道,要不你问下弄服务器的有没有在 i386 机器的上用的 kernel 的 uname -m 是 i686 的?我见的x86,32位发行版的 uname -m 都是 i686 是这样,但没有在i386 / i486 / i586 的机器上用过。

tar -jcvf clfs-version-target-cross_tools-tools.tar.bz2 ${CLFS}/{cross-,}tools

昨天开了 vmware 虚拟机6.0 ,不知乍的,主系统linux的键盘就不太好使了。所以敲不了中文。
我让你看 if you ar going to boot ,只是想让你知道使系统能够启动需要一些什么,或者说是从中得到一些启发。当然,还可以再继续精简。
shadow完全可以不要。 /etc/passwd 以及 /etc/group 也不属于 shadow 。
uotomake 和 uotoconf 在编译有些软件的时候需要。

另外,我曾经发过关于编译 x86_64-Multilib 的帖子。实际上,问题很多的,十分的麻烦。所以,多媒体娱乐用桌面系统还是 x86 了( i686 以上的机器用 i686 )。
我现在在用 x86_64-64 , 也就是 Pure64 (纯64的单一的库)学着配服务。只用开源软件。
那些商业的软件,以及企业级应用的,暂时还不想烦。要学就用发行版好了。

作者: tfkdmwmqtr   发布时间: 2008-01-11

[QUTE]引用 楼主:
---------------------------------------------------------
第二,第七章中going to boot 中已经安装的包(zlib e2fsprogs sysvinit udev etc.) 在第十章中不用再安装了吧?
[/QUTE]


going to boot 中已安装的包,主要的作用是使其能引导。在 if you are going to boot 中的编译内核之后就可以了。这样就具备了能启动并有一些最最基本的命令。详情看手册上讲了哪个软件包是做什么的,都安装了什么样的命令。
going to boot中安装的包,如果编译的方法和之后的手册上的构架目标系统的编译方法不一样,或者说有些功能没有编译进去,有些程序文件或库文件没有被安装,是需要重编译覆盖的。这个自己对比一下就可以了。

[QUTE]
引用 :
-------------------------------------------

第三,/tools下面的工具是用/cross-tools下面的工具编译的吧?(猜测,不知道要到什么地方能看到clfs的原理,我现在能理解到的只是 /croos-tool下面的编译工具是用宿主机的编译工具编译的; 然后用export PATH=/croos-tools:/bin:/usr/bin 屏蔽了宿主机PATH下的同名工具,再用export CC=$CLFS_TARGET-gcc" 这样的命令设定 building basic tools时使用的编译工具的类型)既然going to boot时编译的工具能在宿主机上直接使用,那为什么不用/cross-tools下的工具直接编译出目标系统的标准文件结构,还要经过building basic tools这个中间过程呢?(going to boot 和 building basic tools 两部分的编译环境是一样的阿,为什么不把/tools 下的basic tools 直接编译到$CLFS中呢?)[/QUTE]


编译的原理看精华帖。
if you are going to boot 的时候不将目标的编译出来:一个是因为, going to boot 的目的已经达到,无須更多琐碎。另外,可能是为了保持CLFS手册的统一性。 going to boot 了之后怎么办?当然是继续 compile 编译喽,想安装啥就安装啥,多灵活?如果要不 chroot 就将目标系统的其它软件都编译出来,编译需要修改的参数不是每个软件包都是修改的一样的,有些可能要加好多参数,麻烦还增加出错的可能。

clfs-sysroot 做这个事情很好。但是 clfs-sysroot 的软件包总是比较落后的。而且,暂时 clfs-sysroot 所涉及的范围不广,手册上目前只有编译 Non-Multilib 单一的库,而不能多库。当然,你的 x86 也是可以 clfs-sysroot 的。你需要做的只是在 target 的时候设置一下,你要编译的是何种系统架构。

CLFS的玩法太多,也较LFS更能学到东西。就是这“十八般武艺” 要学通了,耗时太多。我用了八个月的时间学通了 LFS 以及 CLFS ,我以我做过CLFS的次数通晓了CLFS的过程和精髓。

作者: tfkdmwmqtr   发布时间: 2008-01-11

CLFS 内容确实很复杂

原理,编译过程参数设定,不经过几次,数种clfs真的较难吃透

毕竟现在只是作了LFS6.2的一半,然后因为目标586上的编译速度慢才转clfs,有些问题还得不断像达人们请教才行

我初见clfs 就觉得lfs貌似是clfs的一个子集。
但现在看来觉得一般clfs是在比较快的机子上编译比较慢的机子上的东西,可是going to root 这种方法还需要在目标机器上编译第9 10 两章的内容的话,节省的时间就比较有限了,毕竟 还需要编译glibc gcc binutils etc 这些大头

作者: updavy   发布时间: 2008-01-11

引用:
作者: updavy
CLFS 内容确实很复杂

原理,编译过程参数设定,不经过几次,数种clfs真的较难吃透

毕竟现在只是作了LFS6.2的一半,然后因为目标586上的编译速度慢才转clfs,有些问题还得不断像达人们请教才行

我初见clfs 就觉得lfs貌似是clfs的一个子集。
但现在看来觉得一般clfs是在比较快的机子上编译比较慢的机子上的东西,可是going to root 这种方法还需要在目标机器上编译第9 10 两章的内容的话,节省的时间就比较有限了,毕竟 还需要编译glibc gcc binutils etc 这些大头
我候,你要在 i686 中编译 i586 不必 going to boot 。
chroot 应该是可以的。
但是,我不知道 i586 的编译出来的 uname -m 是不是 i586 。如果是 i686 呢?内核是 i686 应该也可以在 i586 的处理器的机器上用,我想是这样。因为一般的32位的GNU/Linux发行版它的应用软件可能不是 i686 ,可能是 i386 或 i486 或 i586 ,这样照顾了那些用老机器做服务器的人。而它的内核用 i686 的,照样可能是能够在 i386 上用的。
但是,我看了clfs手册的 if you are going to boot 在编译内核的时候有一段:

make ARCH=i386 CROSS_COMPILE=${CLFS_TARGET}- menuconfig


很明显,这里的 ${CLFS_TARGET} 还是有一定的作用的。或许这样能使软件运行得更好?

作者: tfkdmwmqtr   发布时间: 2008-01-11

由于,我没有做过 i586,没有将要准备去做 i586 的需要 ,也没有这样的硬件。所以,可能会有一些我没能及时想到的问题。
这样,我就指挥下:
两种方法,你都尝试一下。看哪个更好?

检查两种方法的 uname -m 和 echo $MACHTYPE 。uname -m 由内核的系统架构决定, echo $MACHTYPE 部分由C编译器。由于我对编译原理也不是很了解,所以我的说法可能也会有错误。
你先按 going to boot 的方法让系统能够启动,然后重启机器查看上面说到的 uname -m 和 echo $MACHTYPE ,记录下来。必要时做系统备份。


已知的问题是 x86_64 的 内核, chroot 到 x86 的目标系统,编译会出错。需要指定 target 才成,可能还需要指定cc。BLFS或CBLFS中的有些软件不一定有 target 之类的参数,这就需要改源码,终究是麻烦,而且是原来不必要的麻烦。
i586 的C编译器,i686的内核,编译出的软件可能不是 i586 ,有可能是 i686 。
LFS 不正好是说明了这个道理吗?
lfslivecd-x86 的LiveCD,系统的软件都是按照 i486 编译的,内核分32位和64位两种。LFS的方法用lfslivecd-x86在32位内核在 i686以上的机器上编译出来的软件是 i686 的。

作者: tfkdmwmqtr   发布时间: 2008-01-11

最简单的就是运行一下目标架构的文件。就知道是否需要重启了啊。:)。

作者: 晨想   发布时间: 2008-01-13

引用:
作者: 晨想
最简单的就是运行一下目标架构的文件。就知道是否需要重启了啊。:)。
恩,运行一下目标系统的文件证明当前内核支持chroot

几天断断续续的终于做完了clfs1.0

安装grub
创建menu.lst

重启失败

结果如下

Booting command-list

root (hd0,1)
Filesystem bype is ext2fs, partition type 0x83
kernel /boot/clfskernel-2.6.17.13 root=/dev/hdc2
[linux-bzImage,setup=0x1c00,size=0x16f75a]
Uncompressing Linux... OK,booting the kernel

然后就没有动静了

pc104上cf卡被识别为hdc
分区
/dev/hdc1 swap
/dev/hdc2 /
/dev/hdc3 一个存储分区

作者: updavy   发布时间: 2008-01-17

疑问:

1. pc104上 CF 卡被识别为 hdc?这是在 CLFS 的制作过程宿主系统识别的还是。。。?

2. 你完成的 CLFS-1.0 是用 boot 还是 chroot 进行?貌似是 chroot 的?

作者: d00m3d   发布时间: 2008-01-17

引用:
作者: d00m3d
疑问:

1. pc104上 CF 卡被识别为 hdc?这是在 CLFS 的制作过程宿主系统识别的还是。。。?

2. 你完成的 CLFS-1.0 是用 boot 还是 chroot 进行?貌似是 chroot 的?
宿主系统是 p4 i686
目标系统是pc104 i586

cf 卡当作硬盘用,被pc104识别为hdc

clfs是chroot完成的

作者: updavy   发布时间: 2008-01-17

还是不明白 CF 卡是透过什麽途径被认成 hdc,系统里还有别的硬盘吗?

到底 pc104 是啥玩意?

作者: d00m3d   发布时间: 2008-01-17

楼主新手哦,想必你是用读卡器写cf吧,你用liveCD引导的时候,这时cf卡是被认做scsi的,当你用在pc104的时候,cf卡是IDE设备,做系统的时候注意哦

作者: sspipipipi   发布时间: 2008-01-18

引用:
作者: d00m3d
还是不明白 CF 卡是透过什麽途径被认成 hdc,系统里还有别的硬盘吗?

到底 pc104 是啥玩意?
pc104是一种紧凑型兼容pc的工控机

我手头的这个配置是
CPU:cyrix MediaGX with MMX-S CPU at 300Mhz
RAM: 128M
CF 卡插槽可插CF卡当作硬盘

另外可外接光驱显示器键盘鼠标

我想在上面装个linux操作系统
曾经在上面直接用光驱装过debian etch 感觉 发行版启动太慢

很偶然的发现了LFS 就走上了不归路.....

开始不知道CLFS 直接在PC104上面做LFS 6.2
哪知奇慢无比,一个SBU 1hour....
尴尬,无奈,正欲放弃时发现了clfs
感觉比LFS原理上要复杂一层,而且ms可以大幅度削减sbu
于是就停止了进行到中途的lfs开始clfs
也正是在作了一半的lfs中发现 pc104的u是i586 而我pc机是p4
所以才产生了这个主题

作者: updavy   发布时间: 2008-01-19

引用:
作者: sspipipipi
楼主新手哦,想必你是用读卡器写cf吧,你用liveCD引导的时候,这时cf卡是被认做scsi的,当你用在pc104的时候,cf卡是IDE设备,做系统的时候注意哦
确实如此

我用一个p4 的机器启动LFS 6.2 的livecd启动 然后用cf读卡器接cf卡

p4机识别cf卡为sda1 (swap) sda2 (/) sda3 存储clfs包

目前以完成clfs手册
重启时遇到问题

作者: updavy   发布时间: 2008-01-20

也就是设备的辨认问题了

作者: d00m3d   发布时间: 2008-01-20

引用:
作者: d00m3d
也就是设备的辨认问题了
上面说的是在pc104上重启失败


VFS: Cannot open root device "hdc2" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing:VFS: Unable to mount root fs on unknown-block(0,0)

我觉得是ide cf卡的驱动没有编译好,可是我不知道内核选项里哪个是支持ide cf 的驱动....

作者: updavy   发布时间: 2008-01-20

尝试 使用ubuntu 710 现成的内核启动pc104

将 ubuntu 710 的 vmlinuz system.map 拷到cf卡上的/boot 分区

menu.lst
加入root kernel 两句时仍然提示 Kernel panic - not syncing:VFS: Unable to mount root fs on unknown-block(0,0)

再将ubuntu的initrd拷到cf卡的/boot 下面,menu.lst 里面添加上initrd句时 启动成功了
只是速度比较慢
是不是因为没有initrd 这一句才找不到root fs
clfs过程中怎样生成initrd.img文件??

谢谢

作者: updavy   发布时间: 2008-01-20

非也!还没有搞懂吗?

你用 Ubuntu 的 initrd 能起动是因为它起动时加入了相关内核的支持来进行二次引导,如果你的 initrd 没有相关的支持,就是做了 initrd 也同样不能起动!

建议你看看它的 initrd 里哪些是你自己编译的内核没有的,重编内核便行。

作者: d00m3d   发布时间: 2008-01-20

引用:
作者: d00m3d
非也!还没有搞懂吗?

你用 Ubuntu 的 initrd 能起动是因为它起动时加入了相关内核的支持来进行二次引导,如果你的 initrd 没有相关的支持,就是做了 initrd 也同样不能起动!

建议你看看它的 initrd 里哪些是你自己编译的内核没有的,重编内核便行。
明白了
initrd不是启动引导必需的
只是发行版为了应付不同的硬件环境采取的应急措施,第二次引导就是动态的加载引导过程中必需模块,以防万一(对不?)

从网上找了个方法解开了initrd文件

但是要从initrd.img 文件的模块反推出内核编译时的选项,对我来说还是太难

我还是找点内核编译配置的介绍去挨个试吧

哪位大虾比较熟悉CF卡true ide模式的内核编译,给指个路吧,
要是明确的指出menuconfig 的选项就最好不过了阿

不胜感激

作者: updavy   发布时间: 2008-01-20

没用过这样的设备。
把CF卡接上,在使用硬盘或光盘上的系统启动机器。
lspci
lsmod

研究下。
之后好在内核中定位或估计、猜测相应的选项。

作者: tfkdmwmqtr   发布时间: 2008-01-21

引用:
作者: updavy
明白了
initrd不是启动引导必需的
只是发行版为了应付不同的硬件环境采取的应急措施,第二次引导就是动态的加载引导过程中必需模块,以防万一(对不?)

从网上找了个方法解开了initrd文件

但是要从initrd.img 文件的模块反推出内核编译时的选项,对我来说还是太难

我还是找点内核编译配置的介绍去挨个试吧

哪位大虾比较熟悉CF卡true ide模式的内核编译,给指个路吧,
要是明确的指出menuconfig 的选项就最好不过了阿

不胜感激
我不知道 UB 下的 initrd 是如何制作的,估计它跟 Debian 差不多吧,试把 initrd.img 用 gzip 解压,然後把解压出来的文件用 loop 方式把它挂载再看看它的内容

作者: d00m3d   发布时间: 2008-01-22

引用:
作者: d00m3d
我不知道 UB 下的 initrd 是如何制作的,估计它跟 Debian 差不多吧,试把 initrd.img 用 gzip 解压,然後把解压出来的文件用 loop 方式把它挂载再看看它的内容
我是mv inird.img inird.img.gz
gunzip inird.img.gz
这时候文件还是原来的名字
然后mount -o loop inird.img initrd/
提示需要指定文件类型

root@Davy-desktop:/home# file initrd.img-2.6.22-14-generic
initrd.img-2.6.22-14-generic: ASCII cpio archive (SVR4 with no CRC)

尝试了 ascii cpio auto 都不可以...应该是哪种呢?

作者: updavy   发布时间: 2008-01-22

引用:
作者: updavy
我是mv inird.img inird.img.gz
gunzip inird.img.gz
这时候文件还是原来的名字
然后mount -o loop inird.img initrd/
提示需要指定文件类型

root@Davy-desktop:/home# file initrd.img-2.6.22-14-generic
initrd.img-2.6.22-14-generic: ASCII cpio archive (SVR4 with no CRC)

尝试了 ascii cpio auto 都不可以...应该是哪种呢?
找到了


[root@printserver test]# mkdir new
[root@printserver test]# cd new/
[root@printserver new]# gzip -dc ../initrd-2.6.9-11.19AX.img | cpio -idvm

作者: updavy   发布时间: 2008-01-22

楼主,我提醒你了,可是看来你没有搞定CF卡啊。最简单的办法,把你的CLFS弄到一块IDE硬盘上,启动你的pc104,然后再把系统挪到CF卡上,这个时候就不存在CF卡的scsi和ide的问题了

作者: sspipipipi   发布时间: 2008-01-24

引用:
作者: d00m3d
还是不明白 CF 卡是透过什麽途径被认成 hdc,系统里还有别的硬盘吗?

到底 pc104 是啥玩意?
pc104严格的讲不是说的机型,而是一种总线,是pc机上ISA总线的改进版,其实它的电气信号跟ISA一摸一样,仅仅是改变了ISA的机械结构而已,不再是ISA那种槽子,而是一堆的针孔,而且可以一层一层往上叠加。这种板子常见的cpu是AMD的Geode系列的cpu(更老的还有NSC的),比如GX1什么的。这种嵌入式板子的结构跟pc没多大差别,可以说是一样的,区别仅仅是没有显卡,显示的任务被cpu代劳了,多了一个pio口(一个可编程IO口),感觉跟单片机的IO一样,它输出的就是ttl电平。
这种板子对CF卡的存取用的是CF-to-IDE机制,直接把CF当硬盘使了。

作者: sspipipipi   发布时间: 2008-01-24