Re: error: no such disk

[Michael Evans]

On Sat, Dec 26, 2009 at 1:40 PM, Leslie Rhorer <address@hidden> wrote:
>> The issue I'm still having, and still had when the suggested changes
>> were made, is that grub says there is no such disk; I'm then presented
>> with the grub rescue prompt and I'm unable to ls any of hard drives. I
>> can, however, do an ls and see all the hard drives themselves, I just
>> can't ls their contents. When I do an ls of any of the partitions I
>> get an unknown file system error.
>>
>> Could the insmod ext2 line be the cause? (hd1,4) is an ext4 partition,
>> but the ext2 module is being loaded. I checked to see if I have an
>> ext4 module: I don't. But this shouldn't matter because ext4 is
>> backwards compatible with ext2.
>
>        Well, there's "backwards-compatible", and there's "backwards
> compatible".  I am not familiar with ext4, but it is entirely possible the
> ext4 module can read ext2 partitions, but an ext2 module cannot read ext4
> file systems.  If the failure you are getting happens after the Linux kernel
> and initrd are loaded, then this sounds like an issue in the initrd image.
> If this is the case, you might try updating the initrd image via whatever
> method your distro employs.  If the failure is happening in the grub loader
> before the Linux kernel is loaded, then it is an issue with grub.
>
>> The issue I'm still having, and still had when the suggested changes
>> were made, is that grub says there is no such disk; I'm then presented
>> with the grub rescue prompt and I'm unable to ls any of hard drives. I
>> can, however, do an ls and see all the hard drives themselves, I just
>> can't ls their contents. When I do an ls of any of the partitions I
>> get an unknown file system error.
>
>        Um, OK.  That's a little convoluted, but I think I see what you are
> saying.  If grub cannot read the file systems (ext4 or whatever), then it
> can never see the structures allowing it to find the stage 1 loaders or the
> Linux kernel, which may reside in /boot/grub, /grub, /boot, /, or whatever.
> In my particular case, I have tiny ext2 partitions containing only the Linux
> kernel and initrd files in / and the grub files in /grub.  Grub sees these
> as simply / and /grub on /dev/md1 ( hd0,0 or hd1,0, as the case may be ).
> Once the kernel is loaded and the md module is active, /dev/md2 (consisting
> of hd0,1 and hd1,1) is mounted on / and then /dev/md1 is loaded on /boot.
> The point is, grub must be able to recognize the file system where the
> kernel and the grub files are found.  If the grub menu (menu.lst) comes us,
> then grub is finding menu.lst, and it recognizes the boot partition at least
> well enough to try to pass over control to the kernel.  If not, then in
> order to fix the problem, you are going to have to provide grub with a file
> system it does recognize.  Whether that file system can be ext4 or not, I
> don't know.  That's one reason why I have a separate boot partition.  It
> allows the boot file system to be as rudimentary and / or widely supported
> as possible, while allowing the other file systems to be as new or have as
> many bells and whistles as I want.
>
>
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-grub
>

I agree, ext4 is backward compatible to a point.  There are features
which are important to ext4 performance and benefits which break the
backward compatibility.  Ideally you use ext2 or at best ext3 for your
boot file-system (the difference being only the journal), and have all
the files you want to load on it.  I am not familiar with grub2's
development, and don't know anything about filesystem support
currently in planning or development; you should look at the wiki
and/or website for documentation; though I would take the path of
least resistance and follow the currently working feature-sets.