Prev: Does anyone know how to cross compile the Linux kernel.
Next: Configuring ipmitool failing while loading modules
From: unruh on 6 Apr 2010 13:56
On 2010-04-06, Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:
> 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.
>

In the intial stages, grub uses the bios and the absolute disk reads
contained in the bios. Ie, it has to have the exact disk address ( it
cannot use the filesystem, or directories, or anything like that) to
load the stage 1 into memory. Stage 1 then has some primative filesystem
abilities. Thus, the stuff in the MBR must be tailored specifically
to the disk on which it is installed. One cannot reuse it from another
disk. Thus you have to run grub, the installer, whenever you make any
changes whatsoever.
But I assume you did that.

From: David W. Hodgins on 6 Apr 2010 14:58
On Tue, 06 Apr 2010 12:56:56 -0400, JonT <jgt(a)pobox.com> wrote:

> 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.

Just a guess, but are the versionx of grub on the hard drive and the live
cd, the same?

What filesystem type is being used? I'd expect an older version of grub
to have problems with a newer filesystem type, such as ext4.

Maybe a newer livecd would fix the problem.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: Nico Kadel-Garcia on 6 Apr 2010 20:39
On Apr 6, 8:41 am, JonT <j...(a)pobox.com> wrote:
> 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

It clearly was not "sufficient", or you wouldn't be having such
difficulties. Your confidence in it seems well-meant, but misplaced.
(Hey, it happens to me, too!).

I think you need to mount the old "/" filesystem" at /mnt/sysimage,
and the "/boot" filesystem at /mnt/sysimage/boot. The remnants of your
OS image's /etc/mtab should be in /mnt/sysimage/etc/mtab, so both "/"
and "/boot" should be accesible from inside that chroot. Whether you
have a "/var" or other filesystems that need mounting, I can't tell
without

> 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).

grub-install works well, but needs to happen *from inside the chroot
cage* I just described.

> 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

What, exactly, is a "grub ISO"?
From: David W. Hodgins on 6 Apr 2010 22:18
On Tue, 06 Apr 2010 21:47:15 -0400, unruh <unruh(a)wormhole.physics.ubc.ca> wrote:

> You assume that that the bootloader can read "files". It cannot.

That's true for lilo, and for the boot sector portion of grub.
Grub stage 1.5 does understand filesystems, provided the correct
version of 1.5 is used. When used, stage 1.5 is usually stored
immediately after the mbr, in the first track. Grub stage 2 also
able to read files.

See the images section of "info grub".

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: JonT on 7 Apr 2010 04:46
On 7 Apr, 03:18, "David W. Hodgins" <dwhodg...(a)nomail.afraid.org>
wrote:
> On Tue, 06 Apr 2010 21:47:15 -0400, unruh <un...(a)wormhole.physics.ubc.ca> wrote:
> > You assume that that the bootloader can read "files". It cannot.
>
> That's true for lilo, and for the boot sector portion of grub.
> Grub stage 1.5 does understand filesystems, provided the correct
> version of 1.5 is used.  When used, stage 1.5 is usually stored
> immediately after the mbr, in the first track.  Grub stage 2 also
> able to read files.
>
> See the images section of "info grub".
>
> Regards, Dave Hodgins
>
> --
> Change nomail.afraid.org to ody.ca to reply by email.
> (nomail.afraid.org has been set up specifically for
> use in usenet. Feel free to use it yourself.)

Thanks for the copious replies. Let me just reiterate some evidence,
which I think may answer some of the above questions.

At boot time I get dumped into a grub shell, with no apparent error
(although grub's habit of issuing a clear screen may have concealed
it). I'm not familiar enough with grub's internals to know how many of
stage1, stage1_5 and stage2 this means it has executed, but I'm
guessing one of the posters on this thread knows that.

From the grub shell, I can manually input enough info to complete the
boot, using the info I would expect to use, ie
root (hd0,0)
kernel /vmlinuz-2.6.30-2-686 root=/dev/hda2 ro
initrd /initrd.img-2.6.30-2-686
boot

This info is what is contained in menu.lst (it hasn't changed from the
disc from which the current one was cloned). So this tells me that by
the time I end up in the grub shell, grub is sufficiently capable that
it can interrogate and use linux's ext3 (I'm not using ext4, only
ext3, which is probably the same as ext2 from grub's point of view).

It is certainly possible that the grub code in the MBR and that in the
stage files is somehow out of step. If so, it would be nice to find
something that would allow a consistent set to be installed (eg to
cope with the case when the disc contains no grub related files at
all, not even the installer).
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