无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
楼主: 窄口牛

我的硬盘gpt格式

  [复制链接]
 楼主| 发表于 2019-4-6 14:25:35 来自手机 | 显示全部楼层
还是不行,算了,放弃了,不折腾了。
回复

使用道具 举报

发表于 2019-4-6 14:43:24 | 显示全部楼层
2011yaya2007777 发表于 2019-4-6 14:13
我怀疑,是楼主又格式化了。真好强行占用了2扇区分区表,一格式化就把前2扇区清零了。

一件事出来以后,可能性有很多。比如:

1、流氓软件造成的问题。
2、其他分区软件、格式化软件造成的问题。
3、主板 BIOS 造成的问题。
4、用户自己造成的问题。
5、bootlace 的 bug。

既然报告者放弃了,那么,假如你能确定这不是 bootlace 的 bug,我认为,这个问题就不必再探究了。可以等待以后有别人再报告 bug 时,再去研究它。
回复

使用道具 举报

发表于 2019-4-6 14:52:32 来自手机 | 显示全部楼层
好吧。暂时搁置。
回复

使用道具 举报

发表于 2019-4-6 14:56:48 | 显示全部楼层
2011yaya2007777 发表于 2019-4-6 14:13
我怀疑,是楼主又格式化了。真好强行占用了2扇区分区表,一格式化就把前2扇区清零了。

还有一种可能性,如果你正好写到主板或 Windows  “不喜欢” 让你写的地方(比如它用 “校验和”进行检查,发现那个区域的校验和不正确),它就可能认为你写的是非法的,于是它自动重建分区表,看起来就像重新格式化了一样。

报告者应该在执行 bootlace 之后,立即截取扇区数据,这样才知道是不是写入了完整的代码。如果重启之后才截取,那就不知道是谁破坏了前 2 个扇区了,正如上面列举的那些可能性一样。
回复

使用道具 举报

发表于 2019-4-6 15:10:22 来自手机 | 显示全部楼层
分区表从0x400_0x43ff。而安装代码起始于0x4000。不点说的有可能。希望楼主能帮忙把此技术问题搞清楚。
回复

使用道具 举报

 楼主| 发表于 2019-4-6 15:24:42 来自手机 | 显示全部楼层
本帖最后由 窄口牛 于 2019-4-6 15:33 编辑

在linux下怎么截取?我不会,win下用bootice备份的。

台式机上也是这样的
QQ五笔截图未命名.jpg
回复

使用道具 举报

发表于 2019-4-6 15:35:12 来自手机 | 显示全部楼层
你这个盘第二硬盘?在linux下安装,在windows下截取。最好不要从这个盘重启。
回复

使用道具 举报

 楼主| 发表于 2019-4-6 15:37:15 | 显示全部楼层
台式机上是多硬盘,二合一本上是一块硬盘。
那我在二合一上用优盘搞搞。
回复

使用道具 举报

发表于 2019-4-6 15:37:30 来自手机 | 显示全部楼层
windows扫描磁盘的话,不要让他扫描,或者修正
回复

使用道具 举报

发表于 2019-4-6 15:42:21 来自手机 | 显示全部楼层
在windows下截取64扇区,保存为gpt.bin。在命令行执行:bootlace  --gpt  gpt.bin,然后把这个文件再复制到磁盘开头,就安装妥了。
回复

使用道具 举报

 楼主| 发表于 2019-4-6 15:50:28 | 显示全部楼层
rr.bin.txt (32 KB, 下载次数: 11)
回复

使用道具 举报

发表于 2019-4-6 16:05:05 来自手机 | 显示全部楼层
我猜测你执行的步骤,看看对不对:1. 从硬盘启动,进入linux,向U盘安装grldr_mbr。  2. 重启进入硬盘,截取U盘扇区。   以上是本次要求做的。   猜猜以前是不是安装完毕,直接从U盘启动,就出现你截图所示状态?   另外,你用dg做了什么?是在哪个阶段做的?
回复

使用道具 举报

发表于 2019-4-6 16:09:00 来自手机 | 显示全部楼层
我格式化磁盘,第一分区位于0x800扇区,而你的位于0x30扇区。可以自行调整吗?
回复

使用道具 举报

 楼主| 发表于 2019-4-6 17:17:28 | 显示全部楼层
我操作的是硬盘,优盘做成gpt是不行的,因为微软不允许gpt格式里的wim(分区系统也一样)从legacy方式启动,而反过来是可以的,也就是mar的优盘里wim可以efi也可以legcay启动。至于编辑开始扇区那个我不会操作。
回复

使用道具 举报

 楼主| 发表于 2019-4-6 17:19:47 | 显示全部楼层
一般人用任何分区工具分好区都不会再操作什么,我却用dg修改已经分好区的部分大小,就会发现那些分区前后会有“空隙”,我会把它们都变成0,就是有这个操作。
回复

使用道具 举报

发表于 2019-4-6 17:37:37 | 显示全部楼层
我主要是想搞清楚 0x4000 处的 2 扇区是怎么清零的。
你没有正面回答我的问题。我只好猜测如下,如果不对,你指正。
从硬盘或者U盘启动,进入硬盘或者U盘的 linux 系统,向已经格式化为 gpt 格式的硬盘安装 grldr_mbr 代码。
之后重启,不能启动,如你的截图所示。那之后如何进硬盘?是在硬盘还是U盘截取的 55.bin?
回复

使用道具 举报

 楼主| 发表于 2019-4-6 17:43:49 来自手机 | 显示全部楼层
正常是efi引导,测试的时候才会改为legacy,或者用qemu启动测试工具测试。不存在不能启动而影响到进系统的问题。你得问题我不懂,所以回答不了。
回复

使用道具 举报

 楼主| 发表于 2019-4-6 17:48:42 来自手机 | 显示全部楼层
你可以自己试试我的操作,就应该能复现,就是用dg分区,分好以后,再按住分区选择修改大小或移动,然后把分区开头和分区末尾的数字都修改成0,就是我说的清理“空隙”。然后再写入,就应该是我的这种情况了。
回复

使用道具 举报

发表于 2019-4-6 17:51:00 | 显示全部楼层
GPT 我不懂,只是根据你们提供的线索瞎猜。

楼上 frg521 说,gpt 最少扇区数是 34,即 0x22 个。

yaya 说,0x4000 处的 2 扇区被清零。这个 0x4000 正好是 32 扇区,从这里开始的 2 个扇区,正好在 34 扇区之内。因此,我猜,它被某种规范(或者系统)清零了。
回复

使用道具 举报

发表于 2019-4-6 18:00:37 | 显示全部楼层
继续瞎猜——

那个区域是放分区表的地方?是不是不允许放代码?是不是因此之故,yaya 放置在那里的代码就被强制清零了?

也许是主板给它清零了,也许是 Windows 下的某个工具(例如 dg 之类的)给它清零了?
回复

使用道具 举报

发表于 2019-4-6 18:05:34 | 显示全部楼层
我就是想知道,楼主安装成功 grldr_mbr 之后,到出现下面这个提示之前,还做过什么?可以说的详细一些。

QQ五笔截图未命名.jpg
回复

使用道具 举报

发表于 2019-4-6 18:25:04 | 显示全部楼层
按照 frg521 所说,分区表的空间是不允许写入代码的。有可能是被主板清零的。

yaya 有没有更新校验和?如果没更新,我猜肯定是不行的。即使更新了校验和,主板也不一定允许尾部存放代码。分区表的区域,是不可以存放代码的,正如 MBR 的分区表,也是不允许存放代码(空闲的分区表,也要保持为 00 字节,不允许用作别的用途)。

就算是后来重启动以后由 Windows 清零的,那也没办法。不管是主板,还是 Windows,都算是必须遵守的规范。作为第三方的工具,必须适应这些规范才行。

我猜应该是主板把它清零的吧?主板发现 GPT 校验和不对,判定为非法,于是从备份的 GPT 那里复制过来扇区,覆盖掉了当前的 GPT 扇区。谢谢 frg521 的介绍,让我能凭空发表这么多文字。
回复

使用道具 举报

发表于 2019-4-6 18:26:48 | 显示全部楼层
gpt分区表里面写入数据是非法的,因为有校验和

没注意分区表有校验和。看来代码只能安装到间隙里。楼主费事得把间隙调整为0了。

选择对齐为xx,结果必须是大于或等于50也是0x32,才能安装下代码(代码16扇区)。

点评

人多力量大,找到原因就好。 让分区对齐为 32 扇区(而不是对齐为 16 扇区),那么,34 扇区对齐为下一个 32 的整数倍,那就是 64 了,这就满足 yaya 所要求的 “至少 50 扇区”的条件了。  详情 回复 发表于 2019-4-6 18:37
回复

使用道具 举报

发表于 2019-4-6 18:37:39 | 显示全部楼层
2011yaya2007777 发表于 2019-4-6 18:26
没注意分区表有校验和。看来代码只能安装到间隙里。楼主费事得把间隙调整为0了。

选择对齐为xx,结果 ...

人多力量大,找到原因就好。

让分区对齐为 32 扇区(而不是对齐为 16 扇区),那么,34 扇区对齐为下一个 32 的整数倍,那就是 64 了,这就满足 yaya 所要求的 “至少 50 扇区”的条件了。
回复

使用道具 举报

发表于 2019-4-6 19:00:36 | 显示全部楼层

如果 GPT 占用 34 扇区,那么,把它对齐为 32 扇区,就是 64 扇区。也就是说,如果让第一个分区起始于 64 扇区,那么,yaya 的 16 扇区代码,就能够放在 34 至 64 之间的空闲空间上了。

要么干脆就让第一扇区起始于 2048 扇区——多省事啊,就不会出问题了。

yaya 前面也提到了,在第一扇区也放置有一些引导代码,用来加载并跳转到这 16 扇区的代码。
回复

使用道具 举报

发表于 2019-4-6 21:31:39 | 显示全部楼层
分区表头 (LBA 1),前 92 字节有 CRC32 校验。
分区表项 (LBA 2–33),没有  CRC32 校验。

主板及 windows 没有自动纠正分区表项。一般有错的时候要纠正,也会提示询问的。

在 DiskGenius,当选择 gpd 格式的磁盘时,提示 “DUID主分区表数据CRC错误”,点“更正”,清除 0x4000 之后代码。

点评

根据你的描述,如果我理解正确的话,你是说,diskgen 会纠正分区表的错误,也就是说,把分区表尾部两个扇区的 grldr.mbr 代码清除掉了。 diskgen 这么做,我想,大概不会是毫无根据的。它可能是按照规范去做的。  详情 回复 发表于 2019-4-7 00:43
回复

使用道具 举报

发表于 2019-4-7 00:43:33 | 显示全部楼层
2011yaya2007777 发表于 2019-4-6 21:31
分区表头 (LBA 1),前 92 字节有 CRC32 校验。
分区表项 (LBA 2–33),没有  CRC32 校验。

根据你的描述,如果我理解正确的话,你是说,diskgen 会纠正分区表的错误,也就是说,把分区表尾部两个扇区的 grldr.mbr 代码清除掉了。

diskgen 这么做,我想,大概不会是毫无根据的。它可能是按照规范去做的。也就是说,这里很可能有一个 CRC 校验,来校验分区表。

你提到主板没有自动纠正分区表项,我猜你很可能是说你遇到的主板不纠正。从严谨的逻辑来考虑,那么别人的主板,倒是有可能自动纠正。

这个 CRC 分区表校验如果确实是个规范的话,那就可能被各种软件纠正,只要那些软件严格遵从规范。
回复

使用道具 举报

发表于 2019-4-7 00:59:02 | 显示全部楼层
没有在windows下写入GPT或MBR的程序吗? 只编写 linux 用的 工具?

bootlace 工具只能在实模式的 DOS 下以及保护模式的 Linux 下,才能写入设备,不支持在 Windows 下写入设备。

由于 DOS 已经不可靠了(原因是 BIOS 不可靠了,这是另外一个很长很长的话题,此处略去),所以只能在 Linux 下操作。

话说这年月,进入 Linux 也并不是很奇葩的一件事,用一个 U 盘即可进入 Linux 来执行必要的操作。

回复

使用道具 举报

发表于 2019-4-7 06:59:21 | 显示全部楼层

我多年没参与开发了,手头没有现成的扇区数据用来安装。
在我开发维护期间,我在 readme 文件里面详细描述了如何手动把 GRLDR.MBR 写入硬盘。不过,那时只支持 mbr 格式,不支持 GPT 格式。

yaya 让 bootlace 以及 GRLDR.mbr 支持gpt格式,非常好。我猜它的结构是,第一扇区有固定不变的代码以及一个可变的起始扇区号,用来指示 后续的 16扇区在哪里。你可以看看 readme是否已经有说明了。如果readme没有提到 gpt,那就是没有更新 readme。
写入gpt与写入 mbr 是不同的。mbr 格式简单,而 gpt 复杂一些。
让 yaya 帮你吧。
回复

使用道具 举报

发表于 2019-4-7 08:54:36 | 显示全部楼层
本帖最后由 2011yaya2007777 于 2019-4-7 09:22 编辑

前面关于CRC的表述不正确。更正如下:
分区表头 (LBA 1),前 92 字节的 CRC32 校验,在分区表头的第 16 字节。
分区表项 (LBA 2–33),其串行的 CRC32 校验,在分区表头的第 88 字节。

关于楼主的硬盘在 linux 环境下不能安装 grldr_mbr 的代码,其原因准确表述如下:
1. 由于楼主使用 DG 调整了分区间隙,使其为零,grldr_mbr 代码便失去了在此地安装的空间。
2. 由于楼主设定 GPT 分区对齐为 16 扇区,故使第一分区位于 48 扇区,与可用起始扇区(34扇区)之间只有 14 扇区,不够安装 grldr_mbr 代码(需16扇区)。
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-3-29 14:48

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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