[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Howto fix grub after converting to reiserfs



I'm not sure about what shell wrote, though I believe it should work. But I do have a method that I know works, as I'm using it on my system as we speak.

First, to rephrase a bit of what shell says the problem is, highly simplified. The initial load of grub is done by the BIOS, which reads the boot sectors for additional information for the boot process. The bits of grub that live in the boot sector are obviously not FS dependent in any way. But everything that grub needs in /boot is, and grub must know the FS type in order to read the boot directory content. The default appears to be ext[23], so doing as shell suggests and forcing the other FS image functionality should work. But...

If you still have problems, and can come up with a small bit of additional disk space, near the beginning of the disk, create a separate partition for /boot and format it as ext3, move all the files from your existing subdirectory into this new partition, edit the menu.lst file to remove all references to '/boot' (VERY important), edit fstab to do a mount of this partition on /boot, and reboot. IIRC, that should do it.

The reason for removing the '/boot' from lines in menu.lst is that grub will be looking at the root of the *device* you just created, which is not the same as looking at the directory structure of a running system with all mounts in place. Paths on the device will be '/vmlinux*' or '/grub/menu.lst', since they are not as yet mounted on the 'root' device, under /boot.

Bob

shell wrote:
Florian Kulzer wrote:

On Wed, Jul 26, 2006 at 11:48:07 +0100, marc wrote:
Matthew Dawson said...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 11 July 2006 17:03, marc wrote:
Hi,

I have a little problem :-o

Machine has Windows on sda2 vfat, which is the MBR. (sda1 is not used),
Linux on sda3, sda4 contains sda5 swap, sda6 ext Linux, sda7 is vfat
shared space.

Here's the story, so far

- moved Linux (on sda3) to a safe place while booted on another
partition (sda6)
- formatted sda3 as reiserfs
- amended both fstabs (sda3 and sda6)
- mounted the newly formatted sda3 partition
- moved the data back onto sda3
- rebooted.

Grub currently loads from /boot on sda3, or rather it doesn't now. I'm
getting an error 17 : Cannot mount selected partition. I'm not overly
surprised, but I'm not sure what to do next.

I can mount the partition from a live CD without a problem, and I
obviously mounted it from my sda6 partition.

Suggestions welcomed.
It would seem that grub only embeded support for ext2, which is what it should do because the partition was ext (it uses ext2 support for both ext3 and ext2). What you have to do is embed the reiserfs support. Try mounting the all the partitions as normal from a livecd, then chrooting into it and running update-grub. That should fix the problem.
Just got back to this. Nope, update-grub only "updated" menu.lst, no changes to the initrd.

sudo dpkg-reconfigure linux-image-....

should rebuild your initrd. (For older kernels it is "kernel-image"
instead of "linux-image".)

If that does not work in the chroot environment then you can call
mkinitrd or mkinitrd.yaird directly.

I looked up GNU GRUB Manual 0.97(http://www.gnu.org/software/grub/manual/html_node/index.html), seems like u problem is this.

17 : Cannot mount selected partition
    This error is returned if the partition requested exists, but the
    filesystem type cannot be recognized by GRUB.

If it's true, that's means u grub stage1 image in sda's mbr can't load stage2. So it's useless which update initrd.img. U can bootup from LiveCD because ur LiveCD use stage2_eltorito or syslinux(that's more commonly) to find vmlinuz & initrd.img. So maybe that's what u wanna.

    — Command: *install* [--force-lba] [--stage2=os_stage2_file]
    stage1_file [d] dest_dev stage2_file [addr] [p] [config_file]
    [real_config_file]

In short, it will perform a full install presuming the Stage 2 or Stage 1.5^10 <http://www.gnu.org/software/grub/manual/grub.html#fn-10> is in its final install location.

In slightly more detail, it will load stage1_file, validate that it is a GRUB Stage 1 of the right version number, install in it a blocklist for loading stage2_file as a Stage 2. If the option d is present, the Stage 1 will always look for the actual disk stage2_file was installed on, rather than using the booting drive. The Stage 2 will be loaded at address addr, which must be `0x8000' for a true Stage 2, and `0x2000' for a Stage 1.5. If addr is not present, GRUB will determine the address automatically. It then writes the completed Stage 1 to the first block of the device dest_dev. If the options p or config_file are present, then it reads the first block of stage2, modifies it with the values of the partition stage2_file was found on (for p) or places the string config_file into the area telling the stage2 where to look for a configuration file at boot time. Likewise, if real_config_file is present and stage2_file is a Stage 1.5, then the Stage 2 config_file is patched with the configuration file name real_config_file. This command preserves the DOS BPB (and for hard disks, the partition table) of the sector the Stage 1 is to be installed into.

*Caution3:* You must specify the option --stage2 in the grub shell, if you cannot unmount the filesystem where your stage2 file resides. The argument should be the file name in your operating system.

e2fs_stage1_5
fat_stage1_5
ffs_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
vstafs_stage1_5
xfs_stage1_5
    These are called Stage 1.5, because they serve as a bridge between
    stage1 and stage2, that is to say, Stage 1.5 is loaded by Stage 1
    and Stage 1.5 loads Stage 2. The difference between stage1 and
    *_stage1_5 is that the former doesn't understand any filesystem
    while the latter understands one filesystem (e.g. e2fs_stage1_5
    understands ext2fs). So you can move the Stage 2 image to another
    location safely, even after GRUB has been installed.

    While Stage 2 cannot generally be embedded in a fixed area as the
    size is so large, Stage 1.5 can be installed into the area right
    after an MBR, or the boot loader area of a ReiserFS or a FFS.

    In ur problem, maybe u can try this in grub shell.
*setup* --stage2=/boot/grub/reiserfs_stage1_5 (hd0)
*install* /boot/grub/stage1 (hd0) /boot/grub/reiserfs_stage1_5

Remember return 2 me if that's really work, because I'm not sure in this.

                                               Shell.E.Xu

--
与其相濡以沫,不如相忘于江湖




Reply to: