On Sun, 08 Jun 2008 11:00:49 -0400, Dave Farrance wrote:

> The CD seems OK in that I can mount it in Linux and the configuration
> file "menu.lst" is in the correct place.

Any chance the file was typoed as menu.1st, instead of menu.lst?
(number, instead of letter).

Mount the cd, and post the output of "ll $mountpoint/boot/grub/" and
"cat $mountpoint/boot/grub/menu.lst" and maybe someone can spot 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.)

"David W. Hodgins" wrote:

>On Sun, 08 Jun 2008 11:00:49 -0400, Dave Farrance wrote:
>> The CD seems OK in that I can mount it in Linux and the configuration
>> file "menu.lst" is in the correct place.
>
>Any chance the file was typoed as menu.1st, instead of menu.lst?
>(number, instead of letter).

No, although I've no doubt that's a common mistake. I've figured it out
now, though.

When I booted the Grub CD on a different laptop, the menu displayed OK --
it just didn't display on the laptop that created it.

At the grub prompt, I entered "geometry ( "
which lists the visible disks.

First laptop: fd0 hd0
Second laptop: fd0 hd0 cd

In other words, grub couldn't see the CD on the first laptop, even though
the bios could boot that CD. I guessed that the CD grub loader that was
supplied with Mandriva, "stage2_eltorito", didn't contain the driver for
the Mat****a-UJ-825S DVD writer, probably to save space. I've not had
any problems with any other bootable disks on that drive, though.

It occurred to me that I could grab that file from any version of linux
and it should work, since although I was using Mandriva to create the CD,
the file is effectively its own OS. So I searched with
www.filewatcher.com and grabbed the largest stage2_eltorito that it found
(from Frugalware Linux 0.4) on the principle that it should contain more
drivers. That did in fact work fine.

--
Dave Farrance

I demand that Dave Farrance may or may not have written...

[snip]
> At the grub prompt, I entered "geometry ( " which lists the visible
> disks.

> First laptop: fd0 hd0
> Second laptop: fd0 hd0 cd

> In other words, grub couldn't see the CD on the first laptop, even though
> the bios could boot that CD. I guessed that the CD grub loader that was
> supplied with Mandriva, "stage2_eltorito", didn't contain the driver for
> the Mat****a-UJ-825S DVD writer, probably to save space.

ITYM "didn't contain the appropriate driver for the controller chip for the
interface to which the drive is attached".

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government. WE'RE KILLING THE PLANET.

What is food to one, it to others bitter poison.

hDarren Salt wrote:

>I demand that Dave Farrance may or may not have written...
>
>> In other words, grub couldn't see the CD on the first laptop, even though
>> the bios could boot that CD. I guessed that the CD grub loader that was
>> supplied with Mandriva, "stage2_eltorito", didn't contain the driver for
>> the Mat****a-UJ-825S DVD writer, probably to save space.
>
>ITYM "didn't contain the appropriate driver for the controller chip for the
>interface to which the drive is attached".

I'll take your word for it. The IDE interface is provided by the Intel
82801DBM I/O chip, and that was a standard fit to Centrino laptops.
Presumably, it was intended to be backwards-compatible with fairly
generic drivers.

It's strange that I can boot up any other CD or DVD that I've tried, but
the Grub-CD program "stage2_eltorito" provided by both Mandriva 2007 and
2008 can't see this laptop's DVD drive (although I've now found a
stage2_eltorito from elsewhere that does see it).

And for example, with a USB floppy drive, I can boot up a DOS floppy,
formatted by Windows 98 and with Win98's ancient Oak-Technology DOS
CD-driver, and that can see the internal DVD drive OK.

I don't know if either grub or DOS use any BIOS calls to access the DVD
drive, or if they just access the hardware directly.

--
Dave Farrance

I demand that Dave Farrance may or may not have written...

> hDarren Salt wrote:
>> I demand that Dave Farrance may or may not have written...
>>> In other words, grub couldn't see the CD on the first laptop, even
>>> though the bios could boot that CD. I guessed that the CD grub loader
>>> that was supplied with Mandriva, "stage2_eltorito", didn't contain the
>>> driver for the Mat****a-UJ-825S DVD writer, probably to save space.
>> ITYM "didn't contain the appropriate driver for the controller chip for
>> the interface to which the drive is attached".

> I'll take your word for it. The IDE interface is provided by the Intel
> 82801DBM I/O chip, and that was a standard fit to Centrino laptops.

Hmm. ICH4. That's common, so I'd expect the driver *would* be present else a
lot of people would notice.

[snip]
> It's strange that I can boot up any other CD or DVD that I've tried, but
> the Grub-CD program "stage2_eltorito" provided by both Mandriva 2007 and
> 2008 can't see this laptop's DVD drive (although I've now found a
> stage2_eltorito from elsewhere that does see it).

Could it be some "we don't support old hardware" attitude on their part? ;-)

Anyway, it's definitely a bug which you should report to them, if you've not
already done so.

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.

You will be recognised and honoured as a community leader.

Darren Salt wrote:

>I demand that Dave Farrance may or may not have written...

>> It's strange that I can boot up any other CD or DVD that I've tried, but
>> the Grub-CD program "stage2_eltorito" provided by both Mandriva 2007 and
>> 2008 can't see this laptop's DVD drive (although I've now found a
>> stage2_eltorito from elsewhere that does see it).
>
>Could it be some "we don't support old hardware" attitude on their part? ;-)
>
>Anyway, it's definitely a bug which you should report to them, if you've not
>already done so.

I've now tried making Grub CDs using other copies of "stage2_eltorito".
Those from the latest Mandriva, Fedora, Debian and Ubuntu don't work
correctly on my laptop, but that from Frugalware does work. It's just as
well that I stumbled across the Frugalware version on my first search, or
I'd have quickly decided that Grub CDs didn't work on my laptop at all.

I got the latest official Grub 0.9x source tarfile from gnu.org and
compiled that, but it has the same problem. The Grub source tarfile on
the Frugalware mirrors turned out to be just a copy of the official
tarfile, but it's in a directory with some patch files.

http://www7.frugalware.org/pub/fruga...rce/base/grub/

After applying each patch in turn, I found that patch 02 (debugcdboot)
was the critical one that made it work. That patch file is dated
internally as 27-Sep-04, so the fix has been known about for some time.

Possibly the problem described in the following bug might be the same:

http://savannah.gnu.org/bugs/?8722

Grub 0.9x hasn't been updated since 2005, and bug reporting is no longer
supported for it. They're concentrating on a total rewrite, Grub2, which
is still at a development stage. So that presumably is why Frugalware's
patch didn't get copied upstream and thence to any other distributions.

Dunno if it's worth reporting this on the Mandriva bugzilla. I don't
understand the code, so I can't verify that it doesn't insert new bugs.

--
Dave Farrance

I demand that Dave Farrance may or may not have written...

[snip]
> I've now tried making Grub CDs using other copies of "stage2_eltorito".
> Those from the latest Mandriva, Fedora, Debian and Ubuntu don't work
> correctly on my laptop, but that from Frugalware does work. It's just as
> well that I stumbled across the Frugalware version on my first search, or
> I'd have quickly decided that Grub CDs didn't work on my laptop at all.

Hmm...

> I got the latest official Grub 0.9x source tarfile from gnu.org and
> compiled that, but it has the same problem. The Grub source tarfile on the
> Frugalware mirrors turned out to be just a copy of the official tarfile,
> but it's in a directory with some patch files.

> http://www7.frugalware.org/pub/fruga...rce/base/grub/

> After applying each patch in turn, I found that patch 02 (debugcdboot) was
> the critical one that made it work. That patch file is dated internally as
> 27-Sep-04, so the fix has been known about for some time.

Right. Worth reporting, then.

> Possibly the problem described in the following bug might be the same:
> http://savannah.gnu.org/bugs/?8722

> Grub 0.9x hasn't been updated since 2005, and bug reporting is no longer
> supported for it. They're concentrating on a total rewrite, Grub2, which
> is still at a development stage. So that presumably is why Frugalware's
> patch didn't get copied upstream and thence to any other distributions.

Still worth reporting; there are plenty of people still using 0.9x. (FWIW, I
use lilo and plan to continue doing so.)

> Dunno if it's worth reporting this on the Mandriva bugzilla. I don't
> understand the code, so I can't verify that it doesn't insert new bugs.

A brief reading of that patch tells me that it implements two extra commands,
cdinfodebug and cdinfohack, each taking a single parameter (0 or 1) which
determines whether the feature is enabled; the default settings are debugging
disabled and the hack enabled.

The debug info appears to consist of two lines, one with "get_cdinfo drive="
and the other with various details including "cdrp.media_type=".

Worth playing with, I think...

--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE.

There is no heavier burden than a great potential.

Darren Salt wrote:

>I demand that Dave Farrance may or may not have written...

>> http://www7.frugalware.org/pub/fruga...rce/base/grub/
>> I found that patch 02 (debugcdboot) was the critical one that made it work
>
>A brief reading of that patch tells me that it implements two extra commands,
>cdinfodebug and cdinfohack, each taking a single parameter (0 or 1) which
>determines whether the feature is enabled; the default settings are debugging
>disabled and the hack enabled.
>
>The debug info appears to consist of two lines, one with "get_cdinfo drive="
>and the other with various details including "cdrp.media_type=".
>
>Worth playing with, I think...

Now that you've pointed that out, the structure of the patch becomes
clearer to me. Switching cdinfohack off made the CD unavailable, and
switching cdinfodebug on made the following line appear whenever the CD
was accessed or access was attempted:

err=1 cdrp.drive_no=144 cdrp.media_type=0

I removed the debugging stuff and that left just a five line insertion,
as shown in the patch below, although I don't understand what it does. It
worked fine, though. I've posted it on the bugs-grub mailing list at
gnu.org, so I'll see if anybody there is still interested in Grub 0.9x
patches. I'll post it on the Mandriva bugzilla after that.

------------ cut here ------------

--- grub-0.97.orig/stage2/bios.c 2004-03-27 16:34:04.000000000 +0000
+++ grub-0.97/stage2/bios.c 2008-06-12 20:32:09.000000000 +0100
@@ -147,6 +147,13 @@
grub_memset (&cdrp, 0, sizeof (cdrp));
cdrp.size = sizeof (cdrp) - sizeof (cdrp.dummy);
err = biosdisk_int13_extensions (0x4B01, drive, &cdrp);
+
+ if (drive >= 0x88) {
+ cdrp.drive_no = drive;
+ cdrp.media_type = 0x00;
+ err = 0;
+ }
+
if (! err && cdrp.drive_no == drive)
{
if ((cdrp.media_type & 0x0F) == 0)

------------ cut here ------------

--
Dave Farrance

Dave Farrance wrote:

>switching cdinfodebug on made the following line appear whenever the CD
>was accessed or access was attempted:
>
>err=1 cdrp.drive_no=144 cdrp.media_type=0

Slight correction. The full message was:

get_cdinfo drive=90
err=1 cdrp.drive_no=144 cdrp.media_type=0

and on the other laptop, the one that worked anyway without the patch:

get_cdinfo drive=82
err=0 cdrp.drive_no=130 cdrp.media_type=0

I note that the patch only activates on the condition (drive >= 0x88) and
on first laptop, "drive" (a BIOS port number?) is 0x90.

--
Dave Farrance

I demand that Dave Farrance may or may not have written...

> Dave Farrance wrote:
>> switching cdinfodebug on made the following line appear whenever the CD
>> was accessed or access was attempted:
>> err=1 cdrp.drive_no=144 cdrp.media_type=0

> Slight correction. The full message was:

> get_cdinfo drive=90
> err=1 cdrp.drive_no=144 cdrp.media_type=0

And with the hack disabled...? (I expect that cdrp.media_type != 0, and I
think that you'll want that info when discussing this elsewhere.)

> and on the other laptop, the one that worked anyway without the patch:

> get_cdinfo drive=82
> err=0 cdrp.drive_no=130 cdrp.media_type=0

> I note that the patch only activates on the condition (drive >= 0x88) and
> on first laptop, "drive" (a BIOS port number?) is 0x90.

BIOS drive no., not port no.

--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| Kill all extremists!

You have taken yourself too seriously.

Darren Salt wrote:

>> get_cdinfo drive=90
>> err=1 cdrp.drive_no=144 cdrp.media_type=0
>
>And with the hack disabled...? (I expect that cdrp.media_type != 0, and I
>think that you'll want that info when discussing this elsewhere.)

The same. The hack just deleted the error returned from a BIOS call.

After reading some of the code, I see that it tries by default to check
the geometry of the CD using the BIOS INT-13 function 4B01 (AH=4B AL=01),
and if an error code is returned, then grub assumes that the CD is not
available. As it happens, return code 01 means that the command isn't
implemented. A little experimenting showed that 4B00 returned 00, for
example. This pdf doc describes those BIOS calls:

http://www.phoenix.com/NR/rdonlyres/...specscdrom.pdf

This check is nonsensical for a bootable Grub CD, since the CD had to be
available to boot Grub, but that code block seems to be there due to
commonality with the Grub that installs on the HD. Grub might be booted
from a hard disk, then be used to boot a CD if the BIOS isn't able to
boot CDs, as with very early PCs, so there's a check using an "extended"
BIOS call to see if the CD is there.

I've no idea how widely implemented the 4B01 function is. It's not
mentioned in the INT-13 Wikipedia page. Maybe it *is* common now and
there *is* an unusual bug in my laptop's BIOS to stop it working.

--
Dave Farrance