linux 调试引导程序,c-调试syslinux看到的引导文件系统环境？

好,我启动了它…

首先,我注意到根据Mbr – Syslinux Wiki和HowTos – Syslinux Wiki,内置git源中存在替代的mbr,因此我尝试了mbr.bin和altmbr.bin-altmbr.bin,如下所示：

$printf '\1' | cat mbr/altmbr.bin - | sudo dd bs=440 count=1 conv=notrunc iflag=fullblock of=/dev/sdc

…但是那并没有太大帮助.

最后,我注意到lsusb说“ bInterfaceProtocol 80 Bulk(Zip)”；我记得在某处读过有关ZIP驱动器的内容,因此尝试查找它-最终发现了这一点：

The proper mode to boot a USB key drive in is “USB-HDD”. That is the

ONLY mode in which the C/H/S geometry encoded on the disk itself

doesn’t have to match what the BIOS thinks it is. Since geometry on

USB drives is completely arbitrary, and can vary from BIOS to BIOS,

this is the only mode which will work in general.

Some BIOSes have been reported (in particular, certain versions of the

Award BIOS) that cannot boot USB keys in “USB-HDD” mode. This is a

very serious BIOS bug, but it is unfortunately rather typical of the

kind of quality we’re seeing out of major BIOS vendors these days. On

these BIOSes, you’re generally stuck booting them in USB-ZIP mode.

THIS MEANS THE FILESYSTEM IMAGE ON THE DISK HAS TO HAVE A CORRECT

ZIPDRIVE-COMPATIBLE GEOMETRY.

….

The script “mkdiskimage” which is supplied with the syslinux

distribution can be used to initialize USB keys in a Zip-like fashion.

To do that, calculate the correct number of cylinders (31 in the

example above), and, if your USB key is /dev/sda (CHECK THE KERNEL

MESSAGES CAREFULLY – IF YOU ENTER THE WRONG DISK DRIVE IT CANNOT BE

RECOVERED), run:

mkdiskimage -4 /dev/sda 0 64 32

(The 0 means automatically determine the size of the device, and -4

means mimic a zipdisk by using partition 4.)

因此,按照那里的建议,首先我找到拇指驱动器的气缸数：

$grep 512-byte /var/log/syslog | tail -n 1

Mar 25 22:33:34 mypc kernel: [50884.608687] sd 45:0:0:0: [sdc] 4118528 512-byte logical blocks: (2.10 GB/1.96 GiB)

# get number of cylinders:

$wcalc '4118528/(64*32)'

= 2011

…然后我继续使用mkdiskimage.完成此操作后,我再次尝试了usb_inst.sh-并意识到它将覆盖mkdiskimage创建的分区4,并为其自身创建分区1.这意味着,应该将usb_inst.sh文件复制到其他位置的备份中,然后运行mkdiskimage-然后最后将备份的文件再次复制回thumbdrive；这是命令行日志：

# mkdiskimage is present in syslinux-git:

$./utils/mkdiskimage

Usage: ./utils/mkdiskimage [-doFMz4][-i id] file c h s (max: 1024 256 63)

....

# ... but also in Debian/Ubuntu packaging of syslinux

$mkdiskimage -4 /dev/sdc 0 64 32

/usr/bin/mkdiskimage: /dev/sdc: don't know how to determine the size of this device

# use sudo - note this command takes a while to complete:

$sudo mkdiskimage -4 /dev/sdc 0 64 32

Warning: more than 1024 cylinders (2011).

Not all BIOSes will be able to boot this device.

$ls /dev/sdc*

/dev/sdc /dev/sdc4

$sudo fdisk -l /dev/sdc

Disk /dev/sdc: 2108 MB, 2108686336 bytes

64 heads, 32 sectors/track, 2011 cylinders

Units = cylinders of 2048 * 512 = 1048576 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x866262cc

Device Boot Start End Blocks Id System

/dev/sdc4 * 1 2011 2059248 e W95 FAT16 (LBA)

# (make sure umounted / ejected)

# cd to usb_inst.sh directory; and

# run usb_inst.sh for /dev/sdc; note it will:

# write MBR and "Creating filesystem on /dev/sdc1..."

# and "installing boot loader on /dev/sdc1";

# regardless of the previous setup on partition 4:

sudo bash ./usb_inst.sh

# now no more partition 4:

$ls /dev/sdc*

/dev/sdc /dev/sdc1

# ( mount /dev/sdc1 via disk applet )

$rsync -a /media/SYSRESC /media/backup/

# ... duhh... - again now

# ( umount/eject via disk applet )

$sudo mkdiskimage -4 /dev/sdc 0 64 32

Warning: more than 1024 cylinders (2011).

Not all BIOSes will be able to boot this device.

$sudo ./linux/syslinux --install /dev/sdc4

# ( mount via disk applet )

$rsync -a /media/backup/SYSRESC/ /media/31A8-40E9/

$sudo qemu -hda /dev/sdc # works

# ( umount/eject via disk applet )

# boot on desktop - works! loads rescue64 and initram.igz...

有趣的是-即使出现警告“并非所有BIOS都能够启动此设备”.这个有问题的BIOS会以某种方式毫无问题地加载此thumbdrive(并且上面的_ls函数列出很好).也很有趣-在这里我选择了USB-HDD引导选项(不是USB-ZIP),它仍然有效吗？

因此,作为部分答案-我想调试此方法的方法是,让syslinux以某种方式在拇指驱动器上写入在syslinux安装过程中看到的CHS几何结构.在启动时,查询BIOS(我猜是关于BIOS看到的CHS几何图形),然后将这两个几何图形转储到屏幕上；如果存在不匹配,则很可能应该运行mkdiskimage(不幸的是,我不知道如何将其编码到syslinux中)

回到我最初的HDD问题-原来SystemRescueCD也使用udev来探测设备-再次引导过程无法完成(即使我选择了引导选项“所有文件到内存(docache)”)…所以我得到了消息如下：

udevadm settle - timeout of 180 seconds reached, the event queue contains:

Activating dmraid (fake hardware raid) ...

Starting mdadm (linux software raid) ....

udevd[88] worker [91] unexpectedly returned with status 0x0100 ...

udevd[88] worker [91] failed while handling '/devices/pci0000:00/.../sdb/sdb1'

因此,我可以找到一个Live USB发行版,该发行版不使用udev来探测磁盘-或者我最好将这个HDD取出,扔进HDD USB机箱中,然后尝试在另一台计算机上fsck(希望我能够将其列入黑名单)来自运行系统上的udev的驱动器)

编辑2013年8月24日：回到这个问题,我想我会记下一些额外的笔记：

由于我尚无时间修复此PC及其故障驱动器,因此,我已使用此USB拇指驱动器来引导多个操作系统：PartedMagic和SliTaz确实在硬盘上也遇到了错误-但显然使用了不同的驱动程序来访问它(因此DRDY ERR循环没有启动),它们可以相对快速地完成启动.然后,我尝试构建一个自定义的Ubuntu 12.04映像(使用ubuntu-builder)-该映像最终陷入了DRDY ERR循环,在操作系统完成引导之前,可能需要5分钟以上的时间才能完成.我在Bug #1216397 “

It should be possible to ignore (skip probing) a known bad disk partition at boot” : Bugs : “linux” package : Ubuntu中发布了有关此内容的更多信息.

关于syslinux,有一些有趣的事情,因为此USB拇指驱动器用于引导多个操作系统.首先,仍然首先使用syslinux –install将thumbdrive设置为可启动,而在空时将其安装(将ldlinux.sys文件放置在分区的根目录中)-对应于上面的mkdiskimage步骤；然后才将文件(例如内核映像,包括/boot/syslinux/syslinux.cfg)复制到其中.

现在,我首先要在ubuntu-builder中构建CD映像ISO,然后使用VirtualBox对其进行测试(因为我的计算机上的qemu太慢了).一旦表明ISO映像可以正常工作,则只有casper目录下的文件与如此准备的USB拇指驱动器有关；可以通过syslinux.cfg中的启动菜单项来引用它们.因此,我将在thumbdrive上编辑syslinux.cfg,并将Casper映像文件(例如filesystem.squashfs)复制到thumbdrive-并如上所述使用qemu对其进行测试.一旦通过此qemu步骤,我将用损坏的驱动器在目标PC上移动USB拇指驱动器-有趣的是,在这里我可能会遇到多种类型的syslinux引导失败(在不同的引导阶段)：

>“找不到默认或UI配置指令！” (或者有时显示“ Bad< something> …”消息),然后显示syslinux启动菜单-即使如上所述的调试也会表明syslinux正确读取了thumbdrive上的文件系统并找到了/ boot /syslinux/syslinux.cfg(确实具有正确的指令)！

>“无效或损坏的内核映像”,一旦显示syslinux菜单,并选择了新的内核映像(Ubuntu)-即使其他映像(以前在拇指上找到)在损坏的驱动器PC上正常启动；并且新图像可以在另一台计算机上通过qemu从拇指启动正常！

>“ / init：第7行：无法打开/ dev / sr0：找不到介质”,一旦从syslinux菜单中选择了新的(Ubuntu)映像,它将开始启动；这似乎是Ubuntu特定的消息,它在启动后几秒钟出现.即使启动成功完成,我仍然会遇到它-当出现问题时,此消息只会反复循环,而无法完成其余的启动过程

事实证明,每当我尝试更改syslinux.cfg文件并将其保存在thumbdrive上时,其中的任何一个都可能出现.或者当我在Casper图像文件中进行更改时,我将它们同步或复制到thumbdrive中.也许是复制过程(因为它可能会改变文件位于拇指上的扇区),但会“混淆”引导过程的一部分-尽管这种情况不应该发生,因为上述工作过程也是从空白的syslinux开始的’d thumbdrive,将文件复制到其中；因此,我认为这可能表明拇指驱动器上的扇区出现故障.

但是,即使在这种状态下,上面的工作过程似乎仍然有用-因为使用它,我可以使拇指恢复到工作状态！更详细地说,它是这样的：

>将thumbdrive文件的副本保留在其他磁盘上的某个位置(例如?/ thumbcopy)-但没有ldlinux.sys文件.

>每当您要进行更改(对syslinux.cfg或可引导映像文件)时-确保首先将此更改保存在?/ thumbcopy中

>现在,说我直接在可启动的拇指驱动器上更改了一些文件,遇到了以上错误之一.然后：

>首先,删除除拇指驱动器上的ldlinux.sys外的所有文件,例如：

rm -rf $(ls -I"ldlinux.sys" /media/31A8-40E9/)

>然后,rsync或将?/ thumbcopy中的文件复制(cp -arv …)到thumbdrive,例如：

rsync -aP ~/thumbcopy/ /media/31A8-40E9/

>现在,尝试再次在PC中启动Thumbdrive-它通常可以正常启动！

我遇到了这三种类型的错误,因为我经常尝试直接在thumbdrive中更改/复制单个文件：有时更改不会带来问题,因此启动很好-但是,在许多情况下,它确实可以介绍一个问题.出于某种原因,使用上述过程,我设法从上述两种类型的问题中恢复了指驱动器-也许与USB Flash延迟写入有关,也许与USB Flash失败扇区有关,我无法真正告知…但是无论如何：删除所有文件,然后一次性重新复制,似乎是一个值得尝试的程序,以防出现此类错误.