Mickey Fox 写道:
> 今天我再试了试,进入ash后用mount可以挂载成功,只是必须显式地指定文件系统类型:-text3。我平常习惯都是不指定的,没想到这里必须指定。
>   
这里说个题外话,平时我也不指定mount的系统类型参数,不过我知道那是fstab里
面已经指定的结果。在安装盘的急救模式下是必须指定呢,还是可以自动测试,有
没有人知道?
> 我是在老内核下试的,新内核就干脆没试了。我想要想解决新内核的问题,首先应该让老内核能用起来,因为这个内核本身应该是好的,用了好长时间了。
>
> 要进入ash之前更多的信息是:
> Begin: Mounting root file system... ...
> Begin: Running /scripts/local-top ...
> ide0: I/O resource 0x1F0-0x1F7 not free.
> ide0: ports already in use, skipping probe
> ide1: I/O resource 0x170-0x177 not free.
> ide1: ports already in use, skipping probe.
> Done
>    Check root= bootarg cat /proc/cmdline
>    or missing modules, devices: cat /proc/modules ls /dev
> ALERT! /dev/sda9 does not exist. Dropping to a shell!
>
> 进入ash后,cat /proc/cmdline的结果为:
> root=/dev/sda9 ro
>
> cat /proc/modules的结果为:
> vfat 11872 0 - Live 0xf8896000
> fat 46652 1 vfat, Live 0xf891b000
> ext3 119240 1 - Live 0xf893f000
> jbd 52456 1 ext3, Live 0xf88c3000
> mbcache 8356 1 ext3, Live 0xf889a000
> usb_storage 72000 0 - Live 0xf8908000
> ide_generic 1408 0 [permanent], Live 0xf8890000
> sd_mod 19040 2 - Live 0xf88bd000
> generic 4868 0 [permanent], Live 0xf8893000
> ide_core 110504 3 usb_storage,ide_generic,generic, Live 0xf88d3000
> ehci_hcd 28136 0 - Live 0xf8826000
> uhci_hcd 21164 0 - Live 0xf8889000
> ata_piix 13896 1 - Live 0xf8884000
> libata 89396 1 ata_piix, Live 0xf889f000
> scsi_mod 124168 3 usb_storage,sd_mod,libata, Live 0xf8844000
> usbcore 112644 4 usb_storage,ehci_hcd,uhci_hcd, Live 0xf8867000
> r8169 28360 0 - Live 0xf883c000
> thermal 13608 0 - Live 0xf8837000
> processor 28840 1 thermal, Live 0xf882e000
> fan 4804 0 - Live 0xf8821000
>
> ls /dev的结果为:
> bus     ptypf   sdb13   tty26   tty51   ttyp7
> console ram0    sdb2    tty27   tty52   ttyp8
> disk    ram1    sdb5    tty28   tty53   ttyp9
> full    ram10   sdb6    tty29   tty54   ttypa
> hpet    ram11   sdb7    tty3    tty55   ttypb
> input   ram12   sdb8    tty30   tty56   ttypc
> kmem    ram13   sdb9    tty31   tty57   ttypd
> kmsg    ram14   snapshot        tty32   tty58   ttype
> mem     ram15   tty     tty33   tty59   ttypf
> null    ram2    tty0    tty34   tty6    urandom
> port    ram3    tty1    tty35   tty60   usbdev1.1_ep00
> psaux   ram4    tty10   tty36   tty61   usbdev1.1_ep81
> ptmx    ram5    tty11   tty37   tty62   usbdev1.2_ep00
> ptyp0   ram6    tty12   tty38   tty63   usbdev1.2_ep83
> ptyp1   ram7    tty13   tty39   tty7    usbdev2.1_ep00
> ptyp2   ram8    tty14   tty4    tty8    usbdev2.1_ep81
> ptyp3   ram9    tty15   tty40   tty9    usbdev3.1_ep00
> ptyp4   random  tty16   tty41   ttyS0   usbdev3.1_ep81
> ptyp5   sda     tty17   tty42   ttyS1   usbdev4.1_ep00
> ptyp6   sda1    tty18   tty43   ttyS2   usbdev4.1_ep81
> ptyp7   sda2    tty19   tty44   ttyS3   usbdev5.1_ep00
> ptyp8   sda5    tty2    tty45   ttyp0   usbdev5.1_ep81
> ptyp9   sda6    tty20   tty46   ttyp1   vcs
> ptypa   sdb     tty21   tty47   ttyp2   vcs1
> ptypb   sdb1    tty22   tty48   ttyp3   vcsa
> ptypc   sdb10   tty23   tty49   ttyp4   vcsa1
> ptypd   sdb11   tty24   tty5    ttyp5   zero
> ptype   sdb12   tty25   tty50   ttyp6
> Debian系统安装在/dev/sdb9,进入ash后mount这个分区能成功,所以grub中指定的位置并没有错。
>   
另外,在grub中指定的root=,我不确定是否和启动之后的dev设备完全对应。原来
在搞光盘启动的时候,我曾经接触过一点initrd.img。现代的linux内核启动,其
实会先把这个文件加载到内存中,作为根设备。这个文件中包含了很多设备驱动,
这样就可以不重编译内核支持从很多奇怪设备的启动,例如光驱,usb,或者其他设
备。并且可以定制,加减驱动。这个文件中的脚本会接受你从grub中获得的参数,
而后通过一个过程(很烦琐,我忘光了) 得到这个新的根设备,以ro方式挂载。而
后初始化一些东西(仍然是忘光了哪些),读取/etc/fstab文件,再按照fstab中指
定的方式挂载所有分区。最后启动init,initrd.img的使命就算完成了。
而在initrd.img里面的设备是什么情况,我就没有研究了~~
> 希望这些补充信息能有助于大家帮我解决这个问题。
>
> 在 08-4-10,shell909090<[EMAIL PROTECTED]> 写道:
>   
>> Mickey Fox 写道:
>> debian编译新内核安装的时候是不修改旧内核项目的,所以我觉得特别奇怪。
>>     
> 它也应该不会更新grub吧(menu.lst除外)?
>
>   
>> 本本的SATA模拟成IDE改成启用了
>>     
>
>   
>> 如果确实是这种情况,它会在什么地方改呢?改了BIOS信息(这会影响到新旧两版内核)?还是内核相关的配置(应该不会影响旧内核)?
>>     
>
> 补充:在挂载根分区失败后进入ash,用里面的mount挂载分区都失败,大致的错误信息都是Invalid
>   
>> file
>> system
>>     
> options(凭记忆写的)。因为fdisk不可用,我就用/dev目录下hd和sd开头的分区试的,mount时并没有带-o参数。
>   
>> 怎么会这样呢?这个看上去是你的分区格式被破坏了。你试试加分区格式挂载看看,再试试别的参数。要是死活挂不上去,那你就知道问题在哪里了。
>> 要是挂的上去,那把跟分区的分区写入到menu.lst中试试看。
>> 在 08-4-10,shell909090<[EMAIL PROTECTED]> 写道:
>>     
>
>   
>> 看提示,是不是挂在了initrd.img中的脚本试图加载root分区的时候了?
>>     
> 我记得这时候的分区确定是根据grub的root=信息来的,如果你的跟分区修改了(或
> 者硬盘配置修改了,本本的SATA模拟成IDE改成启用了,等等),就会造成跟分区找
> 不到,进而无法启用。
> 当然,也有可能是grub中的root=信息被改了,不过我记得debian编译新内核安装
> 的时候是不修改旧内核项目的。
>
> Mickey
>   
>> Fox 写道:
>>     
>
>   
>> 我的机器是Windows
>> XP和Debian
>>     
> Etch双启动。昨天在Debian下编译2.6.24.4的内核成功,安装新内核后重新启动,发现进不了Linux了,停在了这一步:
> Waiting
>   
>> for root file system ... ...
>>     
> 在这之前一些会有这样的信息:
> hdc: cache flushes supported
>   
>> hdc: hdc1 hdc2 <hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 hdc11 hdc12 hdc13>
>>     
> ALERT!
>   
>> /dev/sda9 does not exist. Dropping to a
>> shell!
>>     
> 可是在使用原来的内核时硬盘应该是sda和sdb的(两块硬盘)。
>
> 再次重启,选择升级前的2.6.18内核,仍然停在了这一步:
> Waiting
>   
>> for root file system ...
>> ...
>>     
> 但前面的信息略有变化,hdc变成了sda。
>
> 改用Kubuntu光盘启动,能够找到硬盘分区。
>
> 不知问题出在哪?新内核不行也罢了,为什么连回到旧内核都无法启动呢?
>
>   
>>
>>     

回复