无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
楼主: pseudo
打印 上一主题 下一主题

[原创] 分区表项法——使ud或U+深藏区中8PE能EFI启动的一种简单方法

    [复制链接]
61#
发表于 2014-3-28 21:52:28 来自手机 | 只看该作者
这个可以叫做物理map,GRUB4DOS的可以叫软件map,这个东西的缺点是文件不能有碎片和文件不能移动
回复

使用道具 举报

62#
发表于 2014-3-29 00:06:44 | 只看该作者
本帖最后由 chiannet 于 2014-3-29 00:35 编辑





鸡蛋里面挑骨头:我被上图中“any ohter key”摆了一道,按一般理解,是指除<ESC>之外键盘上的随意一个按键都继续执行下一步,其实在这里只有按回车键才能得到如下图的“OK!!!”,而按方向键貌似得不到“OK!!!”,p大能否稍稍改进?非常赞叹P大的奇思妙想,P大绝对是此地球第一个想到这个方法且实现该想法的人!


此外提个小小建议,作为给向我一样的普通人使用,那个显示出来的parttion table代码就是天书,干脆不显示吧。
给大众使用的只显示批处理运行的最终结果:成功或失败。
而给高级用户或开发版本显示那些中间信息一下可能较好。




回复

使用道具 举报

63#
发表于 2014-3-29 08:25:57 | 只看该作者
再反馈一个可能比较大的问题:

在启用了分区表项法的UD上,下列命令第二条失效,只能带--force参数格式化UD了(第一条可行),这意味着必须清除UD及UD外的全部数据,但我们多数时候只想按第二种方式执行,P大,此问题有解?

  1. cd /d "%~dp0"

  2. rem 格式化整个HD1
  3. fbinst.exe (hd1) format --extended 500MB --primary 8m --force --fat32 --archive %cd%\fb.fba

  4. rem 保留非UD区数据,仅格式化UD区
  5. fbinst.exe (hd1) format --extended 500MB --primary 8m --archive %cd%\fb.fba

复制代码

点评

先备份启用了分区表项法之前UD的分区表,保存为UD中的一个文件。 fbinst格式化之前,还原备份的分区表。 是否可行?  详情 回复 发表于 2014-3-29 08:29
回复

使用道具 举报

64#
发表于 2014-3-29 08:29:51 | 只看该作者
本帖最后由 chiannet 于 2014-3-29 08:31 编辑
chiannet 发表于 2014-3-29 08:25
再反馈一个可能比较大的问题:

在启用了分区表项法的UD上,下列命令第二条失效,只能带--force参数格式 ...


先备份开启“分区表项法”之前UD的分区表,保存为UD中的一个文件。
fbinst格式化之前,还原备份的分区表。

是否可行?
回复

使用道具 举报

65#
发表于 2014-3-29 08:57:09 | 只看该作者
在启用了分区表项法的UD上,只能带--force参数格式 ...,碎片整理后必须从新更新分区表.

以上这些对下版fbinsttool 将都不是问题。看来fbinst的第二春要来了

点评

可否考虑额外设置三个扩展分区,附着在UD扩展分区尾部的固定位置,这样碎片整理或者添加文件后后就不用每次更新分区表了。这样在格式化后就可以知道文件的具体位置,后期就不需要在调整分区参数了  详情 回复 发表于 2014-3-30 14:02
J大,更新fbinsttool时,一定记得顺道更新一下命令行版的fbinst哦  详情 回复 发表于 2014-3-29 09:04
拽呀,就等各位大大更新了。要是PECMD执行速度能提快一点  详情 回复 发表于 2014-3-29 08:59
回复

使用道具 举报

66#
发表于 2014-3-29 08:59:13 | 只看该作者
jianliulin 发表于 2014-3-29 08:57
在启用了分区表项法的UD上,只能带--force参数格式 ...,碎片整理后必须从新更新分区表.

以上这些对下版 ...


拽呀,就等各位大大更新了。


要是PECMD执行速度能提快一些,就能直接在windows下实现P大的思路了。
回复

使用道具 举报

67#
发表于 2014-3-29 09:04:52 | 只看该作者
支持p大的新作,继续完善......
回复

使用道具 举报

68#
发表于 2014-3-29 09:04:58 | 只看该作者
jianliulin 发表于 2014-3-29 08:57
在启用了分区表项法的UD上,只能带--force参数格式 ...,碎片整理后必须从新更新分区表.

以上这些对下版 ...

J大,更新fbinsttool时,一定记得顺道更新一下命令行版的fbinst哦
回复

使用道具 举报

69#
发表于 2014-3-29 09:14:32 | 只看该作者
J大P大强强联手,UD隐藏+UEFI第二春。
回复

使用道具 举报

70#
 楼主| 发表于 2014-3-29 10:32:07 | 只看该作者
要是J大能在fbinsttool里加个功能就方便大家了:
右键点ud扩展区里非压缩的.img(或近似后缀)文件,出选项:建(U盘)对应分区表项、清(U盘)对应分区表项。


回复

使用道具 举报

71#
 楼主| 发表于 2014-3-29 10:43:20 | 只看该作者
@chiannet
先清对应分区表项,再正常格式化,没--force参数问题。整理过碎片后,要再刷新分区表项。

原来执行环境是先执行过debug off命令的,可屏蔽杂乱屏幕输出。

你那边成功了吧。估计我弄的8pe.img有问题,你试试用这个img行不?帮我弄个好的img吧。

点评

请示下在windows下有何简便易行可靠的请分区表项方法?PECMD?  详情 回复 发表于 2014-3-29 14:25
在有限范围内测试,vm虚拟机及本地实际机器(笔记本)测试没问题。我的IMG使用winimge命令行方式添加相关文件。在测试范围内没发现问题。 我用你的8PE.img也成功BIOS+UEFI(虚拟机+实器)。  详情 回复 发表于 2014-3-29 14:12
回复

使用道具 举报

72#
发表于 2014-3-29 11:51:18 | 只看该作者
M大,J大,P大,三强出马,有新戏了~~~
回复

使用道具 举报

73#
发表于 2014-3-29 14:12:29 | 只看该作者
pseudo 发表于 2014-3-29 10:43
@chiannet
先清对应分区表项,再正常格式化,没--force参数问题。整理过碎片后,要再刷新分区表项。


在有限范围内测试,vm虚拟机及本地实际机器(笔记本)测试没问题。我的IMa是使用winimge命令行方式添加相关文件动态生成。在测试范围内没发现问题。

我用你的8PE.img也成功BIOS+UEFI(虚拟机+实器)。
回复

使用道具 举报

74#
发表于 2014-3-29 14:25:43 | 只看该作者
pseudo 发表于 2014-3-29 10:43
@chiannet
先清对应分区表项,再正常格式化,没--force参数问题。整理过碎片后,要再刷新分区表项。


请示下在windows下有何简便易行可靠的清分区表项方法?PECMD?

回复

使用道具 举报

75#
发表于 2014-3-29 15:32:55 | 只看该作者
有一键化的工具吗?
回复

使用道具 举报

76#
发表于 2014-3-29 17:03:23 | 只看该作者
向P大学习了,这是一个好方法,既可以延续UD的优点,又给UD注入了新的生机。感谢P大不懈的努力。
回复

使用道具 举报

77#
 楼主| 发表于 2014-3-29 17:57:35 来自手机 | 只看该作者
@chiannet 谢谢。这样虚拟机、实机都有成功先例了。  diskpart清个分区应该不难。
回复

使用道具 举报

78#
发表于 2014-3-30 01:44:54 | 只看该作者
看了一遍,貌似领悟原理了,P大牛逼啊。
回复

使用道具 举报

79#
发表于 2014-3-30 12:46:00 来自手机 | 只看该作者
顶 支持一个
回复

使用道具 举报

80#
发表于 2014-3-30 13:48:49 | 只看该作者
分区表一共可以容纳4个主分区,可以全部利用起来
回复

使用道具 举报

81#
发表于 2014-3-30 14:02:38 | 只看该作者
本帖最后由 2010ihotte 于 2014-3-30 14:05 编辑
jianliulin 发表于 2014-3-29 08:57
在启用了分区表项法的UD上,只能带--force参数格式 ...,碎片整理后必须从新更新分区表.

以上这些对下版 ...


可否考虑额外设置三个扩展分区,附着在UD扩展分区尾部的固定位置,这样碎片整理或者添加文件后后就不用每次更新分区表了。

这样在格式化的时候就可以计算文件的具体位置,后期就不需要重新计算调整分区参数了
回复

使用道具 举报

82#
 楼主| 发表于 2014-3-30 17:26:07 | 只看该作者
目前添加文件并不用刷新分区表项,整理碎片才要。分区表项维护代价并不大。

已考虑了利用4个分区的其余分区,生成分区表项时就可指定第几分区。
例如,ud里可以放一个64位pe映像、一个32位pe映像,分别生成对应对应(hd0,1)、(hd0,2)的分区表项。这样32位、64位efi启动都解决了。
总之,可以灵活应用。

点评

如果仅从32位、64位efi启动的这个问题考虑,并不需要惊动多至两个分区(hd0,1)、(hd0,2),只需从IMG内部就能搞定。  详情 回复 发表于 2014-3-30 19:33
回复

使用道具 举报

83#
发表于 2014-3-30 19:33:38 | 只看该作者
pseudo 发表于 2014-3-30 17:26
目前添加文件并不用刷新分区表项,整理碎片才要。分区表项维护代价并不大。

已考虑了利用4个分区的其余 ...

如果仅从32位、64位efi启动的这个问题考虑,并不需要惊动多至两个分区(hd0,1)、(hd0,2),只需从IMG内部就能搞定。

点评

从维护来说,多分区方便  发表于 2014-3-31 10:43
单纯用一个可以解决但是制作、测试会很麻烦。。再有Win8_UEFI体积都较大每次打包费时费力  详情 回复 发表于 2014-3-31 05:52
是的,合盘就可以搞定。分区越简单越好,复杂了会影响兼容性  详情 回复 发表于 2014-3-30 19:40
回复

使用道具 举报

84#
发表于 2014-3-30 19:40:21 | 只看该作者
本帖最后由 zds1210 于 2014-3-30 20:05 编辑
chiannet 发表于 2014-3-30 19:33
如果仅从32位、64位efi启动的这个问题考虑,并不需要惊动多至两个分区(hd0,1)、(hd0,2),只需从IMG内部就 ...


是的,合盘就可以搞定。分区越简单越好,复杂了会影响兼容性
关键是grub脚本是怎么生成这个启动分区项的,P大能不能共享一下,大家来实现到自己的PE中。

点评

作为一种新生的解决方案要综合考虑各种情况,不能禁图当下之快。。就像BIOS分区规范一样要是当时把扇区调整为1K,也不至于搞到现在这个样子  详情 回复 发表于 2014-3-31 05:55
回复

使用道具 举报

85#
 楼主| 发表于 2014-3-30 21:24:25 | 只看该作者
多了一些选择,灵活运用吧。

g4d脚本在0penb.lzma里,一直开源共享的。从#64楼看也能用于其它pe。
后面可能会有高人提供windows下现成工具。
回复

使用道具 举报

86#
发表于 2014-3-30 22:32:13 | 只看该作者
本帖最后由 zds1210 于 2014-3-30 22:33 编辑

这样子好的帖子,应该加精加亮。版主去哪里了?
同时初步测试了P大的最新PE,不解开Ud和U+深度隐藏,感觉强大,还集成了新的8PE.
回复

使用道具 举报

87#
发表于 2014-3-30 23:43:04 | 只看该作者
高手云集,有好戏看了...........................
回复

使用道具 举报

88#
发表于 2014-3-31 05:52:53 | 只看该作者
chiannet 发表于 2014-3-30 19:33
如果仅从32位、64位efi启动的这个问题考虑,并不需要惊动多至两个分区(hd0,1)、(hd0,2),只需从IMG内部就 ...

单纯用一个可以解决但是制作、测试会很麻烦。。再有Win8_UEFI体积都较大每次打包费时费力
回复

使用道具 举报

89#
发表于 2014-3-31 05:55:46 | 只看该作者
zds1210 发表于 2014-3-30 19:40
是的,合盘就可以搞定。分区越简单越好,复杂了会影响兼容性
关键是grub脚本是怎么生成这个启动分区项 ...

作为一种新生的解决方案要综合考虑各种情况,不能禁图当下之快。。就像BIOS分区规范一样要是当时把扇区调整为1K,也不至于搞到现在这个样子
回复

使用道具 举报

90#
发表于 2014-3-31 06:24:31 | 只看该作者
新版参考方案图示

点评

http://bbs.wuyou.com/forum.php?mod=viewthread&tid=329785&extra=page%3D1  详情 回复 发表于 2014-3-31 09:28
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-11-17 12:37

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表