我原来的系统是lfs8.3，可以参看另一个帖子。然后这几天出了lfs9.1 rc1 测试版本，就想试试更新一下。
我的做法是升级原系统，而不是开一个全新的分区又重新编一次9.1，感觉这样子效率比较低，总不能每次升级我就从头开始编，然后又重新编一个桌面吧，这种做法虽然最彻底，但是也太折腾了。所以我这次要改一下，采用滚动升级模式。

滚动升级需要了解一下LFS的相关知识，最核心的就是工具链，和交叉编译的一些知识。看起来很恐怖，其实一点都不难。到实际应用时的做法更是简单得不能再简单。但是首先要会，然后才能不容易出错的。下面就来说一下。

现在先做一下常规操作，就是完全从零开始按LFS的操作：
1、开新分区和挂载，做为新的LFS的根目录位置，这是LINUX的基础知识自不必说，如果新人不太清楚的话，建议在一个发行版上多搞几次就明白了。这部分在手册的第2章：Preparing the Host System。
2、建立临时工具包，这个就是非常核心的部分了，在手册的第4和5章。在第4章Final Preparations，我们可以看到它建立了临时的变量LFS等，最核心的变量设置是/tools -> $LFS/tools，这里是非常有技巧的，也是挡在众多LFS新手前的第一道坎，比较难理解。（10年前我搞LFS时也在这困住了很长时间）它的技巧在于，成功地“欺骗了”工具链。我们可以看到，后面的工具链安装时，位置都会选择“/tools”，实际上是装在了“$LFS/tools”位置下，但是，你不可以“老实”地写成“$LFS/tools”，因为后面会有一个chroot切换根目录的操作，这样的写法就无法成功“欺骗”工具链，用前面的写法就可以，因为后面切根目录的时候，是以$LFS为根目录的，原来的“$LFS/tools”位置，就非常恰好地成为了 “/tools”，这里就巧妙地形成了一致！（真的很佩服工作组大佬们的思路！）
3、第4-5章的临时工具包编译好后，采用切换根目录的方法，进入临时的独立系统，用临时工具包编译出整个完整的LFS系统，这是第6章的内容。这里面最难的部分就是工具链的调整。因为上面我们提到了，工具包的工具链，指向是“/tools”，第6章要调整为指向"/"，也就是根目录。这里面采用了一些技巧，等下再细说。
4、第7-8章就是对第6章编译好的系统，再进行一些细节的设置，比如启动脚本、界面、设置网络，比如增加新用户等等。这段比较核心的是编译内核，再把内核放到“/boot”下面，并调整启动菜单，从而能够成功启动。
5、成功启动后，LFS的全部工作就已经完成了。这时候的系统是TTY界面的命令行系统，这个系统有着基础的功能，可以让你学一下LINUX的命令行，比如玩玩sed、find、shell脚本什么的，同时也有着最强大的功能：编译！只要有源代码，就没有这个系统编译不了的！这甚至是很多发行版都无法正常做到的！至于这时候用来当服务器还是用于桌面还是当个玩具显摆，就是各用户的事情了，这是BLFS手册的内容了。

下面说一下工具链，以及如何调整它，达到我们所说的老版本滚动升级的目的。
核心工具链的软件包有3个，加上头文件，共4个，这4个是核心中的核心，不能出任何问题的。
1、先说简单的，内核头文件，这是用来与内核对话的接口，如果改动，那么这个系统很可能就要重做，不然很容易崩溃。现在我们需要从LFS8.3使用的内核4.20.10的头文件，升级到现在的5.5.3的头文件。那么按照手册的要求做就可以了的。记住，当第6章6.7. Linux-5.5.3 API Headers中，你将头文件安装到原有的LFS系统后，原系统就已经不可用了（其实也不是完全不可用，但是核心的工具包，比如GCC，已经不能用了。）
2、工具链第一个包，binutils，里面核心的是ld，这是一个指针，指向编译时的库位置，这是非常重要的，也是我们调整工具链的重要切入点。在手册中，它有时指向'/tools/lib',有时又指向'/lib'，这需要我们随时保持清醒的头脑，不可以犯错，否则前功尽弃。
3、工具链第二个包，gcc，这个大家应该比较熟悉了，是编译器。没这个东西就编译不了软件了。它编译时会看ld指向的包，同时，它自己也有一个指向的设置，会写在gcc/config/linux.h, gcc/config/i386/linux.h, gcc/config/i368/linux64.h 文件中，这点大家不用担心，因为手册会用一个sed命令改掉，怎么做都写有了。在第6.10 Adjusting the Toolchain中，还会有一个sed命令调整gcc,就是在他的文件库中生成一个specs文件，定位所使用的库，这些手册中都有命令，大家不用担心，主要是原理上要明白，这样就不会犯错误。
4、工具链第三个包，glibc，这个是C库，也是所有，记得，是“所有”，软件所访问的库，因此它的重要性自不用说。手册中也说，LFS系统在更新相关软件时最好不要更新这个glibc，不然很可能会出问题，只能重构系统。原因就是它的版本如果升高了，可能会导致一些软件版本太低从而不能正常使用。它和内核头文件是对应绑定的，可以看成一个整体来对待。
下面讲工具链的指向和调整过程。

这里讲工具链的指针变化过程，先看第5章
1、如前面我们所说的，可以看到，第５章，5.4. Binutils-2.34 - Pass 1中，工具链的指向是‘/tools’，实际上是‘$LFS/tools’，这里是通过‘--prefix=/tools --with-sysroot=$LFS --with-lib-path=/tools/lib’实现的。也就是做好5.4后，ld指向‘/tools’。
2、5.5. GCC-9.2.0 - Pass 1中，通过一系列的命令，查找、并用sed进行了调整，gcc指向‘/tools’。
3、5.6. Linux-5.5.3 API Headers中，头文件直接就装在了‘/tools/include’下。
4、5.7. Glibc-2.31中，通过--with-headers=/tools/include，明确指向了头文件的位置，此时新的库文件也是指向‘/tools’的。
通过以上几步，所有的工具链核心，都指向了'/tools'，为打造一个完整的临时工具包打下了基础。
5、注意！！5.9. Binutils-2.34- Pass 2中，有一个非常重要的技巧，在最后的阶段，会单独地生成一个ld-new，这个是指向'/'的！这里要特别注意，然后在后面第6章会有一个替换的过程，从而巧妙地将指向‘/tools’的ld，替换成这个指向'/'的ld-new，从而达到调整的目的。

然后看第6章
1、第6章上来就直接安装了头文件，6.7. Linux-5.5.3 API Headers，从原来装在'/tools/include'下，改为直接装在了'/usr/include'下，这时候，头文件已经安装到了最终的位置。头文件的调整一步到位直接完成。
2、6.9. Glibc-2.31，直接搞定C库，前面说了C库和头文件是一个整体，这里就看出来了。通过
'--with-headers=/usr/include libc_cv_slibdir=/lib'参数直接指定了最终的位置。
3、6.10. Adjusting the Toolchain这里是第6章中非常重要的一节，如上面所说，这里进行了ld的调整，把原来指向'tools' 的ld,改成了ld-old,同时将指向'/'的ld-new，替换为ld,至此完成了ld的正确指向！这节同时进行了GCC的指向调整，通过gcc -dumpspecs命令，生成了 GCC specs文件，将GCC的指针强行指向了最终的位置。
4、6.25. GCC-9.2.0中，将工具链的最终一环，GCC，进行了最终的安装，但是，GCC的指向，并不是在这里调整的，是在上面，6.10中已经调整好了，大家要注意这点。这个节只是负责安装好GCC而已，安装好的GCC，已经自动指向了
正确的
位置。
好了，下面讲滚动升级，如何利用技巧实现。（这个技巧非常非常简单！！）

这里再讲讲一个重要的参数:PATH
这是很多初玩LFS的新手踩雷的地方，很多人不知道这个是做什么的，或者对此不重视，从而导致失败，比如我
这可以说是LFS里面，非常重要又容易被忽视的参数！
PATH是干什么的？就是让系统在指定位置找可执行文件的，或者说，就是一个指针！因此，正确定义好它非常非常非常重要！（说三遍！）也就是说，去哪里找ld,去哪里找gcc,全在这里定义！你既可以通过这个，找新编译出来的ld和gcc软件，也可以通过修改这个，找其他特定的ld和gcc!说到这里不知道大家明白了吧？滚动升级能否成功，其实就一个选项，PATH！这就是开启成功的钥匙！
所以，一定一定一定要使用set +h命令（三遍！），这是关闭哈希搜索，让系统只能按PATH的路径找文件！否则一旦找了错误的文件，将前功尽弃。
我们可以看到，第5章的时候，PATH是/tools/bin:/bin:/usr/bin，也就是，工具包的位置是优先位。第6章的时候，PATH是/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin，也就是实际位置是优先位，工具包的位置是最后位。
这是正常的情况，我们滚动升级的话，可以小小调整一下，就能够实现目的了。

下面进入操作阶段。
1、首先，你的系统会有一个老的LFS系统，比如我的是8.3，这时候，也应该还会有一个宿主系统，编译LFS8.3时用的，比如我的是UBUNTU。要利用这个宿主系统，升级LFS。至于能不能在LFS系统下直接给自己升级，我没试过，感觉不太行。因为一旦换头文件，编译软件就会失效。而发行版之所以能实现自我升级，是直接将编译好的成果直接复制粘贴不需要编译的。
2、用宿主系统，或者老LFS系统也行，直接完成手册第5章，就是编译出临时工具包。
3、在宿主系统下，进行第6章，先chroot切进LFS的根目录，此时注意，PATH继续用第5章的变量，即‘/tools/bin:/bin:/usr/bin’！这么做的原因是，因为是在老LFS上升级，此时切进老LFS系统时，系统内是有东西的，如果用手册第6章的PATH，系统就会用老LFS的包，而不是新包，从而会导致出错！
4、在保持'PATH=/tools/bin:/bin:/usr/bin'的状态下，持续开展第6章，直到6.25. GCC-9.2.0完成，也就是gcc最终完成。
5、此时，调整‘export PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin’,将PATH回归正统。这时候，完成后面的所有章节。
这样的操作下，全系统就成功实现了滚动升级。
怎么样，是不是很简单，只需要一个PATH的设置变动就可以搞定了！

这是完成后的图片。既升级好了lfs9.1的内容，又完好保留了原来系统的东西，不需要从零开始。

由于本人换了显卡，从N卡换到A卡，所以目前桌面是进不去了的。准备这几天折腾一下，装一下驱动，然后把XORG的相关软件重编译一下，感觉就差不多了。

这里补上上述做法的原理。为方便表述，这里用几个符号代表一下：原LFS系统的工具链，用-old后缀，现LFS系统的临时工具包中的工具链，用-tools后缀，现LFS系统的最终的工具链，用-final后缀（注意不用new，因为里面会有个ld-new文件，容易搞混....）
1、原系统LFS8.3中，ld-old,gcc-old均指向glibc-old，而glibc-old又指向header-old。
即：ld-old-->glibc-old-->header-old
gcc-old-->glibc-old-->header-old
2、LFS9.1完成了第5章编译时，/tools工具包软件中的情况：ld-tools，gcc-tools，这两个均指向glibc-tools，header-tools,
即: ld-tools-->glibc-tools-->header-tools
gcc-tools-->glibc-tools-->header-tools
3、第6章6.7. Linux-5.5.3 API Headers，上来第一步直接安装好了头文件，即此时产生了header-final，这个直接覆盖了原来的头文件header-old。这步导致了原系统LFS8.3的glibc-old不可用，从而导致了ld-old、gcc-old均不可用。所以这时候我们的PATH变量，一定要把/tools/bin放最前面，否则调用了ld-old，gcc-old，直接就出错。（我的情况是编译第一步就会直接卡死完全不动了！）
4、6.9. Glibc-2.31这章编译生成最终的glibc-final，它指向了header-final。这时候的编译，由于PATH未改变，用的就是ld-tools，gcc-tools，指向的均为glibc-tools。此时如果是新的干净系统，改变了PATH，用的也依然会是ld-tools，gcc-tools，因为新的系统中，此时在/bin,/usr/bin中是无内容的。这就证明PATH采用原来的配置是正确的。
5、6.10. Adjusting the Toolchain中调整工具链后，ld-tools，gcc-tools全部指向了glibc-final.也就是意味着，ld-tools和gcc-tools的指向，与最终将要安装好的ld-final、gcc-final的指向其实是一致的。这也意味着，PATH此时不改变，优先采用/tools/bin的设置依然是正确可行的。甚至可以说，现在这个ld-tools，gcc-tools可以一直用到老都没问题。
即此时：
ld-tools-->glibc-final-->header-final
gcc-tools-->glibc-final-->header-final
6、6.18. Binutils-2.34中安装了最终的ld-final.位于/usr/bin下。这时候按常理，应该优先使用这个指向才是最好的。
但是按我们上面的分析，其实继续用ld-tools，是没有任何区别的。因为它们的指向其实都是一致的。所以如果是新系统，PATH的优先级上/usr/bin在前面，是最合适的，这样可以优先使用刚编译好的ld-final。但是我们是老系统升级，依然用/tools/bin在前面的设置，优先使用ld-tools同样也没问题的。
此时：
ld-final-->glibc-final-->header-final
ld-tools-->glibc-final-->header-final
gcc-tools-->glibc-final-->header-final
可见，我们在下来的章节中继续用ld-tools、gcc-tools进行编译，其实和ld-final来编译效果是相同的。
7、6.25. GCC-9.2.0，将最终的gcc编译完成。生成了gcc-final.此时的指向为：
ld-final-->glibc-final-->header-final
gcc-final-->glibc-final-->header-final
ld-tools-->glibc-final-->header-final
gcc-tools-->glibc-final-->header-final
此时就像书中所说的，最终的一个工具链已经就位了。
这时候，我们就可以将PATH变量调整为最终变量值了，即/bin:/usr/bin:/tools/bin，将系统的文件优先。
当然，这时候你可能会说，继续不变，继续用tools优先不也行吗？是的，当然可以，但是我们的任务是尽快升级好原系统的工具链，然后用原系统工具链开展后面的工作，尽快甩开对tools临时工具包的依赖，这样才是正确的思路。所以，能第一时间更改PATH的时候，应该马上改。
此时，你甚至可以重启进入原系统，用原系统进行下一步编译而不再需要/tools这个临时工具包了。因为原系统中本来就有上个版本的工具包的其他软件，这些软件在之前正确安装好了header-final，glibc-final，ld-final,gcc-final后，其实都是可以正常运行的（也许真有个别无法运行?但是我是没碰到的，就算有，采用重新编译的方式修复即可）。这些软件都不是核心软件，不会影响到编译，也意味着可以采用同系统编译的方式进行升级覆盖就行了。
比如我的原系统是LFS8.3，用的内核是4.20.10，在完成这一步后，在5.5.3的内核头文件和新版本的GLIBC-2.31下，都是可以正常运行的。其他的软件，比如tar，bash等等也可以正常运行。
8、此时，继续做第6章的后面部分，就完成了LFS的升级了。其实也就是非核心软件的常规升级而已。想升就升，不想升都无所谓的，哪怕是内核，不升级，用原来的内核版本，都能正常使用的。最关键的升级，依然是前面提到的工具链。

滚动升级,直接按 blfs 的做法编译新版不就行了. 麻烦的是升级 glibc ,直接升级 glibc 会破坏原来的基本软件的依赖.
比如 ncurses 用的是 旧版的 glibc 库 ,升级 glibc后 ld-linux-x86-64.so.2 指向了新版.
这个时候需要用救援盘(救援系统进去修复这个依赖) 主要是 ld-xxx.so , 我认为没必要重建临时系统 (Constructing a Temporary System).然后直接编译 Basic System 中的各软件包即可.
因为有旧版的原因,需要消除旧版程序.

大佬，你能不能把这个LFS系统做成livecd供大家下载使用

哇，非常赞！

顶，最近正在折腾