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
--
与其相濡以沫,不如相忘于江湖
Pieter Agten wrote:
> Hello,
>
> A couple of weeks ago I installed Debian Stable (3.1) on a PII 400Mhz
> with a 80GB harddisk, everything worked fine. I had to replace this
> harddisk with a different one (also 80GB) and I did this by cloning the
> original disk to this new one with HDClone 3.1. After replacing the
> harddisk, the system doesn't boot anymore: when I should see the GRUB
> Boot Menu, the system just reboots. So now it is stuck in a reboot loop.
>
> The exact boot process is as follows:
> - System POST
> - I see 'GRUB Loading stage1.5.' and 'GRUB loading, please wait...' for
> about half a second.
> - Reboot
>
> I am sure the HDClone 3.1 program works flawlessly because I have used
> it before (on linux systems) and it has never failed. Furthermore, I
> have had this problem before on an entirely different system, right
> after the Debian installation (so on that system I never had even one
> correct boot with GRUB).
>
> How can I solve this problem? One fix might be to install LILO instead
> of GRUB, but what is the best way to do this? I replaced GRUB by LILO
> once before, and after that, everytime I would install a different (home
> made) kernel, I had to adjust the lilo.conf and run lilo manually, so I
> would like to avoid that. If it is possible, I would like to keep GRUB...
>
> Thanks in advance!
Most likely: GRUB got written to a different cluster than original - a
common event in cloning. As a result, the code in bootsector points to
wrong location on partition and GRUB is confused.
To fix it, start up GRUB in interactive mode (as root) and rewrite the
bootsector:
# Assuming boot partition is on first hard drive (hd0):
$ sudo grub
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For
the first word, TAB lists possible command
completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
# type "root (hd0, " then press tab key to get list of partitions:
grub> root (hd0,
Possible partitions are:
Partition num: 0, Filesystem type is fat, partition type 0x16
Partition num: 2, Filesystem type unknown, partition type 0x7
Partition num: 4, Filesystem type unknown, partition type 0x82
Partition num: 5, Filesystem type is reiserfs, partition type 0x93
Partition num: 6, Filesystem type is fat, partition type 0xb
# Here, partition 5 has grub directory, so:
grub> root (hd0,5)
Filesystem type is reiserfs, partition type 0x93
# now rewrite the bootsector:
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/reiserfs_stage1_5" exists... yes
Running "embed /boot/grub/reiserfs_stage1_5 (hd0)"... 18 sectors are
embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+18 p
(hd0,5)/boot/grub/stage2 /boot/grub/menu.lst
"... succeeded
Done.
# we're done:
grub> reboot
Adjust the numbers to fit your situation. Hope this helps!