Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 Oct 1999 00:16:01 -0700
From:      Mike Smith <mike@smith.net.au>
To:        Ed Watkeys <edw@poseur.com>
Cc:        stable@freebsd.org
Subject:   Re: Cdrecord problems to record 1 CD 
Message-ID:  <199910010716.AAA02259@dingo.cdrom.com>
In-Reply-To: Your message of "Tue, 28 Sep 1999 23:50:43 EDT." <Pine.LNX.4.05.9909282244570.18853-100000@poseur.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 28 Sep 1999, Jeremy McMillan wrote:
> 
> > You need to read the spec for El-Torito.
> > 
> > Basically, you need a boot image written to block 0 of your raw CD-R. That
> > boot image needs to know how to access your hardware (ie. load a kernel from
> > somewhere?). Bootable CDROM supporting BIOS just looks at the first block of
> > your CDROM and uses it *just* like the boot blocks from a floppy.
> 
> This is not the most helpful response. At your urging, I read the El
> Torito spec, and what you're saying above does not appear to be true
> of the Walnut Creek 3.2 install CD I have or the ISO image for the 3.3
> install CD. What you're describing seems to be the "multiple boot
> image configuration" that's discussed in the spec. The 3.2 and 3.3 CDs
> appear to be of the "single boot image configuration" variety.

We just use mkisofs to creat the bootable images, same as everyone else.

The problem, which was resolved this evening, seems to be that mkisofs 
space-pads the copyright text in the boot catalog.  If you have no 
copyright text (like eg. the 3.2 image), it's all-0 and boots properly 
on most systems.

If you have copyright text, it's space-filled and terminated with a 
single 0 byte, and this fails.

Interestingly, the Windows NT CDROM has copyright text in the boot 
catalog that is nul-filled, and this CDROM (probably the only benchmark 
for bootable CDROMs in the industry) boots just fine, leading to the 
conjecture that someone got sloppy in their BIOS code, which has been 
widely replicated.

In effect, it's the fact that Jordan was _more_ careful cutting the 3.3 
images that lead to this problem.  Damn that quality control process.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910010716.AAA02259>