Prev: Does anyone know how to cross compile the Linux kernel.
Next: Configuring ipmitool failing while loading modules
From: Nico Kadel-Garcia on 6 Apr 2010 08:16
On Apr 6, 5:47 am, JonT <j...(a)pobox.com> wrote:
> On 4 Apr, 20:58, Nico Kadel-Garcia <nka...(a)gmail.com> wrote:
>
>
>
> > On Apr 4, 6:40 am, JonT <j...(a)pobox.com> wrote:
>
> > > I have a very strange GRUB problem. GRUB is installed in the MBR of
> > > the first hard disc on my system, /dev/hda as far as linux is
> > > concerned, and primary master from a BIOS point of view. There are no
> > > SCSI or SATA discs in the system, just two other PATA IDEs and an IDE
> > > CDROM. /dev/hda has a boot partition /dev/hda1 containing the usual
> > > grub subdirectory, as well as a linux kernel. The linux root partition
> > > is /dev/hda2. In the grub subdirectory of the boot partition the
> > > device.map files contains the correspondence
>
> > > hd0 /dev/hda
>
> > > The menu.lst file correctly lists the kernel, the boot root (hd0,0)
> > > and the initrd. Yet grub will not boot the kernel. Instead it drops
> > > into its shell, with no error displayed. From there I can type the
> > > usual (using filename completion to get it right)
>
> > > root (hd0,0)
> > > kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
> > > initrd /initrd.img-2.6.30-2-686
> > > boot
>
> > > and the system boots. Yet GRUB refuses to do this itself, despite the
> > > above info being identical to that contained in menu.lst I can even
> > > attempt to install GRUB from its shell above, and succeed without
> > > error, but end up with the same effect.
>
> > > Where do I go from here?
>
> > Well, you could mention what version of Linux you installed. The
> > "vmlinuz-2.6.30-2-686" is a good hint that you're using a Debian
> > distribution, just from the age of the kernel. Did this grub *ever*
> > work for you? Is it part of something you installed yourself, or part
> > of a common distribution and normally installed machine and you've
> > been tweaking kernels? How did  you build this initrd?
>
> Yes, it's Debian Linux. The disc I have was created by cloning an
> existing disc using gparted. The reason for doing this is that when I
> created the original I only allocated 50Mb to the boot partition and
> 500Mb to /, which was quite adequate at the time. But, it's no longer
> adequate when updating (in particular I can't get two kernel versions
> on /boot at the same time any more). So, I used gparted to clone it
> but expanding all the vital partitions at the same time. /boot is now
> 500Mb, / is 5Gb, /usr is 10Gb etc. Apart from this, the kernel and
> initrd are exactly as was on the original disc, which boots fine. I
> installed grub using the Ubuntu live CD, by mount /dev/hda1 on /boot,
> then running grub, letting it find /boot/grub/stage1 to tell me
> (hd0,0), then doing the usual root (hd0,0), setup (hd0).
>
> So, no tweaks to kernel or initrd, only slight oddity is getting grub
> from ubuntu hardy live CD.

No, they're *NEVER* exactly as the original disk was when you re-
arrange or re-size partitions. Start from there.

God knows what you mean by "running grub" in this sentence. If you had
a clean and working layout, you should have been able to mount the
hard drive's file systems at "/mnt/sysimage", "/mnt/sysimage/boot", "/
mnt/sysimage/grub", etc. Then you can do "chroot /mnt/sysimage" and
run "grub-install /dev/hda". That's how I've done it for RHEL and
Fedora and SuSE.

As it is, I'm uncertain enough of the vagaries of the grub-install
command to be sure that it would work properly without the "chroot /
mnt/sysimage" step to the filesystem layout of / and /boot as recorded
in /etc/mtab. Running it from a live OS on the live CD is *not* the
same environment.
From: JonT on 6 Apr 2010 08:41
On 6 Apr, 13:16, Nico Kadel-Garcia <nka...(a)gmail.com> wrote:
> On Apr 6, 5:47 am, JonT <j...(a)pobox.com> wrote:
>
>
>
> > On 4 Apr, 20:58, Nico Kadel-Garcia <nka...(a)gmail.com> wrote:
>
> > > On Apr 4, 6:40 am, JonT <j...(a)pobox.com> wrote:
>
> > > > I have a very strange GRUB problem. GRUB is installed in the MBR of
> > > > the first hard disc on my system, /dev/hda as far as linux is
> > > > concerned, and primary master from a BIOS point of view. There are no
> > > > SCSI or SATA discs in the system, just two other PATA IDEs and an IDE
> > > > CDROM. /dev/hda has a boot partition /dev/hda1 containing the usual
> > > > grub subdirectory, as well as a linux kernel. The linux root partition
> > > > is /dev/hda2. In the grub subdirectory of the boot partition the
> > > > device.map files contains the correspondence
>
> > > > hd0 /dev/hda
>
> > > > The menu.lst file correctly lists the kernel, the boot root (hd0,0)
> > > > and the initrd. Yet grub will not boot the kernel. Instead it drops
> > > > into its shell, with no error displayed. From there I can type the
> > > > usual (using filename completion to get it right)
>
> > > > root (hd0,0)
> > > > kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
> > > > initrd /initrd.img-2.6.30-2-686
> > > > boot
>
> > > > and the system boots. Yet GRUB refuses to do this itself, despite the
> > > > above info being identical to that contained in menu.lst I can even
> > > > attempt to install GRUB from its shell above, and succeed without
> > > > error, but end up with the same effect.
>
> > > > Where do I go from here?
>
> > > Well, you could mention what version of Linux you installed. The
> > > "vmlinuz-2.6.30-2-686" is a good hint that you're using a Debian
> > > distribution, just from the age of the kernel. Did this grub *ever*
> > > work for you? Is it part of something you installed yourself, or part
> > > of a common distribution and normally installed machine and you've
> > > been tweaking kernels? How did  you build this initrd?
>
> > Yes, it's Debian Linux. The disc I have was created by cloning an
> > existing disc using gparted. The reason for doing this is that when I
> > created the original I only allocated 50Mb to the boot partition and
> > 500Mb to /, which was quite adequate at the time. But, it's no longer
> > adequate when updating (in particular I can't get two kernel versions
> > on /boot at the same time any more). So, I used gparted to clone it
> > but expanding all the vital partitions at the same time. /boot is now
> > 500Mb, / is 5Gb, /usr is 10Gb etc. Apart from this, the kernel and
> > initrd are exactly as was on the original disc, which boots fine. I
> > installed grub using the Ubuntu live CD, by mount /dev/hda1 on /boot,
> > then running grub, letting it find /boot/grub/stage1 to tell me
> > (hd0,0), then doing the usual root (hd0,0), setup (hd0).
>
> > So, no tweaks to kernel or initrd, only slight oddity is getting grub
> > from ubuntu hardy live CD.
>
> No, they're *NEVER* exactly as the original disk was when you re-
> arrange or re-size partitions. Start from there.
>
> God knows what you mean by "running grub" in this sentence. If you had
> a clean and working layout, you should have been able to mount the
> hard drive's file systems at "/mnt/sysimage", "/mnt/sysimage/boot", "/
> mnt/sysimage/grub", etc. Then you can do "chroot /mnt/sysimage" and
> run "grub-install /dev/hda". That's how I've done it for RHEL and
> Fedora and SuSE.
>
> As it is, I'm uncertain enough of the vagaries of the grub-install
> command to be sure that it would work properly without the "chroot /
> mnt/sysimage" step to the filesystem layout of / and /boot as recorded
> in /etc/mtab. Running it from a live OS on the live CD is *not* the
> same environment.

Well, I don't expect the exact layout of the disc to be identical, but
I do expect the files to be identical, which is what I meant when I
said that the kernel and initrd were identical. grub doesn't seem to
have a problem with either of these, as shown by the fact that I can
boot the system from its shell. I didn't go the mount everything and
chroot route as just mounting /dev/hda1 on /boot appeared to be
sufficient, and also, after the chroot I found I no longer had a grub
binary to run. Also, installing directly from the grub shell seems to
be considered "safer" than trying to use grub-install (I did try grub-
install at one time with the system booted, but it made a pig's ear of
my disc, so I backed out of that).

I've also tried installing using a grub ISO, but with no better
results. The conclusion I seem to be heading to is that grub is not
finding menu.lst when it boots, which suggests that its view of the
linux file system on my boot partition is not the same as linux's
From: Tauno Voipio on 6 Apr 2010 10:54
JonT wrote:
> On 5 Apr, 17:05, Tauno Voipio <tauno.voi...(a)notused.fi.invalid> wrote:
>> JonT wrote:
>>> I have a very strange GRUB problem. GRUB is installed in the MBR of
>>> the first hard disc on my system, /dev/hda as far as linux is
>>> concerned, and primary master from a BIOS point of view. There are no
>>> SCSI or SATA discs in the system, just two other PATA IDEs and an IDE
>>> CDROM. /dev/hda has a boot partition /dev/hda1 containing the usual
>>> grub subdirectory, as well as a linux kernel. The linux root partition
>>> is /dev/hda2. In the grub subdirectory of the boot partition the
>>> device.map files contains the correspondence
>>> hd0 /dev/hda
>>> The menu.lst file correctly lists the kernel, the boot root (hd0,0)
>>> and the initrd. Yet grub will not boot the kernel. Instead it drops
>>> into its shell, with no error displayed. From there I can type the
>>> usual (using filename completion to get it right)
>>> root (hd0,0)
>>> kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
>>> initrd /initrd.img-2.6.30-2-686
>>> boot
>>> and the system boots. Yet GRUB refuses to do this itself, despite the
>>> above info being identical to that contained in menu.lst I can even
>>> attempt to install GRUB from its shell above, and succeed without
>>> error, but end up with the same effect.
>>> Where do I go from here?
>> Is menu.lst on the boot partition?
>>
>> The symptoms point to that GRUB does not find menu.lst.
>> GRUB may have problems findong it from other partitions.
>>
>> --
>>
>> Tauno Voipio
>> tauno voipio (at) iki fi
>
> Yes, the disc has /dev/hda1 as /boot, and menu.lst is in the standard /
> boot/grub/menu.lst. device.map is also located in /boot/grub. I agree
> that it looks as though GRUB doesn't find menu.lst, but I have no
> means of finding out why, unless there's some way of debugging what
> it's up to whilst it's booting. Is it possible that gub wants menu.lst
> to be somewhere else?


Did you move the file or GRUB parts from somewhere without installing it?

--

Tauno Voipio
tauno voipio (at) iki fi
From: JonT on 6 Apr 2010 12:56
On 6 Apr, 15:54, Tauno Voipio <tauno.voi...(a)notused.fi.invalid> wrote:
> JonT wrote:
> > On 5 Apr, 17:05, Tauno Voipio <tauno.voi...(a)notused.fi.invalid> wrote:
> >> JonT wrote:
> >>> I have a very strange GRUB problem. GRUB is installed in the MBR of
> >>> the first hard disc on my system, /dev/hda as far as linux is
> >>> concerned, and primary master from a BIOS point of view. There are no
> >>> SCSI or SATA discs in the system, just two other PATA IDEs and an IDE
> >>> CDROM. /dev/hda has a boot partition /dev/hda1 containing the usual
> >>> grub subdirectory, as well as a linux kernel. The linux root partition
> >>> is /dev/hda2. In the grub subdirectory of the boot partition the
> >>> device.map files contains the correspondence
> >>> hd0 /dev/hda
> >>> The menu.lst file correctly lists the kernel, the boot root (hd0,0)
> >>> and the initrd. Yet grub will not boot the kernel. Instead it drops
> >>> into its shell, with no error displayed. From there I can type the
> >>> usual (using filename completion to get it right)
> >>> root (hd0,0)
> >>> kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
> >>> initrd /initrd.img-2.6.30-2-686
> >>> boot
> >>> and the system boots. Yet GRUB refuses to do this itself, despite the
> >>> above info being identical to that contained in menu.lst I can even
> >>> attempt to install GRUB from its shell above, and succeed without
> >>> error, but end up with the same effect.
> >>> Where do I go from here?
> >> Is menu.lst on the boot partition?
>
> >> The symptoms point to that GRUB does not find menu.lst.
> >> GRUB may have problems findong it from other partitions.
>
> >> --
>
> >> Tauno Voipio
> >> tauno voipio (at) iki fi
>
> > Yes, the disc has /dev/hda1 as /boot, and menu.lst is in the standard /
> > boot/grub/menu.lst. device.map is also located in /boot/grub. I agree
> > that it looks as though GRUB doesn't find menu.lst, but I have no
> > means of finding out why, unless there's some way of debugging what
> > it's up to whilst it's booting. Is it possible that gub wants menu.lst
> > to be somewhere else?
>
> Did you move the file or GRUB parts from somewhere without installing it?
>
> --
>
> Tauno Voipio
> tauno voipio (at) iki fi

No. The files such as stage1, menu.lst etc were already there from the
copy from the previous working disc. My only interaction with grub was
via its shell. I had hoped that all I needed to do was get grub onto
the MBR for it all to work.
From: Tauno Voipio on 6 Apr 2010 13:33
On 6.4.10 7:56 , JonT wrote:
> On 6 Apr, 15:54, Tauno Voipio<tauno.voi...(a)notused.fi.invalid> wrote:
>> JonT wrote:
>>> On 5 Apr, 17:05, Tauno Voipio<tauno.voi...(a)notused.fi.invalid> wrote:
>>>> JonT wrote:
>>>>> I have a very strange GRUB problem. GRUB is installed in the MBR of
>>>>> the first hard disc on my system, /dev/hda as far as linux is
>>>>> concerned, and primary master from a BIOS point of view. There are no
>>>>> SCSI or SATA discs in the system, just two other PATA IDEs and an IDE
>>>>> CDROM. /dev/hda has a boot partition /dev/hda1 containing the usual
>>>>> grub subdirectory, as well as a linux kernel. The linux root partition
>>>>> is /dev/hda2. In the grub subdirectory of the boot partition the
>>>>> device.map files contains the correspondence
>>>>> hd0 /dev/hda
>>>>> The menu.lst file correctly lists the kernel, the boot root (hd0,0)
>>>>> and the initrd. Yet grub will not boot the kernel. Instead it drops
>>>>> into its shell, with no error displayed. From there I can type the
>>>>> usual (using filename completion to get it right)
>>>>> root (hd0,0)
>>>>> kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
>>>>> initrd /initrd.img-2.6.30-2-686
>>>>> boot
>>>>> and the system boots. Yet GRUB refuses to do this itself, despite the
>>>>> above info being identical to that contained in menu.lst I can even
>>>>> attempt to install GRUB from its shell above, and succeed without
>>>>> error, but end up with the same effect.
>>>>> Where do I go from here?
>>>> Is menu.lst on the boot partition?
>>
>>>> The symptoms point to that GRUB does not find menu.lst.
>>>> GRUB may have problems findong it from other partitions.
>>
>>>> --
>>
>>>> Tauno Voipio
>>>> tauno voipio (at) iki fi
>>
>>> Yes, the disc has /dev/hda1 as /boot, and menu.lst is in the standard /
>>> boot/grub/menu.lst. device.map is also located in /boot/grub. I agree
>>> that it looks as though GRUB doesn't find menu.lst, but I have no
>>> means of finding out why, unless there's some way of debugging what
>>> it's up to whilst it's booting. Is it possible that gub wants menu.lst
>>> to be somewhere else?
>>
>> Did you move the file or GRUB parts from somewhere without installing it?
>>
>> --
>>
>> Tauno Voipio
>> tauno voipio (at) iki fi
>
> No. The files such as stage1, menu.lst etc were already there from the
> copy from the previous working disc. My only interaction with grub was
> via its shell. I had hoped that all I needed to do was get grub onto
> the MBR for it all to work.

Is the new disk identical to the master disk?

The initial booting steps need to know the BIOS geometry and
absolute block addresses of the installed files. If the copy
does not preserve the addresses, GRUB will have problems.

--

Tauno Voipio
tauno voipio (at) iki fi

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Does anyone know how to cross compile the Linux kernel.
Next: Configuring ipmitool failing while loading modules