 |
|
|
本帖最后由 2011yaya2007777 于 2018-10-19 09:25 编辑 明白了。原来是从这里下载。下载了一大堆。在 wee 界面没有下载链接。 不能从grub4dos_dev命令行下载。 |
|
你的做法可能不正确吧？ 用浏览器进入这个页面： https://github.com/chenall/grubutils 点击 “clone or download” 按钮，会显示 https://github.com/chenall/grubutils.git 因此，试试： git clone https://github.com/chenall/grubutils.git |
|
git clone git@github.com:chenall/grubutils/tree/master/grubutils/wee.git wee 不能下载 |
jianliulin 发表于 2018-10-18 11:37 你看到的是表面现象。实质没变。当我发现新电脑封杀了 BIOS 以后，自然想让电脑能够启动。而 grub4dos 完全无用，因此，只能寻找 EFI 的启动工具——用户是没有选择权的。 但我立刻又发现，EFI 下的问题一点也没减少。它制造的问题更多。EFI 的目的，大概也就是为了只让 Windows 运行。那些 grub2 之类的方案，或许暂时能够喘息一段美好时光，但终究还是会被折腾死。要知道，BIOS 可是会随时偷偷更新的。 这就迫使我下定决心，弃掉 Windows，寻求纯 Linux 的方案了。我不知道这个过程会持续多长时间，也不知道最终能否如愿。但我知道，没有第二方案，这是唯一的出路了。 |
| 不管怎么说，WEE做硬盘启动管理真的不错。可内置菜单，占用扇区少，可以说是精简版的G4D |
不点 发表于 2018-10-18 11:28 你之前不也很反对grub4dos往uefi方向发展, 现在不也改变了 |
本帖最后由 不点 于 2018-10-18 12:08 编辑 jianliulin 发表于 2018-10-18 10:28 在 Linux 圈里，恐怕没什么人承认吧。时代变了，也不能仅仅看微软不再说 “Linux 是癌症”，就真的有了什么实质性的变化。该打压的，照打不误。对此 “变化”，不同的人，有不同理解。我的理解就是：嘴上说说而已，假支持，真打压。微软换了个掌门人，有一些调整。但大方向是不会变的。美国总统可以换，但都代表美国大财团的利益，因此，该往哪里投放炸弹，照投不误。 补充一点。微软以前可以让 Linux 与 Windows 共存，大家可以方便地 “双启动”。如今微软要消灭双启动，仅仅只让 Windows 启动。有人说了，Linux 也能启动。但是，微软封杀的途径不仅仅是启动程序，还有驱动程序。Linux 启动以后，声卡、网卡、显卡，有一样不能驱动，照样是无法使用。所以，微软 “在实质上” 已经封杀了双启动。既然控制了硬件生产商，那么一切都在控制之下。既然微软能让 XP 和 Win7 转不起来，就能让 Linux 也转不起来。表面上没把 Linux 封死，其实更具欺骗性。因为实质上是封死了。转起来毛病百出，我理解为，那就是封死了。至于说在 Windows 之下运行 Linux，就不要提了。那样的 Linux 是在闭源的 Windows 控制之下的 Linux，失去了开源的意义。就跟在 Windows 的虚拟机下运行 Linux 是类似的。这里的任何内容，都在 Windows 监控之下。如果不想被监控，那就不会接受它。 就是说，以前可以双启动，现在不行了（看上文的解释，别被假象迷惑）。微软现在让大家 “二选一”：要么 Windows，要么 Linux；互不通融。这个情况不只出现在 Windows 的世界里，在其它世界里也一样（谷歌、苹果都不例外），都是不再通融，要封杀 Linux。 |
不点 发表于 2018-10-17 18:46 微软已经免费共享几万个专利给linux使用了，windows都能运行linux的程序了，时代变了。 |
| 原来http://chenall.net/右上角有个github，github里面有个grubutils，代码都搬到github上了。 |
| chenall的网站上除了有weesetup，是个类似bootlace的安装器，没有wee的项目空间了，原来的网址打不开了。 |
金 发表于 2018-10-16 11:30 我也认为，grub4dos 没劲，因为 BIOS 已经被封杀了。但我与你有不同想法——我认为 EFI 也没劲，因为 EFI 迟早也是被封杀的命运，这是注定的。想想看，若干年前，win98 被封杀，然后 XP 被封杀，现在是 Win7 被封杀。 因此，我更看重（或看好）某些开源的硬件制造商，比如生产 Librem 系列产品的那个叫做 Purism 的公司，它生产的产品不会封杀 Linux——它甚至只支持安装 Linux，而不支持安装 Windows、iOS 或 Android。而其它那些既支持 Linux 也支持 Android 的产品，表面上看似是个优点，但我觉得那是缺点。道理很简单：支持 Android 会伤害 Linux。这是因为，设计 Android 操作系统的主要目的之一，就是要与 Linux 不兼容。把故意制造不兼容性的 Android 与 Linux 进行 “共生”，只会给 Linux 带来麻烦。因此那些支持 Linux + XXX 双系统的厂商都靠不住，迟早也要封杀 Linux。 现在没封杀，那是时候未到。 yaya 问 list_partitions 函数在哪里。chenall 的网站上已经保存了最新版的 wee 的代码。在汇编语言的代码中就有这个函数。 |
本帖最后由 liuzhaoyzz 于 2018-10-16 11:58 编辑 金 发表于 2018-10-16 11:30 现在都是高铁时代了，为啥街头上到处都是共享单车？ 引用麦克阿瑟的名言：老兵不死，他们只会慢慢凋零！ |
|
http://bbs.wuyou.net/viewthread.php?tid=167593&extra=page%3D1 MBR 嵌入微型 grub （2010年12月19日更新，不点大师加菜单） 本文和所有文件来自时空论坛“不点”大师！在此致谢！ 这个 grldr 的头部不再是 16 扇区，而是 2 个扇区。只有这样，体积才可能减小到 63 扇区以内。 现在说说这个新的 GRLDR 精简版的结构： 1。第一扇区是为了放置在 MBR 上的。你只需要将开头的 440 个字节复制到 MBR 就可以了。分区表当然不能被破坏，这和以前的做法是一样的。 2。第二扇区仍然是为了备份先前的 MBR，这个也与以前一样，不多说了。 从第三扇区，一直到文件结尾，就是放置在 MBR 上的相应扇区上的。也就是说，MBR 为第一扇区，紧接着是第二扇区（放置先前的 MBR 的备份），再接着，就是第三扇区，放置的当然应该是 GRLDR 的第三扇区以后的全部扇区（总共放置的扇区数不超过 63 个，因为 GRLDR 的长度就在 63 扇区以内）。 大家先在虚拟机下测试，以免有什么 bug 把你的硬盘破坏掉，那我可不负责。 然后，再说说 grldr 文件结尾处的 echo weeeee 命令。这仅仅是一条测试用的命令。你在这里放置任何命令都可以的。grldr 启动之后，首先就要执行这里的命令序列。是的，很多命令都可以放在这里，不同的命令之间，用回车或者换行分隔都可以。 如果你放置的是如下两条命令： 复制内容到剪贴板代码: find --set-root /grldr /grldr 那么启动时会自动寻找 grldr，如果找到，就启动 grldr。当然这个 grldr 就是常规的、非精简版的 grldr 了。而精简版的 grldr 是不能用这种方法来启动的。 一个附带的特性，这次把 grldr 放在任意深的目录下是可能的了： 复制内容到剪贴板 代码:find --set-root /boot/grub/grldr /boot/grub/grldr 得益于 find 的查找功能。好多人以前希望 grldr 不放在根目录，那时候是不可能做到的。现在可以了。而且也支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了。 需要说明，精简版不支持 title 等命令，也不支持 && 和 || 逻辑符号。其实只支持 root, find, command 这三条内部命令。其他的都是外部命令。例如，grldr，grub.exe，ntldr，bootmgr，vmlinuz，io.sys，kernel.sys，echo 等，统统都是外部命令。 提醒一下：不要安装在 U 盘的 MBR 上。有很多主板对于 U 盘不使用 LBA 模式。而我们这个精简版的 GRLDR 只支持 LBA 模式，而完全不支持 CHS 模式。所以，放在 U 盘就不行了。当然，如果你知道你的主板 BIOS 在你的 U 盘上确实提供了 LBA 支持，那倒是可以试一试的。 新版本到 http://nufans.net/grub4dos/wee/ 底下 原文地址： http://bbs.znpc.net/forum.php?mo ... &extra=page%3D1 --------------------2010年12月19日更新----------------------------- 地址：http://nufans.net/grub4dos/wee/ 菜单如下： （最大支持20个菜单条，恳请各位测试反馈） title WDC-500G-wee clear title 01 WinXP root (hd0,1) +1 title 02 WIN7 root (hd0,0) +1 title 03 D_PAN root (hd0,4) +1 title 04 E_PAN root (hd0,5) +1 title 05 XORLDR 52628941+1 title 06 GRLDR 2104000+490 title 07 FBINST.MBR 557134253+1 title 08 PLoP Boot Manager 2103900+100 title 09 GMY-GHOST /memdisk /ghost.img img raw title 10 SYSLINUX find --set-root /boot/IBM.ICO +1 title 11 SSXF-WinPE find --set-root /boot/SSXFLDR /boot/SSXFLDR title 12 SSHY-WINPE find --set-root /boot/SSHYLDR /boot/SSHYLDR title 13 VISTA find --set-root /boot/IBM.ICO /boot/bootmgr title 14 SKTQB 2101000+480 title 15 WIN NT/2003/XP find --set-root /NTLDR /NTLDR title 16 Win7/VISTA find --set-root /BOOTMGR /BOOTMGR title 17 WinPE.ISO /memdisk /winpe.iso iso raw 注意： 1.不要用chainloader 命令，仿上述命令即可！ 2.也请各位测试 title 03 D_PAN rootnoverify (hd0,4) +1 title 04 E_PAN rootnoverify (hd0,5) +1 即 rootnoverify 命令是否有问题？ 3. 【改造】可以将U盘可见分区的BPB复制到MBR，可能提高安装到U盘的启动兼容性。 如果U盘启动电脑成功，则不需复制BPB如果U盘启动失败，再试试这个方法。欢迎大家测试反馈！ 将可见分区（最好是FAT分区）的引导扇区从偏移0X02到偏移0X59止，复制到MBR的0X02到偏移0X59后再按不点大师指导的方法稍作修改即可！ 【不点大师指正：BPB 是促使某些 USB 的主板识别 USB 设备的。有些主板需要 BPB。而有些主板，不喜欢 BPB，有了 BPB，它反而会失败了。另外，既然是欺骗主板的，那么 BPB 是不是就要做得很像呢？比如说，位于 0x1C 处的四字节的“hidden sectors”（隐藏扇区数）域，应该清零，才算是一个合法的软盘引导扇区。在第一扇区上的 BPB，其实就是模仿软盘。同时，位于 0x0E 处的两字节的“reserved sectors”（保留扇区数），应该指向第一分区的 FAT 表的开头，此时第一分区最好也应该是 FAT 格式的，这样更容易欺骗成功。通常，第一分区起始于扇区号 63。隐藏扇区数，加上保留扇区数，就是 FAT 表的起始扇区的号码。所以，很容易算出来。那么，位于 MBR 上的 BPB 中的隐藏扇区数，加上保留扇区数，也应该等于 FAT 表的起始扇区号才算完美。不过，有时候（隐藏扇区数和保留扇区数）两者加起来超过了 2 个字节，那就没办法了，没法写入保留扇区数中了，因为保留扇区数只有两个字节的空间。这时，你可以随便设置一个保留扇区数，不过，应该至少是 64（也就是十六进制的 0x40）。而前面已经解释过了，MBR 上的隐藏扇区数应该是 00 00 00 00，只有这样才算一个完全的欺骗。但是，欺骗得完全，不一定能提高启动的成功率。这就要靠实践来证实了。】 4. 【应用之绝对扇区启动】 将某文件写入绝对扇区，如：plpbt.bin，位置是8388000扇区，大小约85个扇区 菜单写入：command (hd0)8388000+85 （注意command后空一格） 即可从本机启动plpbt.bin。。。目的是加载USB启动 【其他】若想启动grldr完整版也可以，类似： command (hd0)X+Y X是grldr的绝对扇区位置，Y 是grldr占用扇区数 目的是系统或分区损坏，从绝对扇区启动加以维护。。 请大家测试反馈，谢谢！ [ 本帖最后由 天涯海角1216 于 2010-12-21 14:13 编辑 ] 你还可以将分区PBR备份为：c.bin（1个扇区即可），放在根目录 用： find --set-root /c.bin /c.bin 即可成功启动该分区 或 find --set-root /boot/IBM.ICO +1 也可以启动该分区！ find --set-root /boot/IBM.ICO 是定位分区的！ 可以直接启动文件或分区PBR，支持子目录查找和支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了 很想知道假如全新安装XP的话会不会覆盖掉嵌入的微型Grub 如果是GHOST，则不会覆盖掉嵌入的微型Grub， 如果是安装版的，则会覆盖掉嵌入的微型Grub的第一扇区。。 ghost我不担心，担心的就是安装版的，每次安装安装版XP后都要重写MBR，这个要是不受安装版XP的影响就好了 其微型grub是安装到mbr上，它的mbr是专为微型grub使用，若0扇区被修改，同样无法启动此grub，其他mbr也是一样！ 原来的grub安装到mbr，占用18个扇区，只是能够搜索grldr，其本身不能启动分区或文件，而此微型grub则具有启动分区和文件的功能了！ 这个63扇区的grldr用在PXE上不错，可以引导grldr/ntldr/bootmgr/pxelinux/...，看成是引导的引导 但目前不支持菜单，这很难办。 时空论坛的原帖“不点”提出微型grub后不久，时空论坛PT版主就做了一个63S-GRUB，并在无忧发布，见http://bbs.wuyou.net/viewthread. ... highlight=63%2Bgrub ，Pauly 为其制作了一个 63S-GRUB 安装设置程序，见：http://bbs.wuyou.net/viewthread. ... highlight=63%2Bgrub 天涯能否将现在发布的与之做个对比?让我等菜鸟能更容易理解和应用，谢谢！ 用 Pauly的 BOOTICE 能带参数直接安装吗？如果BOOTICE带参数恢复比较安全，怕不小心把分区表搞坏了。 不放心的话，可以先备份MBR到U盘，再用BOOTICE写入就可以了！ 将里面的 grldr 第一扇区除分区表外写入硬盘MBR，再从第三扇区开始复制并写入硬盘第三扇区开始处！ 因为其大小不是512字节的整数倍，所以BOOTICE会拒绝写入。。。 我将其写入硬盘，加上菜单再备份出来，一定是512字节的整数倍了，所以才可以用BOOTICE写入硬盘了。 6月20日更新，欢迎测试反馈！ 我觉得不点大师如果推出一个介于完整版和此微型版之间的GRUB（GRLDR）更实用些，我相信多数都是“中间选民”。 这个过于精简了，不支持标题和CHS都是令人不快的事，我还是用以前的绝对扇区GRLDR法。 不点大师的本意是安装到MBR及其以后的62个扇区内，再加上简单的启动系统和其他功能的，所以只有不足31.5KB(63个扇区就是31.5KB大小) http://bbs.wuyou.net/viewthread. ... p;page=4#pid1982652 感谢天涯海角哥们，你为此付出了很多。你的文档，弥补了软件的不足之处。你的介绍很周到、很细致。 有几个问题我想提出来共同研究、探讨。 1。前面有兄弟提问，说 Windows 重装后，MBR 上的 Wee 是否受到影响。这个问题的答案当然是“会受影响的”。这没有什么办法。Wee 也不是为着解决这个问题而来的。Wee 不可能解决这个问题。任何软件都不可能解决这个问题，除非刷到 ROM 上。Wee 的主要目的、意图，是取代原有的 grldr.mbr 安装在硬盘第一磁道上。这样，当硬盘上的 GRLDR 等查找失败时，还可以进入命令行，手动查找 GRLDR，或者手动进行一些其他的修复。大家对于 Wee 的认可程度，也不是一下子就可以提高的，肯定要经历一个过程。因此，不要夸大 Wee 的作用和能力，否则适得其反。有的人需要 Wee，而有的人不需要 Wee，因人而异。 2。Wee 在 USB 设备上不一定管用，除非你确认，你的 USB 设备能够被主板 BIOS 以 LBA（EBIOS）方式访问。这很要紧，因为 Wee 只支持 LBA（EBIOS），而完全不再调用 CHS 模式的普通 BIOS。只要 Wee 在你的 USB 设备上能够成功启动，那就表明，你的 USB 设备在你的主板上是支持 LBA（EBIOS）的。否则，就是主板不支持。因此之故，Wee 的主要意图，并非安装在 USB 设备上。在 USB 设备上，请使用全功能的 GRUB4DOS，并用 fbinst 来安装，以提高启动的成功率。 3。Wee 是一个非常小的操作系统。其实，grub4dos 也是的。在功能上，Wee 并不比 grub4dos 强。Wee 的优点就是“小”这个字。它能完全嵌入到 MBR 的 63 扇区上，这才是它的亮点。而 GRUB4DOS 则需要两级启动步骤，从 MBR 查找 GRLDR，才可以最终启动成功。 4。天涯海角兄提到在 MBR 上添加 BPB。我提出一点补充意见。BPB 是促使某些 USB 的主板识别 USB 设备的。有些主板需要 BPB。而有些主板，不喜欢 BPB，有了 BPB，它反而会失败了。另外，既然是欺骗主板的，那么 BPB 是不是就要做得很像呢？比如说，位于 0x1C 处的四字节的“hidden sectors”（隐藏扇区数）域，应该清零，才算是一个合法的软盘引导扇区。在第一扇区上的 BPB，其实就是模仿软盘。同时，位于 0x0E 处的两字节的“reserved sectors”（保留扇区数），应该指向第一分区的 FAT 表的开头，此时第一分区最好也应该是 FAT 格式的，这样更容易欺骗成功。通常，第一分区起始于扇区号 63。隐藏扇区数，加上保留扇区数，就是 FAT 表的起始扇区的号码。所以，很容易算出来。那么，位于 MBR 上的 BPB 中的隐藏扇区数，加上保留扇区数，也应该等于 FAT 表的起始扇区号才算完美。不过，有时候（隐藏扇区数和保留扇区数）两者加起来超过了 2 个字节，那就没办法了，没法写入保留扇区数中了，因为保留扇区数只有两个字节的空间。这时，你可以随便设置一个保留扇区数，不过，应该至少是 64（也就是十六进制的 0x40）。而前面已经解释过了，MBR 上的隐藏扇区数应该是 00 00 00 00，只有这样才算一个完全的欺骗。但是，欺骗得完全，不一定能提高启动的成功率。这就要靠实践来证实了。 5。天涯海角兄在 “绝对扇区启动” 中提出启动 plpbt.bin，我不知道行不行。command 的功能比 chainloader 弱。command 不能启动普通的引导扇区文件，只能启动 512 字节 ～ 1024 字节之间的引导扇区文件，而 chainloader 无此限制，可以启动几百K的引导扇区文件。所谓引导扇区文件，就是指它的第一扇区的末尾处含有 55 AA 这个“引导扇区合法标志”，这样的文件，都可看成是引导扇区文件。我不知道 plpbt.bin 是个什么格式，如果仅仅是引导扇区文件，则它不能被 command 启动，因为它太大了，超过了 1024 字节。如果它是 Linux 内核格式，则它仍然可以被 command 启动，因为 command 本身已经设计好了，支持 linux 内核格式的文件的启动。如果 plpbt.bin 不是 Linux 格式，而是 multi-boot 格式，则它不可以被 command 启动，只能被 chainloader 启动。 另外，command 还不能启动 WinMe 的 IO.SYS。所以，整体来看，Wee 的功能比 grub4dos 的功能要稍微弱一些。这是意料之中的，因为它是精简版的。 [ 本帖最后由 不点 于 2010-6-21 07:44 编辑 ] http://bbs.wuyou.net/viewthread. ... p;page=4#pid1982804 发表于 2010-6-21 11:42 另外，关于 BPB 这个概念 其实还有偏移 03 到 0A 这 8 个字节。我觉得这也应该算是 BPB 中的，甚至连偏移 02 处的那个字节 0x90 在内，也可算是 BPB 中的。因为有些启动程序就是根据这些特征，来确定 BPB 的。 所以，复制 BPB 的时候，最好提供一些选项，来决定究竟怎么对待这些不同的字节区域。也可以让用户自己决定 BPB 的每个字节。让用户以十六进制的方式来编辑 BPB 中的每个字节。 个人觉得无需考虑BPB，在wee启动的前提下（EBIOS）根本不存在这方面的困扰。在U盘上最好还是用fbinst及全功能的grub4dos较好。这个wee只适合于本机硬盘并且在紧急救援的情况下 http://bbs.wuyou.net/viewthread. ... p;page=4#pid1983038 Climbing, 这完全是两回事。如何让主板承认 U 盘，v.s. 如何让主板支持 EBIOS。 如果主板不支持 EBIOS，那么我们基本上也无法让它支持 EBIOS。当然此时使用 wee 是必然要失败的。 但是，如果主板连 USB 设备都不承认，那就可能与这个 U 盘的扇区数据有关。通过更改扇区数据，或许可以适应主板的要求。在主板支持 EBIOS 的情况下，更改 BPB 数据，有可能改变成功率。 这是两个问题，不是一个问题。 你让天涯海角兄使用 fb 是对的，但是在天涯海角兄愿意尝试在 U 盘安装 wee 的情况下，他的填写 BPB 的步骤也并非完全无意义的。 在我的一台电脑上，U 盘启动时就支持 LBA（EBIOS）。这样的情况确实可以使用 wee。 wee 只支持 FAT12/16/32，NTFS，EXT2/3/4，不支持 iso9660 光盘文件系统。 光盘空间很大，根本不需要考虑安装 wee。 不点最好能给wee配一个类似bootlace之类的安装工具，第三方的总觉得可能没有官方的可靠。 现在顾不上这事，只能先依靠第三方的工具了。只要经过充分的测试，都不会有问题的。 wee 的重头戏，还在于如何与 grub4dos 接轨，让两者共用相同的外部程序。目前这也没时间考虑。 试用能正常，如果命令行下，能记忆上次输入命令就好多了，真正机器出问题，进入命令行对于我们新手，经常输错命令，又要重新输入，又急又烦，能用上或下方向键补回上次命令再修改多爽，比Tab补全还实用。 这等以后再作修饰。现在不求完美，但求能用。 目前没有命令历史功能。 这个功能并不很迫切。只有当你试图启动 Linux 的时候，才需要输入长长的命令行。 其他情况下，基本都是很短的命令行。 [ 本帖最后由 不点 于 2010-6-22 12:01 编辑 ] 请问不点大师 Wee安装在usb设备上不能成功启动时屏显内容是什么 我昨天把Wee用jianliulin的安装工具写入到一个U盘 在本上启动成功 在一台古董机上启动时 明显失败 usb设备能识别 但是引导其启动时提示Mem fail 且一直在刷屏 强行关机后再用这个U盘插在本上启动 也启动失败了 提示和古董机提示相同 mem fail 刷屏 按不点的规划，wee是用在硬盘的辅助工具，在U盘建议使用FB，在其他场合可以使用G4D 因为wee没有自动探测功能，楼上把它用在U盘是靠不住的 回复 #51 esxcfr 的帖子 好像没有规定不能用在USB设备上吧 我只是在尝试 FB不是很喜欢 UD区不能被大多数常规程序读取 造成PE的外置类还是需要放在可见区 容易被破坏 主要想知道的是Wee装在U盘上启动失败的错误提示 以及 为什么开始时安装Wee的U盘在A机上启动正常 在B机启动失败后 再启动A机时也失败 难道被改写了 把这2次MBR备份63个扇区，用WINHEX比较，就可以知道代码是否修改了 得找时间试试了 这周是没时间测试这个了 昨天是有人要装系统 顺手把Wee写U盘上试了下 http://bbs.wuyou.net/viewthread. ... p;page=6#pid1991818 有迹象表明，笔记本的 USB BIOS 似乎倾向于支持 LBA。那么，在笔记本下使用 wee，估计有一定的成功机会。 wee 不打算支持内存很少的古董机。我记不太清楚，好像内存低于 60M，就要出错了，错误信息确实是 mem fail。 当初想把 wee 的 32 位代码放置在扩展内存的最高端，所以，就需要探测内存量，并且拒绝那些内存太少的机器来使用 wee。但是现在，其实放弃了将 32 位代码放置在扩展内存顶端的努力，所以，此时已经不需要限制内存量了。但是，32 M 的内存还是需要的，因为外部的程序需要从 16M 处开始运行，所以，32M 是一个必须的配置。因此，要求 60M 也不算过分。所以，也就不用改了。你的内存有多大？或者虽然内存足够大，但 BIOS 却不支持 int15／EAX=E820h 这个内存规范，那么 wee 也就无法知道内存的总量了，于是也要出错 mem fail。古董往往正是缺乏对 int15／e820 的支持的。将来我们可以取消这个测试，不再管这些内存总量的问题了，那样，兼容性会提高。 如果 BIOS 本来就不支持 LBA（EBIOS），那么，wee 在第一扇区中的出错信息 Urr! wee... 就会显示出来的。看来你的古董机竟然也能够支持 LBA。因为已经装入了后续的 61 扇区。只要能够装入后续的 61 扇区，那就表明，LBA（EBIOS）是支持的。如果不能装入后续的 61 扇区，那就会显示 Urr! wee... LBA 的支持，对于 wee 来说是很重要的。wee 永远不会调用 CHS 的功能，所以，一个假想中的 BIOS，完全可以没有 CHS 的支持，只要支持 EBIOS 的功能，便可以正常使用 wee 这个操作系统了。wee 从第一扇区 MBR 开始，就不再调用 CHS 的功能，而完完全全调用纯粹的 EBIOS 功能。因此，wee 可以用来检验一个 BIOS 是否支持 EBIOS 的基本功能。 有的 BIOS 会不会把 U 盘的扇区破坏掉？所以才出现你所说的问题？这有待你进一步确认。很有可能，BIOS 在启动过程中，向 U 盘的开头写入了不该写入的信息。这或许是 BUG，或许是某种未公开的秘密。 回复 #56 不点 的帖子 回不点大师 古董机内存是256M BIOS支不支持LBA我也不太清楚 是台联想品牌机 这台还好点 能USB启动 同批的其他联想机连USB启动都没有 出错信息Urr! wee... 这个是一直有还是只有第一行提示 因为出现mem fail后一直在刷屏 我不确定错误提示第一行是什么 改写U盘扇区那个我再看看 用Wee出现问题 用grldr.mbr就没有问题 能正常启动 还有就是这台机子的U口是1.1的 速度不是一般的慢 后置U口还有问题 只能用前置U口 不知道和这个有没有关系 到显示 mem fail 的时候，就已经表明，61 扇区的 pre_stage2 核心代码已经开始执行了。前面已经解释了，这就表示，LBA 是支持的。 如果显示的是 Urr! wee... ，那么接下来就是一个 jump 到自己的无限循环，必须 ctrl＋alt＋del 才能启动。 其实，显示 mem fail 之后，也是一个 jump 到自己的无限循环，必须 ctrl＋alt＋del 才能启动。只是不知道究竟为何出现混乱的局面。怀疑 U 盘的磁道被写入了什么信息，破坏了 wee 的代码，导致混乱的发生。 当然，wee 出现 bug 的可能性也有。懂得汇编语言的朋友不妨帮助调试一下，找出问题的根源，解决它。 －－－－－－－－－－－－－－－ wee 考虑加强对 ebios 的支持，放弃对于 CHS 模式的普通 BIOS 调用的支持，是一个无奈的举动。同时也是一种努力（尽管可能是微不足道的努力），希望（从某种程度上）促成 LBA（EBIOS）的普遍采用。EBIOS 在硬盘上早已被支持了，然而对于本来就没有“磁头”“柱面”以及“磁道”的 USB 设备来说，却仍旧采用 CHS 而不支持 LBA，那确实是一件很值得怀疑的事情，显然制造商们把问题搞得太复杂了。LBA 属于线性地址，没有扭曲的三维几何地址的变化。应该来说，支持 LBA 是最容易的一件事情。LBA 是一维的线性地址结构，而 CHS 则是三维的立体地址结构。当然，LBA 最简单。 [ 本帖最后由 不点 于 2010-7-1 22:11 编辑 ] 回复 #58 不点 的帖子 哦 理解错误 以为会在提示Urr! wee... 后再提示mem fail mem fail无限循环那个我也比较怀疑 所以想问问这种出错是否正常 现在看来问题还不少 我尽量抽时间再用U盘试一下 把前后两次63扇区内容传上来 回复 #58 不点 的帖子 很郁闷的问题 今天再用那个写入Wee的U盘启动那台古董机居然成功了 没有提示fail 引导进了grldr 试了好几次都没能重现昨天的错误 ====================================== 刚刚又试了下 这次重现了 附件里是扇区备份 确实被改写了 不点大师看看吧 normal.bin是写入Wee后的备份 error.bin是出错后扇区的备份 很抱歉，我最近没有时间。而关于对比扇区字节的事情，这谁都能做。你只要报告，有多少个字节被改写了，起始于何处，终止于何处。改写的规律是什么？为什么有时改写，有时又自动复原了？另外，U 盘有防写开关（写保护），是不是不起作用？或者你根本就没有试验？除了BIOS 会改写以外，会不会是病毒干的？ 回不点大师 具体哪一段被改写了我还真没来的及看 测试出错后就直接保存扇区传上来了 不是有时改写 有时自动复原 是写入Wee后开始几次正常 再启动就报mem fail 以后的几次也都是mem fail 没有成功的 有什么规律我也不知道 U盘没有写保护 也没有用diskpart设置磁盘只读 病毒的原因应该不太可能 那台机子很少有人用 U盘也确认没有病毒 增加的 exit 命令，本来的目的，只是方便用户从自己写的 32位可执行程序中调用 enter_cmdline 函数的。如果没有 exit 命令，则 enter_cmdline 无法返回到用户自己的32位程序中。有了 exit 命令，enter_cmdline 就可以结束了，控制将能够返回到调用者。 可是天涯海角1216 兄的exit，我还没明白有什么用。 ——哦！是不是只要第一条命令是 exit，整个菜单就不会执行了？反正感觉很奇怪，一头雾水。 |
| 参与人数 1 | 无忧币 +5 | 收起 理由 |
|---|---|---|
|
| + 5 |
|
http://bbs.znpc.net/forum.php?mo ... age%3D33&page=1 A smaller grldr in size? Can I download a small size grldr anywhere? the best is the size is 63k or less. Can the grldr be packed, then it decompress itself inside the memory? anyone? thanks, uleak 现在没有的。要 63K 这么小的好处是什么？能否讲一讲？ thanks tinybit. I am doing a small experiment. If grldr is that small, then I can simply put it in a img file, embedded into ROMOS. Thus I can embed grldr in a single option rom. this is eliminate problems such as the need of writing to mbr or lossing grldr, etc. This is the method: the ROMOS embeded an img file, which img contain a menu.lst and grldr. The internal boot-strapper relocate grldr.mbr to 7c00:0000, then grldr.mbr chain-loading the grldr from that in-memory img file. Because the img file is within the ROMOS body, which is located in c000:0000 to c000:ffff (64K). _OR_ compress the grldr. I tried to upx the grub.exe and results ~90K grldr may be the same. etherboot offer a upx alike program and the decompression source. this is decompression is a 32bit sub-routine that can act as prefix. one more thing to add. please think about vista. The sequency of boot->grldr->ntldr->grldr is clumsy, it need to modify much file. this embedded method may reduce the steps. and most importantly flashing into the nic boot rom is easier than cbrom into bios. uleak说的确实是一件重要的事情。GRUB 中的文件系统驱动程序占了大量的体积。把那些无关的驱动程序去掉，GRLDR 才有希望变小。 我觉得只要保留 FAT，NTFS，EXT2 以及网络驱动就够了。把其他那些驱动都去掉。另外，把 C 程序改成 ASM 程序，可以大大缩小体积。精简到 63K 应该不成问题。甚至可以精减到 30K，而完全放在 MBR 磁道上。 其实可以考虑grub2，grub2的内核可以定制，需要哪些模块就加哪些。没有包含在内核的模块可以从外部装载。而且，绑定在内核的模块是压缩的，这可以减少内核的大小。 根本的解决之道，我觉得不能是压缩。压缩只能有大约二分之一的压缩率。如果用 C 语言编写文件系统驱动模块，始终逃脱不了“体积”这一话题。不管是 GRUB 还是 GRUB2，如果要小到 30K，而不用汇编，那么这里面放置不了太多的文件系统驱动程序。GRUB legacy 虽然是无结构的，但是，也许从体积这个角度来看，无结构反而是一个优点了。而 GRUB2 的模块化、结构化，不一定能够带来代码的精简（在具有同样功能的前提下），相反，它还要消耗一些额外的代码空间。因此我的结论刚好相反：GRUB2 无助于压缩代码总量。 今天一直琢磨一个问题：做一个 mini grub ？？ 体积要小于32K，也就是能装进一个磁道 功能精简，只保留最基本的，splash 不要，磁盘仿真不要，中文支持不要 但要有搜索功能 这样设计，是针对 gnu grub lagecy 的缺点： gnu grub lagecy 的功能主体 stage2 文件存放于分区中，而且安装后其MBR引导代码被设置为从固定的分区加载stage2，不灵活，健壮性打了折扣 —— 一旦文件被误删，或分区被删除、格式化，或分区序号改变，将无法引导系统，连命令行都进不去，令人束手无策，必须借助急救盘等来恢复。而且修复起来步骤繁琐。 grub 几乎是每个新手都要过的一道关卡 而 mini grub 功能主体全在0磁道，即使启动失败，至少可以进入命令行。可以动态搜索硬盘上的 menu.lst 而不拘泥于某个特定分区。MBR 因重装 win 而被改写，也可以较容易地修复——无需指定 stage1.5 stage2 所在分区，重写一下 0 磁道即可，甚至可以更简单，只重写 mbr 即可。 限于体积，不可能支持太多文件系统，支持一两种即可。比如，可以默认支持 fat ，因为这种格式 win 、linux 都能读写；另一种可由用户指定，或根据 linux 根分区的文件系统格式自动装配。 有点像 grub2 ，但如不点兄所说，我们没有 grub2 那么多功能，体积可以更小 又像 gnu grub lagecy 写在 0 磁道的 stage1 + stage 1.5 ，不同的是，我们把 stage2 也写进去了 还可以融入之前 bean 设想过的 iboot 功能，作为一个桥梁，能加载各种引导器。 你们两位可能都没有注意看第 11 楼 uleak 所说的话。pt 所说的方法，和 uleak 说的基本是一回事。而且 uleak 说的更明白、更好、更彻底：uleak 说不仅 grub 能够精简后放在 grldr.mbr 中，而且还可以像现在的 grldr.mbr 一样自动搜索硬盘分区上的 GRLDR 文件，一旦找到，就启动硬盘分区上的 GRLDR 文件。也就是说，GRLDR.MBR 的功能一点都不减少，而是增加了一个功能，使得它自己本身就是一个微型的 GRUB。 这个当然是有可能实现的，而且技术上并不存在实质性的障碍。我最为头痛的，是硬件兼容性。和硬件兼容性相比，上面这些都不是难题。现在就开始做前期准备工作，把这一思路付诸实施。而其他别的工作，暂且都停下来不做了，由别人去做。 恩，还是有点区别，我的设想，重点在 GRUB 功能，也就是 首先 保证 0 磁道的代码有启动 LINUX 系统的能力，目标是克服 GNU GRUB LAGECY 的缺点 GRLDR.MBR 的功能 我也有提到， 引用: 原帖由 pt 于 2007-6-8 21:32 发表 还可以融入之前 bean 设想过的 iboot 功能，作为一个桥梁，能加载各种引导器。 但这是次要的，能实现最好，一时实现不了也没关系，因为毕竟功能越多代码就越大 先把 MINI GRUB 实现再说 —— 要求放低点，希望可以不用 汇编 那么费劲 这个其实就是我以前提到的miniboot (或者应该叫minigrub ?) 的功能，是可以实现的，不过有点麻烦。 由于大小限制，只保留文件系统访问和chianloader的功能，菜单转化为容易使用的形式，嵌入到启动文件中。整个loader的大小在8K以内，可以在NT管理启动启动，也可以安装到MBR。 bean: 8K 的代码只能用来搜索 GRLDR，不能再做别的事情了。如果 8K 不再搜索 GRLDR 了，当然可以拥有一点功能。不过，这好像也不会好到哪里去。我记得 Smart Boot Manager 就有 18K 之多，所以，如果限定 8K，则很难有功能性可言了。一个文件系统的驱动就能占据 8K。所以，8K 之中无法加入文件系统驱动（即使是汇编，也难）。但 30K 就应该可以了。相信将来有人改造 NTLDR，让它像 VISTA 那样可以装入 64K 的引导文件。 pt: uleak 的意思并没有说要减去一些重要的功能。可以启动 Linux， 这是当然应该支持的功能了。 其实8K也可以做不少事情了，以现在grldr.mbr为基础，把FAT12/16/32的处理合并，并且去掉前面BPB的空间，这样的话文件系统代码只占6个扇区的空间，其余扇区足够处理装载启动扇区，ntldr, grldr, io.sys等启动文件了。如果空间足够的话还可以处理linux内核和initrd。这样的话，基本上可以满足一般启动的要求了。而且，功能和大小不可能两者兼顾，如果要达到小的内核，就必须去掉一部分的功能。 顺便说一下，grub中最大的部分是builtins.c，编译后的有70多K，而最大的文件系统模块ntfs，编译后只有5K，因此如果不减少功能的话，很难把grldr缩小到30多K。 text data bss dec hex filename 15633 0 0 15633 3d11 pre_stage2_exec-asm.o 2945 0 0 2945 b81 pre_stage2_exec-bios.o 5355 0 1620 6975 1b3f pre_stage2_exec-boot.o 69167 1620 592 71379 116d3 pre_stage2_exec-builtins.o 4877 296 8 5181 143d pre_stage2_exec-char_io.o 1614 0 0 1614 64e pre_stage2_exec-cmdline.o 5391 392 16 5799 16a7 pre_stage2_exec-common.o 90 12 4 106 6a pre_stage2_exec-console.o 8081 360 68 8509 213d pre_stage2_exec-disk_io.o 2350 0 8 2358 936 pre_stage2_exec-fsys_ext2fs.o 2007 0 0 2007 7d7 pre_stage2_exec-fsys_fat.o 1384 0 12 1396 574 pre_stage2_exec-fsys_ffs.o 1347 0 0 1347 543 pre_stage2_exec-fsys_iso9660.o 2590 64 44 2698 a8a pre_stage2_exec-fsys_jfs.o 1390 0 12 1402 57a pre_stage2_exec-fsys_minix.o 5291 0 176 5467 155b pre_stage2_exec-fsys_ntfs.o 3173 4 212 3389 d3d pre_stage2_exec-fsys_pxe.o 3590 0 0 3590 e06 pre_stage2_exec-fsys_reiserfs.o 1729 0 28 1757 6dd pre_stage2_exec-fsys_ufs2.o 881 0 20 901 385 pre_stage2_exec-fsys_vstafs.o 3514 6 140 3660 e4c pre_stage2_exec-fsys_xfs.o 2622 16 4976 7614 1dbe pre_stage2_exec-graphics.o 4530 252 44920 49702 c226 pre_stage2_exec-gunzip.o 520 16 12 548 224 pre_stage2_exec-hercules.o 1803 16 96 1915 77b pre_stage2_exec-md5.o 1300 4 24 1328 530 pre_stage2_exec-serial.o 2010 240 548 2798 aee pre_stage2_exec-smp-imps.o 6742 0 32 6774 1a76 pre_stage2_exec-stage2.o 685 200 512 1397 575 pre_stage2_exec-terminfo.o 2368 2 964 3334 d06 pre_stage2_exec-tparm.o 8K 当然也有可能做好，但是，似乎难度较大。我们可以先把 30K 的做完，积累一点经验，如果发现 8K 的也可以搞定，再做 8K 的也不迟。这样做的好处有两点：一是可以有更大的成功把握，二是可以等待别人把一个 NTLDR 的替代品弄出来（让它载入 64K，而不是 8K。我估计一些 hacker 应该可以完成这个任务，到时候我们就可以省略做 8K 的这个步骤了）。做 30K 还有一个好处，那就是不再照顾低于 63 个扇区的 每磁道扇区数 了。这有助于促成大家都朝每道 63 个扇区靠拢。那些杂牌的 U 盘竟然使用每道 32 扇区，实在是一个遗憾。 微软的 NTLDR 已经是不再维护了，因此，这个产品就是大家的、是社区的了。我这么说虽然有点过分，但仔细想想，这其实也是实话。我因此相信有人会把它改造好（我希望情况会是这样的，就像 Wengier 改造 DOS 那样）。 |
|
你自己下载看下吧，好像在ASM.S里面有。 这是不点2012-6-10上传的。 http://bbs.wuyou.net/forum.php?m ... &fromuid=298214 wee的项目空间好像打不开了。源代码不点应该有吧。不知道后来chenall更新没有。 请问下新版wee在哪里下载 - GRUB4DOS - 无忧启动论坛 - Powered by Discuz! http://bbs.wuyou.net/forum.php?mod=viewthread&tid=272510 |
398.93 KB, 下载次数: 8, 下载积分: 无忧币 -2
| 可否把 list_partitions 函数源码贴上来? |
| 11111111111111111111111111111111111111111 |
| 码字好多，看起来研究很深入 |
Powered by Discuz! X3.3
© 2001-2017 Comsenz Inc.
组图打开中，请稍候......
收藏
支持
反对