MI root.step1 更新后 LayoutFb LayoutVesa 五秒后失败重启

haulm

实在是搞不定求助了。。。
layoutopt = ['LayoutFb', 'LayoutVesa']

sejishikong

mi2有一个更新环境的脚本吧。

zy_sunshine

要先手动调节好每一个 Layout 的 X 启动，两种Layout配置都在 xorg.conf 中定义
目前是用 LayoutFb LayoutVesa 两种方式启动，前者优先于后者，如果前者失败，五秒钟后尝试用后者启动，应该满足大多数显卡了。

haulm

原帖由 zy_sunshine 于 2011-11-16 13:34 发表
要先手动调节好每一个 Layout 的 X 启动，两种Layout配置都在 xorg.conf 中定义
目前是用 LayoutFb LayoutVesa 两种方式启动，前者优先于后者，如果前者失败，五秒钟后尝试用后者启动，应该满足大多数显卡了。 ...

我是想问，我只是升级了 xorg.xml 列表中的包，并没有动过别的东西，但是新的 MI2 就无法启动 X 了，这该如何解决呢。

zy_sunshine

手动执行X启动命令去测试啊..用strace ldd 等命令去查看到底是什么问题导致X不能启动..
这种问题情况很多的，也可以去看看xorg.log

haulm

原帖由 zy_sunshine 于 2011-11-16 18:51 发表
手动执行X启动命令去测试啊..用strace ldd 等命令去查看到底是什么问题导致X不能启动..
这种问题情况很多的，也可以去看看xorg.log

程序运行到那就自动重启了，怎么手动哈。。。

zy_sunshine

手动启动X + xterm 测试， startx + 若干参数

haulm

原帖由 zy_sunshine 于 2011-11-16 13:34 发表
要先手动调节好每一个 Layout 的 X 启动，两种Layout配置都在 xorg.conf 中定义
目前是用 LayoutFb LayoutVesa 两种方式启动，前者优先于后者，如果前者失败，五秒钟后尝试用后者启动，应该满足大多数显卡了。 ...

如何在现有系统中测试 LayoutFb LayoutVesa，如果我在 xorg.conf 中将驱动改成 LayoutFb LayoutVesa 根本就不存在这样的模块。在 MI 中该如何停止它加载 X 以便于测试 X 呢？MI 加载 X 失败就会重启。
对于 MI 最近的理解概念有所增加，我用 busybox kernel grub 参照网上文章实现了一个微系统，也就 7 M，如果把一些工具，比如 mksquashfs 添加进 initrd.gz，使用 ldd 查出依赖库也添加进 initrd.gz，也能实现微系统对新工具的运行。但是暂时没搞懂为什么 fdisk -l 返回空。
MI2 同样使用 busybox kernel grub parted，实现加载系统的方式非常相似，但我猜MI启动并不是象我自制的微系统完全一个 busybox 就实现了，我实在是没有代码洞查力去研究代码细节。。。root.step1 是从母系统的安装包中提取出来要加进 initrd.gz 中实现功能的程序和类库部份，并由这些文件进行控制：
bash.xml          glibc.xml    mkfs.xml             pyudev.xml  script         udev.xml
busybox.xml     grub.xml    parted.xml          rhpl.xml       syslib.xml    xorg.xml
debug.xml        gtk2.xml    post_scripts.xml  rpm.xml       themes.xml
filesystem.xml  kudzu.xml  python.xml          SConscript  trace.xml
MI 必需跟着母系统的更新不断更新，而 root.step1 是最需要跟着系统更新而变化，可惜 magiclinux 的安装器 MI 的 root.step1 没有一个方便的更新工具，以致于手工去修改版本号核查变动的类库或程序名，最烦人的是xorg.xml，由于 xorg 1.6 升级到 1.9.3 很多东西发生了改变，我也闹不清 X 为何启动失败。
目前 MI2 有很多 Bug，没有 MI1 稳定，不过更新比 MI1 方便，受母系统影响更大，MI1 用 uClibc 编译的工具链来编译工作环境，更新难度更大。MI2 从母系统提取的内容比 MI1 还要多，不过我更愿意相信这只是会使一些提取内容的依赖增加，除增加体积外应该不会造成别的麻烦。
目前 MI 工作不稳定的原因很奇怪，包括 内核更新影响到系统启动，为什么不直接用 busybox 直接运行然后 chroot 到 MI 呢？分区识别有问题，这和 parted 有关，而 parted 不稳定肯定和 root.setp1 里的内容有依赖。
唉，乱，总之目前的 MI 的确很难升级，整个工程倒还不如把整个制做过程教程化更有助于理解和更新。
半桶水就讨论这样的东西，如有错误请见谅指正。

sejishikong

mi环境可以在当前系统下运行。从而可以测试X。
linux整个是一个系统，有些很小的地方也可能给其它地方带来影响的。
比较容易的解决办法大概是有一个稳定ml系统，从ml里提取相应的文件，不过说起来容易，真要调试起来的话，比较麻烦的。

haulm

分享一下，通过 kernel busybox grub squashfs-tools，提取系统中的
/lib 下的
ld-linux.so.2  libc.so.6      libm.so.6        libuuid.so.1
libblkid.so.1  libgcc_s.so.1  libpthread.so.0  libz.so.1
/usr/lib 下的
liblzma.so.2  liblzo2.so.2
事实上除了 busybox 需要静态编译外，其它所有东西都可以提取，整个系统不过 8M。
完成后运行系统可以用 mksquashfs 压缩文件，也可以 unsqashfs 解压文件
这有什么用呢？ 也就是说 Livcecd 实现或 ghost 类似的安装也就这么来的了，现在的麻烦是要解决 busybox 找不到硬件的问题，需要系统能识别硬件需要哪些东西？ udev ？

haulm

原帖由 sejishikong 于 2011-11-17 09:18 发表
mi环境可以在当前系统下运行。从而可以测试X。
linux整个是一个系统，有些很小的地方也可能给其它地方带来影响的。
比较容易的解决办法大概是有一个稳定ml系统，从ml里提取相应的文件，不过说起来容易，真要调试起来的话，比较 ...

我觉得 MI 不是一个好办法，从目前大家安装的状况可以看得出来。MI 只能说用来测试自己系统的完整性还是有用的，但交给用户使用已经是过时的了。现在最好的安装方式就是 Live 方式，或者干脃不用 LIve ，直接解压安装 grub 就是了。而且根本不难实现，还省了 MI 升级的痛苦。提供给大家一个系统，其实要唯护两个系统太辛苦了，更何况网上有很多微系统，为什么要我们自己去实现？

haulm

好多系统都有非 X 的安装方式，MGC 没有。

sejishikong

en，这其实是个问题，不过我的确不知道怎么办。
理论上的python的改成文本界面应该可以吧。
其实现在比较流行的还是live方式的安装。

sejishikong

原帖由 haulm 于 2011-11-17 09:24 发表

我觉得 MI 不是一个好办法，从目前大家安装的状况可以看得出来。MI 只能说用来测试自己系统的完整性还是有用的，但交给用户使用已经是过时的了。现在最好的安装方式就是 Live 方式，或者干脃不用 LIve ，直接解压安装 grub  ...

问题在于，如果用live方式安装，需要写一个安装程序，这个谁来写。

zy_sunshine

mi 尚且搞不定，你不要谈别的了，做出来的东西也没法用的。

mi 就是基本功，你不搞懂，去搞LiveCD，出来的东西也是不行的。

mi2是重构，每一行代码，系统中的每一个文件都是手工调试出来的，想要自动升级是不可能的，这种非常底层的活是不可能自动的。

不要长篇大论了，最简单的方法就是赶紧去看代码。

我长时间不动 mi 的原因是因为我需要提高编码水平，在我现在的编码水平也不能对她做多大的提高。