Haines Brown wrote:
> I have a situation in which a debian cd installation disk won't boot,
> but a Knoppix livecd disk will boot, and so I need to understand better
> how the initial drivers get loaded. If I try to boot the debian cd
> installation disk without offering any alternative boot method in BIOS,
> I get a boot failure, system halted error.
>
> It is my understanding that the CPU calls a set of programs on the ROM
> chip, one of which is BIOS. I gather that BIOS holds a series of device
> drivers that enables the system to function prior to boot. BIOS
> setup seems to control which drivers get loaded so that a boot can
> begin. Is this accurate?
>
> In the case of my problem, there are certain drivers that will be needed
> for the system to access my IDE cdrom drive. How can I find out what
> they are and verify that the BIOS has indeed loaded them?
>
> If the system accesses the cdrom in some cases (Knoppix), but not others
> (debian install disk), should I infer that the debian install disk needs a
> driver that the Knoppix disk does not? What could distinguish the two
> disks in terms of their initial requirements?
>
> If a needed driver, such as the one to access a cdrom drive, is not
> being loaded, can I get it to behave?
>
> What is the correct term to refer to the drivers built into BIOS, as
> distinguished from the drivers in initrd?


The CD boot is a kludge: In principle, there is
a copy of a boot diskette image on the CD, and
it is shown to the boot code as the first diskette
(BIOS call 0x13, device 0x00).

The diskette image stays there until the booted
code either sends an acknowledgement message to
the BIOS or simply by-passes the BIOS drivers
with own drivers (like those in the Linux kernel).

For details, Google for 'El Torito specification'.

I guess that the boot actually succeeds, but the
installation CD boot image does not understand
your drive, but Knoppix does.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio (tauno.voipio@INVALIDiki.fi) writes:
> Haines Brown wrote:
>> I have a situation in which a debian cd installation disk won't boot,
>> but a Knoppix livecd disk will boot, and so I need to understand better
>> how the initial drivers get loaded. If I try to boot the debian cd
>> installation disk without offering any alternative boot method in BIOS,
>> I get a boot failure, system halted error.
>>
>> It is my understanding that the CPU calls a set of programs on the ROM
>> chip, one of which is BIOS. I gather that BIOS holds a series of device
>> drivers that enables the system to function prior to boot. BIOS
>> setup seems to control which drivers get loaded so that a boot can
>> begin. Is this accurate?
>>
>> In the case of my problem, there are certain drivers that will be needed
>> for the system to access my IDE cdrom drive. How can I find out what
>> they are and verify that the BIOS has indeed loaded them?
>>
>> If the system accesses the cdrom in some cases (Knoppix), but not others
>> (debian install disk), should I infer that the debian install disk needs a
>> driver that the Knoppix disk does not? What could distinguish the two
>> disks in terms of their initial requirements?
>>
>> If a needed driver, such as the one to access a cdrom drive, is not
>> being loaded, can I get it to behave?
>>
>> What is the correct term to refer to the drivers built into BIOS, as
>> distinguished from the drivers in initrd?
>
>
> The CD boot is a kludge: In principle, there is
> a copy of a boot diskette image on the CD, and
> it is shown to the boot code as the first diskette
> (BIOS call 0x13, device 0x00).
>
> The diskette image stays there until the booted
> code either sends an acknowledgement message to
> the BIOS or simply by-passes the BIOS drivers
> with own drivers (like those in the Linux kernel).
>
> For details, Google for 'El Torito specification'.
>
> I guess that the boot actually succeeds, but the
> installation CD boot image does not understand
> your drive, but Knoppix does.
>
Of course, he didn't define "won't boot".

There can be issues related to the bios and the specific distribution
(or rather how that distribution lays the boot on the CD or DVD).

The BIOS sees the CD as a large floppy, as you point out. But older
BIOS's expect things one way, while more recent BIOS's expect things
to be a different way. A given distribution has to decide which to
be compatible with, and as the older hardware recedes in the distance,
it's more likely to be compatible with newer hardware than old. And if
that's the issue, the CD won't boot on a computer with an older BIOS.

I certainly have the problem, and to boot a more recent version of
the distribution I use, I have to put smartbootmanager on a floppy, and
tell the BIOS to boot from the floppy, and then the smartbootmanager
will actually do the booting from the CD/DVD.

Of course, the original poster is so vague that it's hard to tell
what his problem might be. He's assuming he knows where the problem
lies, but that isn't necessarily the case.

It could also be a simple thing like one specific CD has been written
wrong so it won't actually boot. People do that all the time, they end
up writing the image to the CD as a file rather as an image to be
layed all over the CD. Other times they simply do a bad write, and
the CD isn't useable.

Michael

Tauno Voipio writes:

> Haines Brown wrote:
>> I have a situation in which a debian cd installation disk won't boot,
>> but a Knoppix livecd disk will boot, and so I need to understand better
>> how the initial drivers get loaded. If I try to boot the debian cd
>> installation disk without offering any alternative boot method in BIOS,
>> I get a boot failure, system halted error.
> For details, Google for 'El Torito specification'.

Tauno, thanks for the claification.

> I guess that the boot actually succeeds, but the
> installation CD boot image does not understand
> your drive, but Knoppix does.

Possible, but it is a surprise to experience this when I've used the
drive in plenty of other situations, including installing debian. It is
a rather common drive.

To add fuel to the fire, I got my hands on another installer cd for
debian etch, put together by someone else. This one booted. However,
when the installer got to the point of copying files from the CD, it
failed. In other words, the drive is accessed to the extent of starting
the installation, but not when it comes to downloading files.

I'm going to try to swap out RAM to see what happens, but obviously some
RAM must have been used to get to this point.

--

Haines Brown, KB1GRM

I'm sorry not to have provided more specific information, for I was
trying to ask a rather generic question. In any case, this is a SCSI
system dating to about 2002 that now has debian sarge (2004112) on
it. The kernel is 2.4.27-3-686.

As mentioned, while I can boot Knoppix, the Etch installer gets to the
point that it detects CDROM hardware, scans the CDROM, successfully
autodetects. Howevever, when it tries to copy the installer from the CD,
it "Failed to Copy from CDRM". This seems to have happened with the
first file, zlib1g-udeb.

I located the CD holding the Debian Sarge installer that I had
originally used for this system and hardware, and so I know it worked at
one time with it. When I tried to install Sarge, it noted that some
hardware modules were "not available yet" (apggart, e100, ide-mod,
ide-probe-mod, ide-generic, ide-floppy). This list comes as a surprise,
for these drivers are certainly on the CD (I assume), and so it may be
that some hardware simply isn't seen. It goes on to tell me that CDROM
autodetection was successful and it then tries to load installer
components from the CD. It tells me there's no ethernet card found (I
certainly have it and it works). So "Detect network hardware" failed.

I infer that if the install routine fails to see my NIC and IDE drives,
something's fundamentally wrong at the level of hardware. I have a
replacement motherboard headed in my direction, and if that doesn't
work, I guess I'll just have to trash the system and build a new one
(new mb, cpu, ram, ps).

--

Haines Brown, KB1GRM

Haines Brown wrote:
> I'm sorry not to have provided more specific information, for I was
> trying to ask a rather generic question. In any case, this is a SCSI
> system dating to about 2002 that now has debian sarge (2004112) on
> it. The kernel is 2.4.27-3-686.

Aaa - ha!

You should have told it straight away ...

The Debian installer uses a secondary boot
(which I don't remember the name for) which
does not access the simulated floppy, but
accesses the boot media directly with its
own drivers. The bad side is that it has a
driver for an IDE CD only.

I had the same problem with a SCSI system.
The CD booted fine, as it was then using
the code on the SCSI controller BIOS chip,
creating the simulated floppy, but the
secondary boot got stuck due to the missing
SCSI controller and CD drivers.

--

Tauno Voipio, OH2UG
tauno voipio (at) iki fi

On 2008-02-20, Haines Brown wrote:

> It is my understanding that the CPU calls a set of programs on the ROM
> chip, one of which is BIOS. I gather that BIOS holds a series of device
> drivers that enables the system to function prior to boot.

This is true, but only to a point. The BIOS is real-mode code, and only
needs to provide enough device support to load the kernel, after which
the cpu switches to protected mode. Once in protected mode, the kernel
can load native drivers either from disk or an initrd (RAM disk).

> In the case of my problem, there are certain drivers that will be needed
> for the system to access my IDE cdrom drive. How can I find out what
> they are and verify that the BIOS has indeed loaded them?

These should either be compiled directly into the kernel, or provided in
a real-mode accessible device (disk partition below 1024 cylinders or
initrd).

--

John (john@os2.dhs.org)

John Thompson wrote:

> On 2008-02-20, Haines Brown wrote:
>
>> It is my understanding that the CPU calls a set of programs on the ROM
>> chip, one of which is BIOS. I gather that BIOS holds a series of device
>> drivers that enables the system to function prior to boot.
>
> This is true, but only to a point. The BIOS is real-mode code, [...]

.... Unless you have an EFI BIOS or you're on a MIPS, (Ultra)SPARC or
something. ;-)

>> In the case of my problem, there are certain drivers that will be needed
>> for the system to access my IDE cdrom drive. How can I find out what
>> they are and verify that the BIOS has indeed loaded them?
>
> These should either be compiled directly into the kernel, or provided in
> a real-mode accessible device (disk partition below 1024 cylinders or
> initrd).

Slight bit of pedanticism...: the /initrd/ is accessed from within protected
mode only, not from real mode. ;-) On any /x86/ machine with a legacy real
mode BIOS, the boot processor/core is still in real mode when the LILO or
GRUB bootloader starts running.

The bootloader will then load the kernel image into RAM, as well as an
eventual /initrd/ - as is the case with most binary distributions - and
will pass on kernel parameters to the kernel's bootstrapping code. This
bootstrapping code runs in real mode but only serves as to set up the
necessary registers before the CPU can be switched to protected mode.
Next, protected mode is initialized, and only then are the actual kernel
and /initrd/ decompressed. ;-)

Any hardware access outside of the BIOS boot sequence and the bootloader
operation always happens from within protected mode. The real mode boot-up
sequence involving a CD-/DVD-ROM is a matter of bootloader code and thus
has nothing to do with drivers that have either been statically linked into
the kernel image or that exist in an /initrd/ as modules. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Tauno Voipio writes:

> Haines Brown wrote:

>> I'm sorry not to have provided more specific information, for I was
>> trying to ask a rather generic question. In any case, this is a SCSI
>> system dating to about 2002 that now has debian sarge (2004112) on
>> it. The kernel is 2.4.27-3-686.
>
> Aaa - ha!
>
> You should have told it straight away ...

I still did not tell you enough. My SCSI system does have a SCSI CDROM
drive, but the one I've been using for installation is IDE. The
information you provide is very useful and much appreciated, but I'm no
closer to solving the problem. As my other note suggests, I don't
believe the IDE drivers involved in data transfer from the CD are being
loaded.

I put the installer on a USB-key. When I try to install from it I get:

SYSLINUX 3.31 Debian 2007-03-09 CBIOS ...
unknown keyword in syslinux.cfg
...
missing parameter in syslinux.cfg
...
Loading Linux ...

and at this point reboots, and I'm left in an unending cycle.
--

Haines Brown, KB1GRM

Haines Brown wrote:
> Tauno Voipio writes:
>
>
>>Haines Brown wrote:
>
>
>>>I'm sorry not to have provided more specific information, for I was
>>>trying to ask a rather generic question. In any case, this is a SCSI
>>>system dating to about 2002 that now has debian sarge (2004112) on
>>>it. The kernel is 2.4.27-3-686.
>>
>>Aaa - ha!
>>
>>You should have told it straight away ...
>
>
> I still did not tell you enough. My SCSI system does have a SCSI CDROM
> drive, but the one I've been using for installation is IDE. The
> information you provide is very useful and much appreciated, but I'm no
> closer to solving the problem. As my other note suggests, I don't
> believe the IDE drivers involved in data transfer from the CD are being
> loaded.
>
> I put the installer on a USB-key. When I try to install from it I get:
>
> SYSLINUX 3.31 Debian 2007-03-09 CBIOS ...
> unknown keyword in syslinux.cfg
> ...
> missing parameter in syslinux.cfg
> ...
> Loading Linux ...
>
> and at this point reboots, and I'm left in an unending cycle.


OK.

It seems that the configuration file of your
boot loader (syslinux, isolinux) is hosed.

There are Web pages for syslinux, Google for it.

If you need to read the boot diskette image from
the installation CD, please drop me a mail,
correcting the address in my sig in the obvious way.

--

Tauno Voipio
tauno voipio (at) iki fi

On 2008-02-20, Aragorn wrote:

>> These should either be compiled directly into the kernel, or provided in
>> a real-mode accessible device (disk partition below 1024 cylinders or
>> initrd).

> Slight bit of pedanticism...: the /initrd/ is accessed from within protected
> mode only, not from real mode. ;-) On any /x86/ machine with a legacy real
> mode BIOS, the boot processor/core is still in real mode when the LILO or
> GRUB bootloader starts running.

True, but the initrd itself has to be accessible by the real mode BIOS
before the protected mode drivers it contains can be loaded...

--

John (john@os2.dhs.org)

Haines Brown wrote:
> I have a situation in which a debian cd installation disk won't boot,
> but a Knoppix livecd disk will boot, and so I need to understand better
> how the initial drivers get loaded.

> I get a boot failure, system halted error.

Your problem may be related to the CDROM drive itself. I have encounted
problems with some CDROM drives not being able to interpret some disks
as bootable. By changing the model of CDROM drive (on the same computer,
using the same media), I have been able to boot the disks.

http://markhobley.yi.org/linux/labor...rom/index.html

Interestingly (or not), the swapped out drives could boot from other
disks, for example a Microsoft Windows '95 installer disk.

I suggest that you try to boot the Debian disk on some other computers,
and see if it will boot. That will enable you to confirm that the disk
is bootable.

On the computer that gives a boot failure error, you will probably have
to boot using an alternative method, such as from a pen stick or
floppy drive and mount the CDROM image manually somehow.

> What is the correct term to refer to the drivers built into BIOS, as
> distinguished from the drivers in initrd?

The BIOS services are provided in real mode using interrupts.
You probably won't really want to start looking at that, unless you are
working on some sort of fix to make the images bootable from all drives.

I am keeping a log of all CDROM drives that cannot boot from working
Debian CDROM images, so please update the wiki with your CDROM drive
model.

Regards,

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

John Thompson wrote:

> On 2008-02-20, Aragorn wrote:
>
>>> These should either be compiled directly into the kernel, or provided in
>>> a real-mode accessible device (disk partition below 1024 cylinders or
>>> initrd).
>
>> Slight bit of pedanticism...: the /initrd/ is accessed from within
>> protected
>> mode only, not from real mode. ;-) On any /x86/ machine with a legacy
>> real mode BIOS, the boot processor/core is still in real mode when the
>> LILO or GRUB bootloader starts running.
>
> True, but the initrd itself has to be accessible by the real mode BIOS
> before the protected mode drivers it contains can be loaded...

Indeed, and so must the kernel image be. The bootloader - as advanced and
featureful as it may be, with GRUB springing to mind - operates in real
mode and must therefore find a way to access the disk and read a file into
memory.

In the event of LILO, this is done mainly by BIOS calls - basically just
direct CHS or LBA accesses to physical disk sectors - although LILO
contains some tricks to fool a BIOS regarding what the BIOS considers a
bootable medium.

GRUB is quite a bit more advanced. Its first stage operates similarly to
LILO and uses CHS or LBA to access physical sectors to load its second
stage, and then uses a real mode filesystem driver to load the
kernels, /initrds/ and other modules. GRUB is therefore considered by many
to be a miniature real mode OS, not unlike MS-DOS, whose basic OS design
totally (and solely) revolved around loading a(n executable) file into
memory and passing control of the CPU to that file. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Tauno Voipio writes:

> Haines Brown wrote:
>> Tauno Voipio writes:
>> I put the installer on a USB-key. When I try to install from it I get:
>>
>> SYSLINUX 3.31 Debian 2007-03-09 CBIOS ...
>> unknown keyword in syslinux.cfg
>> ...
>> missing parameter in syslinux.cfg
>> ...
>> Loading Linux ...
>>
>> and at this point reboots, and I'm left in an unending cycle.
>
>
> OK.
>
> It seems that the configuration file of your
> boot loader (syslinux, isolinux) is hosed.

Tauno, I certain appreciate your patience, but the possible problem with
the syslinux.cfg file on the USB stick may be marginal to my initial
concern whether my hardware is broken. This was my first attempt to
create a bootable system on a USB stick, and I may well have messed up
the procedure.

> There are Web pages for syslinux, Google for it.
>
> If you need to read the boot diskette image from
> the installation CD, please drop me a mail,
> correcting the address in my sig in the obvious way.

The missing parameter and unknown keywords, incidentally, were in the
syslinux.cfg file on a USB-key, not a CDROM.

--

Haines Brown, KB1GRM

Haines Brown wrote:

> This was my first attempt to
> create a bootable system on a USB stick, and I may well have messed up
> the procedure.

Probably not relevant - I haven't been following the thread -
but I read this in my notes:
----------------------------------------------
So now I am trying to install the Fedora 7 Live KDE iso
on my new 8GB USB stick, following the instructions
at .

These almost worked; though at first
I got the error message "No Operating System".
But after
dd if=/usr/lib/syslinux/mbr.bin /dev/sdg
both blanche and the VIA machine booted fine into KDE.
----------------------------------------------

--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

Mark, thanks for your comments.

markhobley@hotpop.donottypethisbit.com (Mark Hobley) writes:

> Your problem may be related to the CDROM drive itself. I have encounted
> problems with some CDROM drives not being able to interpret some disks
> as bootable.

I should note that I've been using this CDROM drive on this computer for
years, and in fact used it to install the debian sarge system that it is
now running. So presumably the drive works. Also, it does boot a Knoppix
disk.

> On the computer that gives a boot failure error, you will probably have
> to boot using an alternative method, such as from a pen stick or
> floppy drive and mount the CDROM image manually somehow.

As I noted in another message, I no longer get boot failure error, but
the sarge installation disk starts the installation and gets to the
point that it must copy files from the disk into RAM, and with the
first file it tries to copy, it reboots, and so I'm in a cycle. I
presume that if the installation disk gets this far, that it is a
functional cdrom drive.

--

Haines Brown, KB1GRM

Haines Brown wrote:

> Mark, thanks for your comments.
>
> markhobley@hotpop.donottypethisbit.com (Mark Hobley) writes:
>
>> Your problem may be related to the CDROM drive itself. I have encounted
>> problems with some CDROM drives not being able to interpret some disks
>> as bootable.
>
> I should note that I've been using this CDROM drive on this computer for
> years, and in fact used it to install the debian sarge system that it is
> now running. So presumably the drive works. Also, it does boot a Knoppix
> disk.

Just as with any other CD/DVD reader, the lens may get dirty over time, or
the actual drive mechanism may start showing failure over time. I've seen
it happen myself. ;-)

>> On the computer that gives a boot failure error, you will probably have
>> to boot using an alternative method, such as from a pen stick or
>> floppy drive and mount the CDROM image manually somehow.
>
> As I noted in another message, I no longer get boot failure error, but
> the sarge installation disk starts the installation and gets to the
> point that it must copy files from the disk into RAM, and with the
> first file it tries to copy, it reboots, and so I'm in a cycle. I
> presume that if the installation disk gets this far, that it is a
> functional cdrom drive.

You could also check the CD itself by trying to use this /modus/ /operandi/
on another machine. It's quite possible that there are a few bad bits on
the media - say from a scratch, for instance...

--
Aragorn
(registered GNU/Linux user #223157)