升级硬盘后,GRUB挂在菜单之前。 如何debugging?

我在运行Debian wheezy的4 x 1 TB驱动器的服务器上遇到问题,GRUB 1.99-27 + deb7u3。

sda和sdb都有使用(Linux软件)RAID1镜像的分区,包括/boot 。 sdc和sdd每个都有一个分区,镜像一个LVM物理卷的数据。 GRUB安装到sda和sdb。 我使用了mdadm ,并且 – --fail了1 TB sdc,并用新的2 TB ST2000NX0243replace了旧的驱动器(ST91000640NS)。

随着新的驱动器,GRUB得到了

 GRUB loading. Welcome to GRUB! 

但未能显示菜单。 sdc上的驱动器指示灯持续点亮,所以大概GRUB内核正在尝试读取该驱动器,即使不需要访问/ boot / grub。 我已经尝试了两个相同型号的驱动器,两者都使用smartctl进行testing,结果相同。 随着sdc驱动器托架空,一切正常启动。 系统从实时USB引导,新驱动器可访问,所以它不是硬件不兼容(*)。 我确定这是sdc被删除,并没有迹象表明BIOS重新sorting的驱动器。

(*) 这可能不是一个安全的假设。 查看答案。

所以我有以下相关的问题:

  1. 更改的逻辑扇区大小(4096而不是512字节)是否会引起问题,可能是GRUB内核中的RAID支持? 为什么我至less得不到grub rescue>提示? 一个4K的问题也可以防止使用该驱动器的Linux RAID?
  2. 什么是解决这个问题最快捷的方法? [以前的build议包括:我是否需要重新安装GRUB,并在这种情况下如何? 一个GRUB救援USB(由同一个系统制造)有同样的问题? 这是GRUB中的一个已知错误,我应该升级吗? 这些答案似乎是:不,是和否。]我可以永久configurationDebian使用的GRUB映像前缀吗?
  3. 如何去debuggingGRUB的这个阶段? 它可能对内置的模块很敏感,但是如何find这个模块呢?

我正在考虑一个debug.cfg只是debug=all和类似的东西:

 grub-mkimage -c debug.cfg -o dcore.img configfile normal raid fs multiboot grub-setup -c dcore.img /dev/sda 

这会工作吗? (我在我自己的答案中解决了这一点,但是在我的情况下,似乎在embedded式configuration被执行之前发生了这种情况。)

更多的系统细节

如果它帮助可视化,这里是lsblk输出的一部分:

 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 931.5G 0 disk ├─sdb1 8:17 0 957M 0 part │ └─md0 9:0 0 956.9M 0 raid1 /boot ├─sdb2 8:18 0 9.3G 0 part │ └─md1 9:1 0 9.3G 0 raid1 / ├─sdb3 8:19 0 279.4G 0 part │ └─md2 9:2 0 279.4G 0 raid1 /var └─sdb4 8:20 0 641.9G 0 part └─md3 9:3 0 641.9G 0 raid1 ├─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home └─vg0-swap (dm-2) 253:2 0 32G 0 lvm [SWAP] sdc 8:32 0 931.5G 0 disk └─sdc1 8:33 0 931.5G 0 part └─md4 9:4 0 931.5G 0 raid1 └─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home sdd 8:48 0 931.5G 0 disk └─sdd1 8:49 0 931.5G 0 part └─md4 9:4 0 931.5G 0 raid1 └─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 957M 0 part │ └─md0 9:0 0 956.9M 0 raid1 /boot ├─sda2 8:2 0 9.3G 0 part │ └─md1 9:1 0 9.3G 0 raid1 / ├─sda3 8:3 0 279.4G 0 part │ └─md2 9:2 0 279.4G 0 raid1 /var └─sda4 8:4 0 641.9G 0 part └─md3 9:3 0 641.9G 0 raid1 ├─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home └─vg0-swap (dm-2) 253:2 0 32G 0 lvm [SWAP] 

这是2010年之前的BIOS,没有EFIfunction。

不相关的:在运行的系统上,下面给出了与grub-probe 1.99相同的LVM错误,虽然一切似乎都起作用(这在GRUB 2.02中似乎已经修复了)。

 # grub-fstest /dev/sda cp '(loop0,msdos1)/grub/grub.cfg' grub.cfg error: unknown LVM metadata header. 

以下答案中的debugging方法显示正在安装到sd [ab]的映像的前缀是:

 grub-mkimage -d /usr/lib/grub/i386-pc -O i386-pc --output=/boot/grub/core.img '--prefix=(mduuid/<UUID of sdN1>)/grub' biosdisk ext2 part_msdos part_msdos raid mdraid09 

我不知道为什么'part_msdos'重复。 没有gpt表。 md0(引导)使用RAID超级版本0.9,与md1,md2和md4(这些是旧数组)一样。 md3是超级1.2,但不应该参与启动。


更新

感谢迄今为止的build议。 进一步testing之后:

  • BIOS已经设置为使用sda(ata1.00)启动。 使用dpkg-reconfigure grub-pc将GRUB重新安装到所有驱动器之后,没有任何更改,并且在新的驱动器通过SATA连接时GRUB仍挂在菜单之前。 无论如何,这不可能由/ boot / grub内容不匹配核心映像。 同样,物理重新安排驱动器没有区别。
  • 在Debian Jessie中将GRUB升级到2.02只会产生Welcome to GRUB! 消息不会被打印出来,而是会改变graphics模式。 它仍然挂在相同的条件下。
  • 挂起似乎发生在embedded式configuration设置debugvariables之前。 没有有用的debugging信息被发射。
  • 从可移动介质启动时,GRUB会显示一个菜单,其中前缀不使用UUID,这样可以通过物理驱动器启动系统。 但是,TAB枚举的驱动器冻结。 正如所料,从硬盘链GRUB挂载像以前一样挂起。 从同一系统的grub-mkrescue制作的USB驱动器启动也会挂起。
  • 作为一个单独的故障,在实时系统(Linux 3.2.0-4-amd64)上,尝试将新的4Kn驱动器添加到RAID1arrays,无论是通过内部的SATA还是USB都会导致设备上Bad block number requested ,随后md系统失败的驱动器, BUG: unable to handle kernel paging request和内核oops。 ( mdadm --remove表示失败的元素正在忙,md-resync进程没有响应SIGKILL,我没有尝试echo frozen > /sys/block/mdX/md/sync_action 。一切都显得很好)。 当然,Linux的MD驱动程序能够与旧的驱动器同步一个4Kn dtive而不使用BIOS?

因此,解决方法可能包括将非RAID分区挂载为/boot/ ; 用设备依赖的前缀来安装GRUB; 或刷新BIOS。 最明智的事情可能是联系供应商交换驱动器。

换句话说,问题3有一个解决scheme,其效率可能受到GRUBfunction请求的影响; 问题二是吠叫错了树,所以我修改了它; 和问题1,如果不是太远离主题,现在另外说明为什么驱动器显然不能用于Linux RAID。

我会很高兴奖励这个任何这样的一个体面的解释,关于RAID重新同步错误,或使用flashrom轶事4Kn支持,如何告诉grub安装不使用UUIDs或任何相关的系统pipe理员提示。

我将回答我的问题的第三部分,介绍在启用debugging的情况下安装GRUB的过程。 我仍然希望得到关于麻烦可能出在哪里的知情build议,或者在最短的停机时间和最大的原因信息下解决的策略。


一些常规要点:GRUB提供了其他debugging方法 – grub-mkrescue将生成一个.iso文件,其中包含您可能需要内置的所有模块,因此可以使用实时USB来尝试导航RAIDarrays并尝试加载.cfg文件甚至是内核。 grub-emu模拟器在大多数发行版中都是可用的,但更多的是面向菜单的外观。 更高级的是标准GRUB模块,用于通过串行电缆使用gdb进行debugging 。

在启用debugging的情况下安装GRUB的过程

因此,获取debugging消息的过程在GRUB手册的第6部分中提到,但没有详细介绍。 您可能要考虑的第一件事情是在串行控制台上进行debugging,并在screen前运行script来loggingdebugging消息。 显然你需要root权限。 请注意,在这个答案中的驱动器布局不一定匹配的问题,只是一个例子。 假设正常的(非debugging)GRUB被安装到其他驱动器上,这只是将debuggingGRUB安装到希望引导的驱动器上的过程。 (这意味着debugging消息可以明确哪个驱动器正在引导。对于安装到RAID分区,在这两种情况下,前缀可能是相同的,所以您可以像/dev/sdb一样对/dev/sda运行相同的命令。)

首先,检查现有的grub文件, /boot/grub或更可能的/boot/grub/<platform> 。 在这种情况下,假设它们在/boot/grub/i386-pc/ 。 我们不会修改已经存在的文件,但是在debugging启用的情况下添加一个额外的核心映像。 如果.cfg文件丢失或被修改,请使用grub-mkconfig -o /boot/grub/grub.cfg其重新生成。

检查已安装的模块和前缀

显示哪些模块已经被编译到核心映像中的快速和肮脏的方法是再次运行grub-install 。 这在GRUB 2.02中有效:

 grub-install -v /dev/sda 2>&1 | grep '\(mkimage\|setup\)' 

在没有RAID或lvm的简单情况下,这可能会显示像ext2 part_gpt biosdisk这样的列表。 但是,GRUB 1.99不使用-v作为详细信息,所以请使用--debug 。 我们将结合这个技巧来实际上不安装图像,以节省一点时间:

 grub-install --debug --grub-setup=/bin/true /dev/sda 2>&1 | grep '\(-mkimage\|-setup\|true\)' 

请注意, grub-install可以运行shell脚本来代替它所调用的程序,所以我们可以这样做:

 # create grub-mkimage wrapper cat > /usr/local/bin/grub-mkimage.sh <<"EOF" echo Arguments to grub-mkimage: $* /usr/bin/grub-mkimage $* EOF # create a dummy grub-setup cat > /usr/local/bin/grub-setup.sh <<"EOF" #!/bin/bash echo Arguments are: $* EOF # run grub-install using the above chmod u+x /usr/local/bin/grub-*.sh grub-install --grub-mkimage=/usr/local/bin/grub-mkimage.sh \ --grub-setup=/usr/local/bin/grub-setup.sh /dev/sda 2>&1 \ | grep 'Arguments' | tee grub-args.txt 

path当然可能会根据您的分布和select的shell而有所不同。

设置debuggingvariables

我们现在创build一个文件,我们可以通过debugging设置调用debug.cfg 。 (如果在这个阶段遇到注释,核心会产生一个非致命的错误,所以我们不会使用任何。

 set pager=1 set debug='init modules disk ata,scsi,linuxefi,efi,badram,drivemap linux,fs,elf,dl,chain serial,usb,usb_keyboard,video' set 

任何空白,,,的组合;| 可以用来分隔string中的模块名称。

我从GRUB 2.02源文件中提取了debugging工具列表,并对它们进行语义sorting。 'all'会从scripting解释器中产生太多内存信息。 对于特定的文件系统,如'xfs'和'reiserfs',以及'net','partition'和'loader',还有额外的function(对于我们感兴趣的菜单,可以得到一个菜单,我们可以在那里设置debuggingvariables。)不幸的是,在'mdraid_linux'源文件中没有debugging消息,但是disk显示了最重要的操作。

如果您不通过控制台捕获debugging消息(例如使用script ),则需要使用pagervariables来读取debugging消息。 我发现pager不工作,没有包括一个额外的模块,如sleep或configuration文件,这是图像的大小的两倍多。 debugging环境variables无论如何生效。

安装

现在制作一个你想debugging的图像:

 grub-mkimage -p '(,msdos3)/boot/grub' -c debug.cfg \ -O i386-pc -o dcore.img -C auto ext2 part_msdos biosdisk 

其中模块列表是您要debugging的grub-install的模块列表,并包含sleep或其他任何您需要的内容。 前缀-p应该从grub-install的输出中复制,显然它对GRUB横幅之后发生了什么有很大的影响。 您可能想要尝试使用GRUB设备代码(在这种情况下)而不是标准的UUID。 您可以使用lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE,STATE,UUIDls -l /dev/disk/by-id/以及mdadm --detail /dev/sda在RAID驱动器上显示UUID。

现在将刚刚创build的核心安装到任何正常启动的磁盘上:

 cp dcore.img /boot/grub/i386-pc grub-bios-setup -d /boot/grub/i386-pc -c dcore.img /dev/sda 

对于2.0之前的GRUB版本, grub-bios-setup命令仍然可以像手册中那样被称为grub-setup

重启。 您应该看到Welcome to GRUB! 随后在显示菜单之前显示几页debugging消息(或不按照情况)。

我现在正在回答我自己的问题1.这是4Kn('高级格式')问题吗?

是。

4Kn硬盘并不像你想像的那样得到广泛的支持 ; 例如,它们与Windows 7或GRUB 1或许多英特尔芯片组不兼容。 在我的情况下,这个问题似乎是主板上的英特尔82801I企业南桥控制器芯片(ICH9家族)。 我认为这也是驱动器部分故障的原因,即使通过USB md_resync。 在上面的链接分析似乎发现,尽pipe缺乏英特尔的官方支持,Linux的ata_piix驱动程序工作正常,超过英特尔ICH10 4Kn。 对于ICH9,我可能find了不同的结果。 我还没有testing驱动器是否可以在AHCI或SAS模式下工作。

只有主板制造商或其他进行了彻底testing的人员才有可能知道驱动器兼容性信息。 我很快就断定,“这不是硬件不兼容”,只是因为简单的读写工作。 有一个原因,为什么这个主板的更新BIOS不支持4Kn:因为主板不能这样做的可靠。

在这种情况下,没有理由使用等效的512e硬盘。

为了回答你的第二个问题,在2.02中有一个与raid1相关的bug 。

我希望这会有所帮助,即使我在2.02〜beta1之前(错误报告的版本)也不知道这个bug是否存在。

编辑:此外,发布这个问题后,脑海中浮现出一个问题:你的RAID1是一个软件还是硬件RAID?